【マルチコア】並列化 ..
308:デフォルトの名無しさん
06/12/20 23:21:00
あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。
実際にどれだけパフォーマンスに差がでるかわからないけど、
スレッド版を用意してくれると実際に使う人がベンチマークが取れて
プロセス版かスレッド版かどちらかを選択するか判断できていいですな。
> スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
> 温床になっているという主張なのですよ > このライブラリ
さすがに含蓄のあるお言葉ですな。
309:303
06/12/20 23:28:00
>>307
いや、SMPだけを対象にしてます。
MPC++/SCoreとか、ネットワークで接続されたコンピュータを
SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;
310:デフォルトの名無しさん
06/12/21 19:53:02
JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか?
311:デフォルトの名無しさん
06/12/21 20:09:14
>>310
JAVAはマルチスレッドにしても速度は上がらんよ。
312:デフォルトの名無しさん
06/12/21 22:00:09
>>310
速度を気にするならJAVAは問題外
313:デフォルトの名無しさん
06/12/21 23:29:59
てっきり >>194 みたいなことが書いてあるから…
.netは対応?済みらしいがマルチコア環境じゃないから試せない。
314:デフォルトの名無しさん
06/12/22 00:01:18
マルチスレッドは速度を向上させるのが目的ではないと思うがなあ
315:デフォルトの名無しさん
06/12/22 00:09:25
サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン?は既にやってるとこもあるみたいだけど。
316:デフォルトの名無しさん
06/12/22 00:10:31
>>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。
マルチノード、マルチインスタンスにはした方が良いけど、
かなりの大規模ノードじゃなければ十分。
317:デフォルトの名無しさん
06/12/22 04:56:33
>>285
x86である必要があってx86なのではなく、
数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。
318:デフォルトの名無しさん
06/12/22 05:05:09
>>314
何が目的なのか、ハッキリ言ってよ。
>>316
クライアントが同時に複数いる状況で性能を要求されるサーバならば、
2コアとか4コアくらいなら、
同期する必要のない部分と同期する必要がある部分に分けるだけで、
十分だったりするしね。
>>315
XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、
パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。
319:デフォルトの名無しさん
06/12/22 12:35:22
>>310
他の言語と同じように恩恵はあるよ。
恩恵がないのは遥か昔の green thread の頃かな。
320:デフォルトの名無しさん
07/02/14 06:21:12
Intel,80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
URLリンク(www.4gamer.net)
321:デフォルトの名無しさん
07/03/06 16:26:58
トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。
職場の女がニコニコしながら、
「上司の○○さんが呼んでいたので『地球の平和を守りにいってます!』と答えておきましたよ〜」
死にたい気持ちになった。
322:デフォルトの名無しさん
07/03/06 16:32:41
へたくそなコピペじゃねーぞ!
あまりにショックなので、こんな過疎スレに書き込んでいる。
今夜は一人で飲みたい。
323:デフォルトの名無しさん
07/03/06 16:38:00
↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる!
324:デフォルトの名無しさん
07/03/06 16:47:30
オッス、オラうんこまん!
地球防衛隊員ってのをやってるんだ。よろしくな!
325:デフォルトの名無しさん
07/03/06 16:57:41
>>324
恥ずかしい自演乙
326:デフォルトの名無しさん
07/03/07 01:42:39
>>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。
327:デフォルトの名無しさん
07/03/13 14:25:23
それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん(結構かわいい)がレジで支払いしてるトコだった。そのレジ台に置いてあったの
がイチジク浣腸の10個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入
れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。
噂を流したら俺だってわかるし山下さんもかわいそうだから。
328:デフォルトの名無しさん
07/03/20 01:14:45
動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの?
329:デフォルトの名無しさん
07/03/20 22:13:18
linuxでやれ。
330:デフォルトの名無しさん
07/03/21 15:28:42
やってみる価値は非常にありそうだな。
331:デフォルトの名無しさん
07/03/21 16:43:18
つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ?
332:デフォルトの名無しさん
07/03/21 20:02:48
>>331
たぶんそうなんじゃない。
動画は前の画像の圧縮して解凍したものを使うから
ある程度の時間の動画をひとつのスレッドにしたほうが
効果ある上に作るのがとても楽だね。
333:デフォルトの名無しさん
07/03/21 21:17:47
キャッシュ効率が下がるんじゃない?
334:デフォルトの名無しさん
07/03/21 21:47:44
下がるだろうね。
キャッシュ重視で1枚の画像を複数のスレッドでMPEG圧縮する。
手間かける余裕があるかどうか。
CPUのマルチコア化を一般ユーザが使うようになるころは
メモリとかHDDの性能はどうなるのかしら。
335:デフォルトの名無しさん
07/03/21 22:43:12
エンコードに必要なワーキングセットをNとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね
・・・そこまでやるか?
336:デフォルトの名無しさん
07/03/22 03:49:20
ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい?
337:デフォルトの名無しさん
07/03/22 11:25:18
ダンゴ様の許可があればいい
338:デフォルトの名無しさん
07/03/22 14:28:33
>>336
Xeonは除外?
339:デフォルトの名無しさん
07/03/23 02:25:42
>>336
どんな話がどう濁されているのか具体的に。
そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。
>>338
XeonもCore2ファミリじゃね?
340:デフォルトの名無しさん
07/03/23 02:55:13
初期のXeonもCore2だっけ?
341:デフォルトの名無しさん
07/03/23 03:15:39
ダンゴ的にはどうよ?
342:デフォルトの名無しさん
07/03/29 00:56:14
結局は高クロックのシングルコアが速い?
343:デフォルトの名無しさん
07/03/29 04:29:47
それができないからthe free lunch is overなのでは?
344:デフォルトの名無しさん
07/03/29 20:44:06
Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか
Pen3やNetBurst系とは逆?
345:デフォルトの名無しさん
07/03/30 00:00:33
この質問はダンゴじゃないとマトモに返答できないと見た
346:・∀・)っ-○◎●
07/03/30 01:52:36
.
347:デフォルトの名無しさん
07/03/30 03:33:19
32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら
皆知ってるけどね。
348:デフォルトの名無しさん
07/03/30 22:22:50
人間活動 → スカラ
自然現象 → ベクトル
中途半端 → 今のCMP全般
349:デフォルトの名無しさん
07/04/03 09:13:21
____
/⌒ ⌒\ ホジホジ
/( ●) (●)\
/::::::⌒(__人__)⌒::::: \ <で?
| mj |ー'´ |
\ 〈__ノ /
ノ ノ
350:デフォルトの名無しさん
07/04/03 19:26:14
おちんぽ
351:デフォルトの名無しさん
07/04/13 21:20:44
結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。
352:デフォルトの名無しさん
07/04/15 03:08:29
既出かもしれんけど
URLリンク(cag.csail.mit.edu)
353:デフォルトの名無しさん
07/05/06 00:35:15
JCSPの話はここでいいのか?
354:デフォルトの名無しさん
07/05/06 02:41:23
良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。
355:デフォルトの名無しさん
07/06/03 02:01:31
保守
356:デフォルトの名無しさん
07/06/03 15:31:56
逐次処理を並列処理に分割する手法で代表的なものって何?
357:デフォルトの名無しさん
07/06/03 15:33:02
OpenMP とか関数型言語で書き直すとか?
358:デフォルトの名無しさん
07/06/03 15:41:12
>>356
OpenMP、pthread、MPI 辺りですかね。
# SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
ちなみに性能的には MPI > pthread > OpenMP、
お手軽さでは OpenMP > pthread > MPI の順でしょうか。
359:デフォルトの名無しさん
07/06/03 16:43:38
>>358
>ちなみに性能的には MPI > pthread > OpenMP、
ええっ!? SMP環境でMPIってpthreadより性能いいの?
360:デフォルトの名無しさん
07/06/03 17:47:44
OpenMP、pthread、MPI ってどこにあるの?
361:デフォルトの名無しさん
07/06/03 18:15:19
一番星を右に進んだ所、虹の彼方に
362:デフォルトの名無しさん
07/06/04 19:05:59
ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう?
データですか?タスクですか?
363:デフォルトの名無しさん
07/06/04 19:20:07
適材適所。
364:デフォルトの名無しさん
07/06/04 19:22:08
栄枯盛衰
365:デフォルトの名無しさん
07/06/06 00:22:34
>>359
MPIは複数の計算ノード(例えばPCとか)を高速な通信回線で接続した
HPCクラスタ用ですね。
pthreadは共有メモリシステムじゃないと使えないので、CPUの数を増や
してもいくつかの理由(メモリアクセスの集中やキャッシュコヒーレンシ
維持のためのオーバーヘッド増加)のために、システム全体の性能はある
程度で飽和してします。大体 CPU 8〜16 個くらいが限界でしょうか。
クラスタシステムではCPUだけではなくメモリも分散配置しているので、
うまく仕事を複数のノードに配分するようにプログラムを作ることがで
きれば、もっとCPUを増やしてもシステム性能を向上させることができ
ます。
# でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な
# 学生が使える教育機関でしか人気が無いような気がする…。
366:デフォルトの名無しさん
07/06/06 13:37:00
>>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね
>>358
># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
>
>ちなみに性能的には MPI > pthread > OpenMP、
>お手軽さでは OpenMP > pthread > MPI の順でしょうか。
「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?
367:デフォルトの名無しさん
07/06/07 11:12:37
358じゃないけど、
>>366
>「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
SMPだけどNUMAなアーキテクチャとかどうなんだろ。Opteronマシンみたいなの。
pthreadでNUMA考慮して書けばいいけど、間にMPIはさんどくと、誰かが最適化してくれるかもしれない。
もう最適化されてるのかな?
MPIはHPCクラスタ用っていうけど、日立やNECも自社のスパコン用にMPI提供してて、
クラスタならmpich、スパコンならベンダオリジナルのMPIってことで計算コードを使いまわせるんで、
MPIの利用率は高いと思う。10年ぐらい前スパコン使ってたころは高かった。
メモリ共有ノード内と、分散メモリになるノード間の通信の使い分けとか考えたら、
トップスピード出すにはMPIか、その手のライブラリ使うことになると思う。
368:デフォルトの名無しさん
07/06/07 23:03:08
>>367
>SMPだけどNUMAなアーキテクチャ
これは定義矛盾
Opteron は NUMA
NUMA への最適化は最近のカーネルなら大抵入ってるよ
369:デフォルトの名無しさん
07/06/07 23:13:02
>>367
もまいはこれよめ
URLリンク(www.amd.com)
370:デフォルトの名無しさん
07/06/15 00:05:56
これってどう?
URLリンク(www.rbbtoday.com)
371:デフォルトの名無しさん
07/06/15 00:10:53
機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな
372:デフォルトの名無しさん
07/06/15 00:13:22
>>370
URLリンク(www.nec.co.jp)
これのことか?
373:デフォルトの名無しさん
07/06/15 06:55:05
何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に
なるだろうけど、そんな簡単な用途は極めてまれなわけで。
宣伝の一人歩きだろう。
374:デフォルトの名無しさん
07/06/15 07:46:05
>極めてまれ
そうでもない。
処理はシンプルでも大量に捌かないといけない場合はままある。
#尤も、そういうケースは並列化の自動化も難しいが。
375:デフォルトの名無しさん
07/06/16 01:44:51
んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな?
376:デフォルトの名無しさん
07/06/16 02:10:48
画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは
並列化してナンボな物が多い。
デスクトップアプリは 4 コアもあれば十分だと思うけど。
377:デフォルトの名無しさん
07/06/16 11:53:25
大規模マルチコアプロセッサの発売に向け準備を進めるインテル
URLリンク(japan.cnet.com)
IntelのTera-Scale Computing Research Program担当共同ディレクタ
ーJerry Bautista氏によると、現在、Intelの研究者らは、コンピュータ
メーカーやソフトウェア開発者らが、大量のコアを搭載するマルチコア
チップにより簡単に適応できるようにするため、それらのチップの複雑
な機能性を意識させないための手段を模索しているという。
異種マルチコアチップ内のすべてのコアを外骨格のようなもので覆い、
それらすべてのコアを複数の従来型x86コア、あるいは1個の大きなコア
に見立てる。Bautista氏は、「それは、いわば1つのリソース貯蔵庫のよ
うになり、ランタイムがその中から適当と思うものを使用する」と述べ、
「これはプログラミングを簡略化するためだ」と付け加えた。
1個のチップ内の多様なコア間で演算タスクを分配するハードウェアスケ
ジューラを使用することにより、特定の演算タスクをより短時間で完了
できるとBautista氏は指摘する。
プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング
技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要
はない。これらのオペレーションは大抵、チップ自体によって処理される
ため表面化しないのである。
378:デフォルトの名無しさん
07/06/16 16:38:55
>>377
素晴らしい!!
テクノロジーの進化ってとんでもねぇなw
379:デフォルトの名無しさん
07/06/16 22:47:24
Windows出たばかりの頃の宣伝の様だが
380:デフォルトの名無しさん
07/06/16 22:56:25
まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、
コンパイラ屋ガンガレ、死ぬまでガンガレ by Intel
って漏れの耳には聞こえてるが気のせい?
381:デフォルトの名無しさん
07/06/16 23:05:49
>>380
そういうのは NetBurst や Itanic で懲りていると思いたい…
382:デフォルトの名無しさん
07/06/16 23:42:46
>380
俺にはIntel以外のコンパイラは淘汰されてしまえ
と聞こえるが
383:デフォルトの名無しさん
07/06/16 23:54:34
ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん
INTELはいっつもAMDいじめて悦に浸ってる変態だし
しねってかんじだ
384:デフォルトの名無しさん
07/06/17 00:13:12
そらそうよ、Intelはパラノイアが社訓だもん
385:デフォルトの名無しさん
07/06/17 01:16:16
いよいよAMDの時代
URLリンク(northwood.blog60.fc2.com)
URLリンク(northwood.blog60.fc2.com)
URLリンク(northwood.blog60.fc2.com)
URLリンク(blog.livedoor.jp)
386:デフォルトの名無しさん
07/06/17 01:23:55
Intel社、ソフトウエアの並列化が研究開発部門の最重要課題に
URLリンク(www.eetimes.jp)
マルチコア・プロセッサに対する需要の高まりを受け、米Intel社はソフトウエア
の並列化を最重要課題に掲げている。その取り組みの一環として、特定用途
向けプログラミング言語や既存のプログラミング言語/アプリケーションの並列化
に関する研究に250名を投入している。「オレゴン州にある研究開発部門では、
全業務の実に約3/4をソフトウエア関連が占める」
インテルが開発ツールの新版を発売、ソフトウエアの並列化を支援
URLリンク(www.eetimes.jp)
コンパイラは、ベクトル化が可能な場合、SSE命令セットを利用したコードを
生成する。また、C++のテンプレート・ライブラリとして実装されているTBBを
利用すると、ソフトウエア開発者が明示的にコードを記述しなくても、マルチ
スレッド化できる。OpenMPライブラリを利用しており、実行時に利用可能な
コア数分だけスレッドを生成する。
387:デフォルトの名無しさん
07/06/17 15:02:51
AMDは甘ちゃん
IBMとIntelはプロフェッショナル
388:デフォルトの名無しさん
07/06/18 01:10:40
次世代スパコンはスカラーとベクトルの複合型に,日立/NEC/富士通の「3社連合」で開発へ
URLリンク(techon.nikkeibp.co.jp)
アーキテクチャの概要は,スカラー型プロセサからなる演算システムにアクセ
ラレータを付加し,さらにベクトル型プロセサからなる演算システムを組み合わ
せる,というもの。スカラー部とベクトル部は,共有ファイル・システムを介して
データをやり取りする。これによって様々な大規模計算シミュレーションが計算
のタイプに合わせた演算環境を選べるようになる。
ハードウエアだけでなく,ソフトウエアも同時に開発する。「制御フロントエンド」
のジョブ管理を通して,ユーザーはこれら二つのシステムの違いを意識せずに
最適な演算環境を選べるようにするという。
389:デフォルトの名無しさん
07/06/18 06:50:59
>>384
コンピュータ様って事ですね?市民。
390:デフォルトの名無しさん
07/06/18 23:42:06
もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・
URLリンク(pc.watch.impress.co.jp)
391:デフォルトの名無しさん
07/06/18 23:46:07
いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。
392:デフォルトの名無しさん
07/06/18 23:51:36
シーケンス図廃止からやってみようかな?
で、その代わりに何を使えばいい??
393:デフォルトの名無しさん
07/06/19 18:18:04
並列システム用のモデリングviewをUMLに策定してくれんかな。
394:・∀・)っ-○◎●
07/06/20 00:23:28
あのさー
マルチコアに限らずソフトの最適化なんて、現場レベルでボトルネック分析し
どこを重点的に並列化するか設計フェイズにフィードバックしながらやっていくもんで
日本伝統のウォーターフォールモデルじゃ、いくらお絵かきツールが便利になっても
全然役に立たんよ。
むしろUMLの本質は抽象化なんでそもそもマルチコアを意識する必要ねぇ。
逆に具体化しちゃうと、コア数の増減やパフォーマンスの見積もり違いで破綻する希ガス。
マルチスレッドは一般的にはObserverパターン、と本で得た知識をそのまま晒してみる。
URLリンク(www.hyuki.com)
それにしても結城先生お茶目だな。
395:デフォルトの名無しさん
07/06/20 00:28:27
さてと、、、
396:デフォルトの名無しさん
07/06/20 16:51:08
Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が
ご迷惑をおかけしております。
397:・∀・)っ-○◎●
07/06/20 22:12:33
ゲハ厨自演乙
398:デフォルトの名無しさん
07/06/21 00:00:47
>>396
バカかお前www
何も知らないんだなwwwww
ム板で厨認定された糞団子が帰る場所は
学歴とゲハだよwwwwwwww
399:デフォルトの名無しさん
07/06/21 15:37:25
該当するスレが見付からず、
かといってどこにかけばいいかわからないのでここで質問をします
(どこか適当なスレがあれば誘導していただければ幸いです)
今、FreeBSD 6.2のPCからPVMを起動して
Fedora 7(192.168.1.3)とVine Linux 4.2(192.168.1.4)のPCをクラスタに登録したいのですが
登録の成功をつげているのにもかかわらず
マシンには登録されていないような状況になっています
/tmp/pvml.????(????:グループID)を確認したら以下のようなメッセージが
でてきます
------------------------------
[t80040000] 06/21 15:11:35 host1 (192.168.1.2:60822) FREEBSD 3.4.5
[t80040000] 06/21 15:11:35 ready Thu Jun 21 15:11:35 2007
[t80040000] 06/21 15:14:50 netoutput() timed out sending to ryle after 14, 190.000000
[t80040000] 06/21 15:14:50 hd_dump() ref 1 t 0x80000 n "ryle" a "" ar "LINUX" dsig 0x408841
[t80040000] 06/21 15:14:50 lo "" so "" dx "" ep "" bx "" wd "" sp 1000
[t80040000] 06/21 15:14:50 sa 192.168.0.3:32790 mtu 4080 f 0x0 e 0 txq 1
[t80040000] 06/21 15:14:50 tx 2 rx 1 rtt 1.000000 id ""
[t80040000] 06/21 15:16:40 netinput() bogus pkt from 192.168.1.3:32790
------------------------------
PVMの方で勝手にタイムアウトをしているのですが
このような場合はどのようにすれば回避できるのでしょうか?
400:デフォルトの名無しさん
07/06/21 22:38:31
簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある?
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。
401:デフォルトの名無しさん
07/06/23 18:29:29
UNIXのパイプ
402:デフォルトの名無しさん
07/06/24 23:14:58
フィックスターズが出している
URLリンク(www.shuwasystem.co.jp)
は、役に立つのだろうか?
立ち読みした限りでは内容がちと薄い気がするのだが。
403:デフォルトの名無しさん
07/06/26 16:17:27
>>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。
とりあえずコードを何回も書いて覚えている途中。
変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。
404:デフォルトの名無しさん
07/06/26 20:43:30
そんなレベルの奴が並列化なんかに手を出すのが間違い
405:デフォルトの名無しさん
07/06/26 21:33:51
並列かなんてたいして技術いる事じゃないだろ
406:デフォルトの名無しさん
07/06/26 23:43:46
そういうやつが平気でぼけぼけかますのが並列化
407:デフォルトの名無しさん
07/06/26 23:46:28
科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。
javaERの俺にはダグリー先生の本のほうが面白かったけど。
408:デフォルトの名無しさん
07/06/26 23:48:17
>>406
一緒にするなよ
409:デフォルトの名無しさん
07/06/27 08:23:06
Amazonでの評価は微妙だね。
URLリンク(www.amazon.co.jp)
410:デフォルトの名無しさん
07/06/27 18:12:05
俺は釣られないぞ
411:デフォルトの名無しさん
07/06/29 01:44:41
なんでOpenMPばっか期待されてんの?
どこにもOpenMPなんて書いてないように見えるが(本のタイトルとかに)
412:デフォルトの名無しさん
07/06/29 01:46:42
デザインパターンの本。
↓
Javaについてはほとんどのってないので期待はずれ。
↓
デザインパターンの本、評価は微妙。
だれもJavaって言ってないじゃん…
413:デフォルトの名無しさん
07/06/29 13:17:14
たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。
俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。
Win32マルチスレッドプログラミング
URLリンク(www.amazon.co.jp)
414:デフォルトの名無しさん
07/07/06 09:47:57
URLリンク(www.ebjapan.com)
これってハードレベルで並列を実現したってこと?
415:デフォルトの名無しさん
07/07/06 12:21:00
>>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。
416:デフォルトの名無しさん
07/07/07 21:55:50
業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね?
417:デフォルトの名無しさん
07/07/07 22:04:37
>>415
FPGAのparallel random access machine/model
じゃねーのそれって?
しかし今回はそれを1個だけしか作れていないはず。
64個最大実装時(現在開発中)が現行CPUの100倍程度って事だな
まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が
書きやすいと思われる。価格も現実的だし。
418:デフォルトの名無しさん
07/07/07 22:18:17
URLリンク(seisei.s8.xrea.com)
これはどうなんだろうね?
419:デフォルトの名無しさん
07/07/07 22:39:58
>>418
うさんくさすぎねーかw
これが全部実現できるならIPAとかに公募して金もらうはず。
なんか穴があるはずだ。実用上の
420:デフォルトの名無しさん
07/07/07 23:05:23
>>418
すげぇ、胡散臭すぎて読む気にもならないよ。
421:デフォルトの名無しさん
07/07/07 23:29:44
読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。
で?
422:デフォルトの名無しさん
07/07/09 01:01:13
XORをまるちすれっど?
で?
423:デフォルトの名無しさん
07/07/10 10:41:52
オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案?
で?
424:デフォルトの名無しさん
07/07/10 11:41:21
順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる!
俺天才!!!
って事?w
URL削るともっと胡散臭いw
425:デフォルトの名無しさん
07/07/10 15:18:46
えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、
という感じ?
じゃなくてこれは単なる dish の簡単な使用例か。
URLリンク(www2.chem.nagoya-u.ac.jp)
426:デフォルトの名無しさん
07/07/11 22:20:15
>>424
やばい、ドキュメントDLで金とるよ的なページもある。
427:デフォルトの名無しさん
07/07/11 23:45:26
419です。
スマン、どうやらスレ汚しをしてしまったようだ。
削除依頼してくるわ。
428:デフォルトの名無しさん
07/07/12 00:01:42
ごめん、↑は418の間違いね
429:デフォルトの名無しさん
07/07/12 02:56:59
そりゃ潔癖すぎる
気楽にやろうぜ
430:デフォルトの名無しさん
07/07/17 07:17:14
クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。
タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。
無理か?
431:デフォルトの名無しさん
07/07/17 09:33:39
200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。
432:デフォルトの名無しさん
07/07/17 11:49:26
メガドラか
433:デフォルトの名無しさん
07/07/17 12:32:41
200メガギガヘンリー
434:デフォルトの名無しさん
07/07/17 12:38:57
200万ギザエッチ
435:デフォルトの名無しさん
07/07/17 12:57:02
200マゾガチハーレム
436:デフォルトの名無しさん
07/07/17 21:41:58
ダンゴさんのレスが望まれるところだ
437:デフォルトの名無しさん
07/07/18 01:21:03
悪趣味だな。
438:・∀・)っ-○◎●
07/07/18 02:51:49
だーんごー
だーんごー
たーっぷりー
だーんごー
439:デフォルトの名無しさん
07/07/18 11:04:21
>>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。
440:デフォルトの名無しさん
07/07/18 21:12:27
>438
それ、たらこだろ?
441:デフォルトの名無しさん
07/07/18 23:45:04
キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ
442:デフォルトの名無しさん
07/07/18 23:50:16
イチローの出番だわな
443:デフォルトの名無しさん
07/07/19 10:24:49
>>430
ヘテロなマルチコアならcellがあるじゃまいか
444:デフォルトの名無しさん
07/07/19 11:45:36
そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ
れば効率よくマルチプロセス・スレッドができると思ったのよ。
>200MGH
200MHと間違えたよorz
445:デフォルトの名無しさん
07/07/19 16:09:31
>クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして
重い処理をするコアが数パーセントの稼働率でその処理やればいいんじゃない?
あまった時間はクロックダウンして各種電源OFFしてればいいし。
ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな
低速簡単タスクはPICとか使ってやってるシステムもあるよね。
446:デフォルトの名無しさん
07/07/19 16:19:17
どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、
低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。
その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを
考えたほうが建設的だと思う。
447:デフォルトの名無しさん
07/07/19 21:07:21
分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。
人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに
448:デフォルトの名無しさん
07/07/19 22:52:24
>分散すれば仕事が早くなるってアホな幻想
お前がアホなんだろw
449:デフォルトの名無しさん
07/07/19 23:32:58
無理なものは無理
450:デフォルトの名無しさん
07/07/20 00:00:15
つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。
451:デフォルトの名無しさん
07/07/20 00:42:36
工場の単純労働者は1000人必要かもしれない
だからといって社長(+役員)は20人もいらない
452:デフォルトの名無しさん
07/07/20 00:50:41
でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw
453:デフォルトの名無しさん
07/07/20 00:58:53
>>452
それなんていう暖房機具?
454:デフォルトの名無しさん
07/07/20 01:32:05
1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。
455:デフォルトの名無しさん
07/07/20 02:00:49
今なら1U3台で済むよ
QuadXeon 6個+ママン3枚でオケ
456:デフォルトの名無しさん
07/07/20 06:53:20
Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか?
おめでたいな。
457:デフォルトの名無しさん
07/07/20 09:27:02
頭が4つもついてる役員は怖いです。
458:デフォルトの名無しさん
07/07/20 11:07:36
バスが飽和しそうです。
459:デフォルトの名無しさん
07/07/20 23:18:00
>>454-456
お前らブレードサーバも知らんのか?
6U で Xeon 20個 コア 80個ぐらいは積めるだろ。
460:デフォルトの名無しさん
07/07/24 21:52:02
URLリンク(japan.cnet.com)
461:デフォルトの名無しさん
07/07/25 00:49:04
GPL?
462:デフォルトの名無しさん
07/07/25 00:55:38
記事読んだ感じだと、例外付き GPL なんじゃないの
463:デフォルトの名無しさん
07/07/26 00:26:11
LGPLだなたしか。
でも実際これら使っても効果出る範囲狭いみたいだぞ。
464:デフォルトの名無しさん
07/08/04 20:15:15
タスク境界を自動で検出するTOOLないかね?
465:デフォルトの名無しさん
07/08/16 15:32:15
foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。
466:デフォルトの名無しさん
07/08/21 09:25:35
URLリンク(www.itmedia.co.jp)
467:デフォルトの名無しさん
07/08/21 16:40:31
>>465
どういう計算だよw
468:デフォルトの名無しさん
07/08/21 22:27:55
URLリンク(pc.watch.impress.co.jp)
469:デフォルトの名無しさん
07/08/22 13:13:48
URLリンク(www.atmarkit.co.jp)
470:デフォルトの名無しさん
07/08/23 22:07:23
URLリンク(pc.watch.impress.co.jp)
471:デフォルトの名無しさん
07/08/31 20:12:44
Wikiペディアより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず
マジか
472:デフォルトの名無しさん
07/08/31 20:16:45
>>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは
ないことは理解してる?
473:デフォルトの名無しさん
07/08/31 20:26:13
一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける
ものの違いだと認識している。
多分
474:デフォルトの名無しさん
07/08/31 20:40:22
XP HOMEもそうだったでしょ。
物理CPUに対応してるのは1個まで。
物理CPU1個ならコアが4個あっても大丈夫(のはず)
物理CPU2個はXP PROFESSIONALから。4個以上は知らない。
475:デフォルトの名無しさん
07/08/31 22:48:30
それは違うぞ。
476:デフォルトの名無しさん
07/08/31 23:02:14
じゃあどうなの
477:デフォルトの名無しさん
07/08/31 23:03:08
いや、自分でもよくわからないんだけどさ
478:デフォルトの名無しさん
07/09/01 00:01:00
>>473
ちがうよ。
マルチプロセッサってのは文字通り
マザボに CPU を複数のっけることだよ。
ハードディスクを 2 個繋げたり
メモリを 4 枚さすのと同じ。
479:デフォルトの名無しさん
07/09/01 00:20:57
URLリンク(www.atmarkit.co.jp)
Windows 2000 Server Advanced Server
最大SMP CPU数 4CPU 8CPU
URLリンク(win64xp.impress.co.jp)
Windows XP Professional Windows XP Professional x64 Edition
対応CPU数 2 2
URLリンク(q.hatena.ne.jp)
1.WindowsXP HomeEdition … 1 ソケット
2.WindowsXP ProfessionalEdition … 2 ソケット
3.WindowsVista HomePremiumEdition … 1 ソケット
4.WindowsVista BusinessEdition … 2 ソケット
5.WindowsVista UltimateEdition … 2 ソケット
6.WindowsServer2003 StandardEdition … 4 ソケット
コア数は4個だろうが8個だろうが全て認識するようです
480:デフォルトの名無しさん
07/09/01 08:45:16
コアが32個あるタスクメジャー見たなwwwwwwww
481:デフォルトの名無しさん
08/01/15 17:42:48
並列化・並列計算のスレってこの板には多分ここくらいしかないので、
ここで質問します。
太陽系の惑星の軌道を並列計算をするときに、
時刻tでの惑星の速度と位置のデータを
他のプロセスに渡して次の時刻(t+1)の速度と位置を計算させて、
全ての惑星の分を計算し終わったら次の時刻の計算を・・・
と繰り返す処理をPVM + C言語で組んでいるのですが、
どうもデータの送受信部分のコーディングがうまくいきません。
繰り返し1回目はちゃんと結果が帰ってくるんけど、
2回目は送信はできるけど計算結果が帰ってこない、
というような状況になっております。
並列計算で繰り返し処理を行う場合は
データの送受信の処理はどのようにコーディングすればいいのでしょうか。
(作りかけのプログラムをどっかにうpしたほうがいいんですかね・・・?)
482:デフォルトの名無しさん
08/01/15 17:56:30
>>481
MPIのスレがあるぞ
483:デフォルトの名無しさん
08/01/16 19:20:30
>>482
そうなんですがMPI以外の話になっちゃうので
抵抗がありまして・・・
484:デフォルトの名無しさん
08/01/16 20:30:46
地球時間とか木星時間の一年周期で同期したらいいんじゃね
485:デフォルトの名無しさん
08/03/29 13:31:27
cygwin+gccだとどのような方法がありますか?
486:デフォルトの名無しさん
08/04/06 22:12:28
ない
487:デフォルトの名無しさん
08/04/07 12:52:16
lam-mpiならcygwinにインスコできた。
mpichもたぶんできる。
488:デフォルトの名無しさん
08/04/08 08:42:45
IntelのCt言語っててにはいるのかな?
489:デフォルトの名無しさん
08/04/21 23:13:24
「小飼弾のアルファギークに逢ってきた」っていう本に
Dave ThomasがErlangの本を書いているって書いてあったんだけど
詳細が分かる人いますか?
07年7月に出版予定とか書いてあったけど、どうもAmazonの洋書でそれらしいものがない。
490:デフォルトの名無しさん
08/04/21 23:14:06
すみません。
誤爆しました。
491:デフォルトの名無しさん
08/04/27 21:21:30
128bit レジスタ を 8 コアで SSE 拡張として繋げて、
1024bit のベクトルプロセッサとして使える。
、、、とかだったら面白くなりそうなんだけどな
492:デフォルトの名無しさん
08/04/28 13:11:09
>>491
どれかのプロセスがそれをやっている間他のプロセスが割りを食いそうだからやだ。
493:デフォルトの名無しさん
08/04/28 18:17:35
>>491
逆に並列性が下がりそう
494:デフォルトの名無しさん
08/04/28 21:44:59
素朴な疑問だけど、これからはメニーコアの時代、とかいうが、
コア間で「人月の神話」と同じ問題は発生しないのかえ
495:デフォルトの名無しさん
08/04/29 09:07:34
する。
496:デフォルトの名無しさん
08/04/29 11:53:18
つーか、大昔からのマルチプロセッシングの課題が
いかにリニアにスケールさせるか、です。
497:デフォルトの名無しさん
08/04/29 14:01:25
それじゃ漠然としすぎて無意味だよ
498:デフォルトの名無しさん
08/04/29 14:08:39
大昔からリニアにスケールさせるにはどうしたらいいかって話で
結局は個別対応になるから、一般論として本当に軽い話しかできない
古い記事だけどマルチコア、マルチスレッドで
どこらへんに苦労したかっていうのは書いてあるけどほとんど一般論
URLリンク(www.4gamer.net)
EfficientC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。
499:デフォルトの名無しさん
08/04/29 14:28:00
>>497
知りたいことの的を絞ってくれればある程度話ができるよ。
500:デフォルトの名無しさん
08/05/10 13:46:08
mac osx ppc64 で tbb を使って遊んでみようと思ってます(当然シングルコアなので雰囲気だけ)
ところが、libtbb.dylibとlibtbbmalloc.dylib を入れてもリンクエラーが発生します。
自分でソースからビルドしてdylibを作り直してもダメ。
dylibの中をみてもそれらしいシンボル名がないようなんですが、どうすれば動くんでしょうか。
501:デフォルトの名無しさん
08/05/10 14:33:45
おおむね一年研究してみたが、マルチコア化でいちばん厄介なのは
1.どれだけスレッドセーフなコードを簡単に作れるか
2.どれだけスレッドセーフを意識しなくてもよくできるか
の二点にかかっている、これに伴って
スレッド化が問題を引き起こすのは、作る側、使う側の間で、仕様伝達がもつれてしまったり、
一旦スレッド化すると、非スレッドセーフに戻したり、逆に非スレッドセーフに作ったコードを簡単にスレッド化できない事で
オブジェクト指向で言えば、オブジェクト間の結合がスレッドによってむやみに強められてしまう点がまずい。
スレッドセーフは、メソッドにつけられる属性の一つとして機能するが、言語機構てきに簡単には取り付けられない。
なにしろ、何につていスレッドセーフかという問題もあって厄介だ。
逆のこの点を解消すれば、むしろ色々な物(IO同期処理等)が統合できて便利だと思った。
『やりたいことの記述と、どう実装するかの記述を分離する事』が最も重要だ。
>結局は個別対応になるから、一般論として本当に軽い話
初めて見た時は不可能そうに見えたが、一般論化しないかぎり成功しない、そしてそれは不可能でもないと思った。
逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。
一言でいえば、いかにサクッと書けるか書き換えられるか、同期が必要なデータが明白化できるかが、そのまま並列化の性能になってしまう。
並列化はパフォーマンスを求めるために使う技術だが、パフォーマンスを求ている内は使い物になりそうにない。
VBが、GUIのコードをあっさり書けるようして、実用的にしたように、マルチコア化も同様なものが必要でスケールとかは意識しても仕方がないと思った。
概念として重要そうなのは、C#やVBのLINQやHaskell等で実装されている遅延評価が使えそうだという点か。
502:デフォルトの名無しさん
08/05/10 15:17:55
CPU・・・衝突、不一致を嫌う設計
脳・・・衝突、不一致を積極的に利用
CPUの設計原理を変えずに、脳の真似をするのは難しい。
503:デフォルトの名無しさん
08/05/10 18:27:12
>>501
> 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。
業務用ゲーム業界に職人技的に伝えられてきたというあの「タスクシステム」?
504:デフォルトの名無しさん
08/05/10 18:51:40
タスクシステムなんてこのWEB全盛時代にはもはや化石だなw
505:デフォルトの名無しさん
08/05/10 19:31:26
並列化のキーワードは網羅って聞いたことがあるような。
例えばソートだと、順列(全パターン)を作ってそれが並んでいるか調べるだけでいい。
現在の手法は今までのアルゴリズムを並列化しようとしているからロックとかで問題になっているんでしょ?
アルゴリズムを根本から変えれば良いと思うけど。
506:デフォルトの名無しさん
08/05/10 20:18:15
>>503
カプコンのMTフレームワークは使うかどうかはともかく、見ておく価値はあるよ。
URLリンク(watch.impress.co.jp)
十分とは思えないが、役に立たない理屈と違い実戦的な並列化手法の一つだから。
507:デフォルトの名無しさん
08/05/10 20:19:49
>>505
量子コンピュータ時代になれば、役に立つかもなw
508:デフォルトの名無しさん
08/05/10 21:15:20
>>507
ある程度コア数が大きくなったら役立ちそうだと思うけど
別に1パターン1コアに分けなくてもいいし。
509:デフォルトの名無しさん
08/05/10 21:59:00
>>508
> ある程度コア数が大きくなったら役立ちそうだと思うけど
算数からやり直した方がいいと思う。
510:デフォルトの名無しさん
08/05/10 23:18:15
>>508
たとえば1000の組み合わせの数を数えてみたらどうかな?
n qubitに対して、並列度が 2^n である量子コンピュータなら
2^1000程度の並列度を持たせれば、その組み合わせ数にも打ち勝てる可能性はあるが、
10個や20個のコアでなんとかなるかな?
511:デフォルトの名無しさん
08/05/10 23:58:22
あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。
アルゴリズムが分かりやすいし。
512:デフォルトの名無しさん
08/05/12 07:51:09
>>511
極めて単純なものだけに有効でしかないよ
総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。
宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。
そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。
量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、
自分たちが感知できない別の宇宙にコンピュータを配置する、
今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。
これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。
ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。
それにしても一番気になるのは計算機よりも並行宇宙そのものだ。
513:デフォルトの名無しさん
08/05/12 21:09:31
量子コンピュータを神秘視しすぎだろwww
514:デフォルトの名無しさん
08/05/13 09:02:31
>>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ?
どうころんでも、どう解釈してもキモ過ぎだよ
515:デフォルトの名無しさん
08/05/13 09:15:37
量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。
キモいと言えばキモい性質ではある。
516:デフォルトの名無しさん
08/05/14 03:50:53
並行宇宙ワロタ
517:デフォルトの名無しさん
08/05/16 06:37:49
並行宇宙ヤバイ
518:デフォルトの名無しさん
08/05/16 19:49:58
>>512マジキモイ
519:デフォルトの名無しさん
08/05/16 19:51:44
2XXX年のオリコン一位
「並列宇宙」
520:デフォルトの名無しさん
08/05/16 22:01:54
>>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか
量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。
521:デフォルトの名無しさん
08/05/17 01:31:05
Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。
522:デフォルトの名無しさん
08/05/17 03:24:15
宗教の話は他でやってくれないか。
523:デフォルトの名無しさん
08/05/17 04:33:17
ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ
524:デフォルトの名無しさん
08/05/17 05:23:47
>>520
量子コンピュータが量子力学の正しさを証明しても
並行宇宙解釈が主流になる事は無いと思われ
525:デフォルトの名無しさん
08/05/17 05:33:35
ここム板やで。
526:デフォルトの名無しさん
08/05/18 14:45:50
>>1
boinc環境を用意してねらーを煽る。
527:デフォルトの名無しさん
08/05/18 19:38:01
懐かしの宇宙ヤバイを思い出した。
528:デフォルトの名無しさん
08/05/29 23:59:57
ちょっと、細かい質問なんだが、
tbbの本38ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。
たとえば、2コアのCPUで1000回のループのを並列処理するときに、grainsizeを500にする、
4コアならgrainsizeを250にすることで、理想的にスケールするということなんでしょうか。
この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか(TBBのもいい参考書だとおもいますけど。)。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5392日前に更新/215 KB
担当:undef