【マルチコア】並列化 ..
424:デフォルトの名無しさん
07/07/10 11:41:21
順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる！
俺天才！！！
って事？ｗ
URL削るともっと胡散臭いｗ
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
>分散すれば仕事が早くなるってアホな幻想
お前がアホなんだろｗ
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
今なら１U3台で済むよ
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
どういう計算だよｗ
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に対応してるのは１個まで。
物理CPU１個ならコアが４個あっても大丈夫（のはず）
物理CPU２個はXP PROFESSIONALから。４個以上は知らない。
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 ソケット
コア数は４個だろうが８個だろうが全て認識するようです
480:デフォルトの名無しさん
07/09/01 08:45:16
コアが32個あるタスクメジャー見たなｗｗｗｗｗｗｗｗ
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)
ＥｆｆｉｃｉｅｎｔC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。
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
タスクシステムなんてこのＷＥＢ全盛時代にはもはや化石だなｗ
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の本３８ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。
たとえば、2コアのＣＰＵで１０００回のループのを並列処理するときに、grainsizeを５００にする、
４コアならgrainsizeを２５０にすることで、理想的にスケールするということなんでしょうか。
この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか（TBBのもいい参考書だとおもいますけど。）。
529:デフォルトの名無しさん
08/05/30 00:11:11
>>528
その本持ってないから意味不明で困る。
処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。
530:デフォルトの名無しさん
08/05/30 00:16:56
>この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁
531:デフォルトの名無しさん
08/05/30 09:09:33
>>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
>>530
ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎
532:デフォルトの名無しさん
08/05/30 09:31:16
>>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
533:デフォルトの名無しさん
08/05/30 12:28:09
調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってｗ
534:デフォルトの名無しさん
08/05/30 13:41:29
>>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw
例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。
535:デフォルトの名無しさん
08/05/30 14:24:20
>>534
「複数のマルチスレッドライブラリが組み合わさった状態」
になったら「ショボイ開発」って思わなきゃダメだよ
536:デフォルトの名無しさん
08/05/30 15:42:06
10000行で完成する程度のコードしか組んだことないんだなw
537:匿名
08/05/30 15:45:44
並列・分散処理に関しては以下のホームページが参考になります。
主要な言語に対応したツールなどの紹介もあります。
www.cspjapan.org
538:デフォルトの名無しさん
08/05/30 16:46:39
>>537
宣伝でつか？
マルチポストでやるのは、あまりイメージ良くないですよ。
539:デフォルトの名無しさん
08/05/30 16:51:46
>>537
ちらっと見ただけだけど、通信部分が浮いている感じがするな、もっと洗練できると思う。
540:デフォルトの名無しさん
08/05/30 17:00:24
グリッドコンピューティング？には合ってる部分もあるのかもだけど
昨今のマルチコア活用方向とは全く合わんのじゃ…
大体想定環境・状況が古すぎるような…
541:デフォルトの名無しさん
08/05/30 17:06:31
プロセス代数は基本だと思うし、オブジェクト間通信という考えの元でも問題はないと思う。
マルチコア活用を阻害している最大の要因はパフォーマンスではなくて
直感的に記述することや効率よく記述すること、デバッグを容易にすることが重要だという点に気付いているかが気になった。
542:デフォルトの名無しさん
08/05/30 17:11:11
もうひとつあるな、現行残っているシングルスレッドモデルで記述された大量のコードを徐々に移行していくための仕組みがいる。
543:デフォルトの名無しさん
08/05/30 17:42:51
>>534
想定しなくていいように作るもんだろ
それに囚人のジレンマは場違いもいいとこ
544:デフォルトの名無しさん
08/05/30 17:58:10
>>532
> コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
プログラマからするとソフトウェアもコードがスマートになるように作ってほしいですよね。
>>543
俺も思ったけど、Wikiみたら使い方あってるみたい。
> 囚人のジレンマ
> 個々の最適な選択が全体として最適な選択とはならない状況の例としてよく挙げられる問題。
545:デフォルトの名無しさん
08/05/30 18:01:14
>>543
すべてのライブラリが自家製とかありえないだろ、ふつう
546:デフォルトの名無しさん
08/05/30 18:12:32
>想定しなくていいように作るもんだろ
想定しなくていいように作る＝毎回開発でスクラップアンドビルド
だが、良いのか？
547:デフォルトの名無しさん
08/05/30 21:10:39
>想定しなくていいように作る＝毎回開発でスクラップアンドビルド
うわっバカだ
548:デフォルトの名無しさん
08/05/30 21:58:47
マルチスレッド並列化で解決すべき深刻な問題の一つだからな、保守性の無さと再利用性の低さは。
549:デフォルトの名無しさん
08/05/30 22:18:08
>>537
今更CSP紹介されてもな…何十年前の話題だよ。
CSPを普通に実装するとプロセス間をデータが流れることになり、
キャッシュを越えるコア間のデータ転送が増えて、途方もなく
効率悪いと思うんだが。
その辺まで言及してくれればこのスレ的な話題になる。
550:デフォルトの名無しさん
08/05/31 08:31:32
>>548
＞ 保守性の無さと再利用性の低さは。
STM はその辺強いのかね
551:デフォルトの名無しさん
08/05/31 13:48:09
>>550
変な用語を使うのはヤメレ、シングルスレッドモデルといいたいのだろうが・・・
ちょっとでも触ればマルチスレッドを使った並列化の現状が論外な状態だと判るはず。
可能ならとっくに流行っている。
552:デフォルトの名無しさん
08/05/31 13:50:49
>>549
現在のプロセッサの最大の弱点はプロセッサ相対で低速なメモリーであって
キャッシュ間の転送は、小さくはないが致命的でもない。
553:デフォルトの名無しさん
08/05/31 14:30:34
>>551
アフォか。Software Transctional Memoryだろが
554:デフォルトの名無しさん
08/05/31 14:56:15
>>552
一般論としてはそうだが例えばfork/joinはスティールされない限り
同じスレッドで実行することでデータ転送を減らすよう考慮されてる
スティールされるのが古いタスクからなのも同じ理由
それに比べてCSPはどうだ？
555:デフォルトの名無しさん
08/05/31 18:16:47
>>554
>fork/joinはスティールされない限り同じスレッドで実行することでデータ転送を減らすよう考慮されてる
SMT(ハイパースレッディング)が登場してから、おかしな対処をしないと性能がでなくなって必ずしもそうなっていないよ、今は。
556:デフォルトの名無しさん
08/05/31 18:24:58
>>555
そうか？tbbやjsr166yのfor/joinは>554で書いたようになってると理解してるが。
ソースｷﾎﾞﾝ
557:デフォルトの名無しさん
08/05/31 18:25:21
しかしまぁ、オペレーションズ・リサーチは情報系出身なら常識だろうと思うが、こういった基本すら知らない奴はどうしてくれるかなぁ
ゲーム理論や囚人のジレンマも知らないというのはどうかと思うんだ・・・
558:デフォルトの名無しさん
08/05/31 18:28:29
>>556
Core 2 Quadマシンと、Windows Vista 買ってきて、ひとつアプリを走らせろ
そして、タスクマネージャーなり、ガジェットからCPUメーターをダウンロードして睨めっこをするんだ
そうすれば、ソースも必要ないし説明するまでもない筈。
559:デフォルトの名無しさん
08/05/31 18:36:48
>>558
まさかProcessor affinityの話をしてるのか？
560:デフォルトの名無しさん
08/05/31 18:37:45
>>559
謎用語出す前に、基本を勉強しとけ
561:デフォルトの名無しさん
08/05/31 18:43:23
>>560
謎用語て…単なる煽りか？それなら消えてくれ
煽りじゃないなら>558とjork/joinのタスクスケジューリングの関係を説明してほしい
562:デフォルトの名無しさん
08/05/31 18:44:11
ソースだせと、なぞ用語で捲し立てるのが趣味なら消えてくれ
563:デフォルトの名無しさん
08/05/31 18:46:20
>>557
常識だと思うけど、大学卒業して10年の俺はさっぱり覚えてないw
564:デフォルトの名無しさん
08/05/31 18:46:37
頭の悪いGKがいる、絶対いるw
565:デフォルトの名無しさん
08/05/31 18:56:40
>>562
Processor affinityはWindowsでもLinuxでも商用UNIXでもAPIになってる
特定のプロセス／スレッドを特定のCPUに割り当てられやすくするもの。
fork/joinのスケジュールがスレッドのローカルなキューからタスクを
取ってくるのも新しいタスクをキューの先頭に入れるのも
他のスレッドからキューの後ろからスティールするのも
Processor affinityの元でスレッドが同じコア上で実行される場合に
キャッシュが効率的に使われることを目指していると俺は理解している。
さて、>555や>558について説明してもらえないかな
566:デフォルトの名無しさん
08/05/31 18:58:27
>>565
CPUメーターみてみなよ、OSが勝手にスケジュールを調整してこちらの意向を無視している。
567:デフォルトの名無しさん
08/05/31 19:03:08
>>566
そのアプリがSetThreadAffinityMask読んでないなけだろ
568:デフォルトの名無しさん
08/05/31 19:04:05
>>567
単に、特定アプリに依存すると障害が多いからMSが調整しただけかと
569:デフォルトの名無しさん
08/05/31 19:08:58
>>568
意味が分からない
SetThreadAffinityMaskを呼び出していないスレッドをOSが勝手に
スケジュールするのは当然のことだ
お前さんの言ってるアプリはSetThreadAffinityMaskを呼び出してるのか？
呼び出してないアプリでCPUメーター見ても全く意味がないんだが
Processor affinityを知らなかっただけじゃね？
570:デフォルトの名無しさん
08/05/31 19:10:20
そっちの言っている事こそ意味不明だわw
571:デフォルトの名無しさん
08/05/31 19:12:50
じゃあさ、>558で「ひとつアプリを走らせろ」のアプリが
SetThreadAffinityMaskを呼び出してるアプリのことかどうかだけ答えてくれ
yes/noだけでいいからさ
572:デフォルトの名無しさん
08/05/31 19:14:01
こんなの、つまらないコード書いて、パフォーマンス確認目的でパフォーマンスカウンタ見れば一発なんだが・・・
なんでこんなややこしい話が登場するのかと・・・
573:デフォルトの名無しさん
08/05/31 19:14:46
バカ相手にするのは疲れる
574:デフォルトの名無しさん
08/05/31 19:22:31
>>572
ややこしい話はしていない
そのつまらないコードでSetThreadAffinityMaskを呼んだのかどうか、それだけだ。
これもyes/noだけでいいから答えてくれ
575:デフォルトの名無しさん
08/05/31 19:31:59
SetThreadAffinityMaskじゃなくSetProcessAffinityMaskなら
タスクマネージャーから設定できる。
プロセスタブでプロセスを選んで右クリック、関係の設定でCPUを選ぶだけ
576:デフォルトの名無しさん
08/05/31 20:07:00
逃げたようだな。結局Processor affinityすら知らなかっただけだけか
何が「基本を勉強しとけ」だよｗ
きっとfork/joinも何のことかわかってないんだろうな…
577:デフォルトの名無しさん
08/05/31 20:31:28
割り込んでごめんなさい。
windows 2k serverってマルチコアに対応してますか？
windows serverは全部対応してるって記事をネットで見たけど、
記事自体、いまいち信用できないんです。
578:デフォルトの名無しさん
08/05/31 20:57:52
雑誌記事が信用できずに、誰の発言かもわからない
掲示板の話を信用するんですか？
579:デフォルトの名無しさん
08/05/31 21:16:49
>>578
どっちもどっちですが、広告だらけのブログで「対応してる。」って言われるのと比べるなら、
まだ、ここのほうが信用できます。
「ここで公式に書いてるよ！」みたいなレスがあればなぁなどと思った次第です。
580:デフォルトの名無しさん
08/05/31 21:31:15
それプログラミングと関係ないだろスレ違いだしageんな
581:デフォルトの名無しさん
08/05/31 22:21:36
>>578
P4-2.4Cで2個見えてるから、2個までは対応してると思うよ
＃手元に2コアまでしかないからそれ以上は分からんｗ
582:デフォルトの名無しさん
08/05/31 22:25:52
初心者ですまんが
Ｐｇ作るのにマルチコアなんて気にする必要アンの？
いいところスレッド処理とか流せば
しかたねえな ってかってに動いてくれそうだけど
583:デフォルトの名無しさん
08/05/31 22:35:21
そのいいところってのが難しいんじゃない？
いままでみたいな粗い粒度のスレッドの使い方じゃなくて、もっと積極的に
例えば単なるクイックソートを2〜4スレッドで並列実行して高速化しようとか、
そういうのを考えるんじゃないかなたぶん
584:デフォルトの名無しさん
08/05/31 22:35:59
>>582
ここは君が来るところではないんだよ。
ここはデュアルコアならシングルコアの2倍、クアッドコアなら4倍の
パフォーマンスを目指すスレ。
今のところ有益な議論は一度もないけどな。
585:デフォルトの名無しさん
08/05/31 22:54:45
Processor affinityも知らないSoftware Transactional Memoryも知らない
wait freeやlock freeの話も出ない
有益な議論のしようがないなｗ
586:デフォルトの名無しさん
08/05/31 22:56:05
>>584
キャッシュに入るような小さな処理から頻繁にメモリアクセスが必要な処理をした際
実際のパフォーマンスを比較したものってどっかにないの？
587:デフォルトの名無しさん
08/05/31 23:03:12
マルチスレッドスレと話題かぶるからなぁ
588:デフォルトの名無しさん
08/05/31 23:17:48
>>582
俺も気になった。
winのapiには無いと思う。
２つのスレッドを２つのコアにわけるなら話も早いけど、
１つのスレッドを２つのコアにわけると、なんか、戻りとか処理のオーバーヘッドがでかそう。
win上で動くプログラムからそこを制御できるかも、よくわかんないし。
と、初心者は思うのでした。
589:デフォルトの名無しさん
08/05/31 23:52:50
初心者だと思うなら、「winのapiには無いと思う。」なんてろくろく調べもしないで
レスするなよ。
590:デフォルトの名無しさん
08/06/01 00:07:59
マルチコア対応apiはwinにはないね。未熟なOSなのかも。
591:デフォルトの名無しさん
08/06/01 00:18:47
同一ソケット上のマルチコアに特化したAPIはないわな。未熟だわなｗｗｗ
592:デフォルトの名無しさん
08/06/01 00:19:17
windows上なら、SetXXXAffinityMaskってのを使うみたいだけど、
OSに任せたほうが無難だろうな。
ビットマスクに何指定するのか、俺の古いMSDNだとわかんないし。
あとNT3.5から対応してるんだな。
これ使ってプログラム組んでれば、
別にwin 2kでもwin 2k severでもマルチコアに対応できる気がする。
（OSが認識さえできれば、で、マルチコアは2kで認識できるはず。非公式だけど。）
>>577への回答ね。マルチコア対応プログラムなら、おそらくwin2kでもおっけ。
むしろ余分な他プロセスのバックグラウンド処理が少ない分、win 2kがxpやvistaより早いと思う。
それ以外は、OSの判断だけど、多分２つCPUあるときと同じだから、win2kでも大丈夫な気がする。
こっちはあんま自信ない。
以上、>>577の自己回答でした。
593:デフォルトの名無しさん
08/06/01 00:22:55
>>589
嫌味な上級者は、絶対何も言わないんだよな。
さっきからずっと、むかつくレスしてんのこいつだろ？
上司でたまにいるんだよ。
知ったかして、具体的に何も言わないで、誰かが言ったら便乗するやつ。
594:デフォルトの名無しさん
08/06/01 00:27:06
そりゃ、言うべきじゃない時を心得てるのが上級者というものだからなあ
595:デフォルトの名無しさん
08/06/01 00:31:12
>>592
MSDN見たなら「参照」も見るといいよ
596:デフォルトの名無しさん
08/06/01 00:43:55
>>592
あんまり調べる気無い。
何か映像関係の高速処理組むなら別だけど予定もないし。
スレッド、プロセス関連は完全に２、３継承のクラス化しちゃってるし、
いまさらOSの判断以上の速度が出るように直す気はない。
597:デフォルトの名無しさん
08/06/01 00:44:33
時代がマルチコアなのになぜ対応apiがないのか？
これはMSの怠慢ではないだろうか
高いOSライセンス代（１台につき１万〜３万）を定期的（５年程度）に払っているというのに
ひどい話だ
598:デフォルトの名無しさん
08/06/01 00:51:54
>>597
マルチコア対応APIって具体的にどういうものよ？
599:デフォルトの名無しさん
08/06/01 01:06:17
>>597
だからwindowsにもあるって。
プロセッサを直接指定できるapiが。
やっぱNT系のカーネル作った連中は偉いわ。
おれもまだまだ2kで行く。
600:デフォルトの名無しさん
08/06/01 01:10:52
マルチコアねぇ…
TPC風にProcessor/Core/Threadで表すと、Core2Quadの1/4/4はマルチコアだよな。
じゃあシングルコアXeonを4個使った4/4/8とかItaniumを64個使った64/128/256は？
後者もマルチコアならマルチコア対応APIは既にある。
601:デフォルトの名無しさん
08/06/01 01:12:08
マルチダイもマルチコアに含めてるしな、、、思想的には
ていうか、やっぱまだ２ｋって需要あるかなー？
今新規にフリーソフト作ってるが、どこまでサポートするか悩む
602:デフォルトの名無しさん
08/06/01 01:15:22
>>599
Processor affinityはDECのVMSの時代からある。
WindowsNTと作った連中は同じだけどなｗ
603:デフォルトの名無しさん
08/06/01 01:19:14
>>601
俺、フリーソフトは、2kで作って、xpで軽く動かしてテスト終わり。
2kで動いて、xpで動かなくなったことはない。
基本、Direct X関係に気をつけるだけ。
604:デフォルトの名無しさん
08/06/01 01:22:24
CPUが別パッケージかオンダイかを気にするような場面には出くわしたことないなあ
キャッシュの奪い合いとか同期の頻度とかが問題になるのかな？
むしろhyper threadingが特別だったんじゃないかと思う
605:デフォルトの名無しさん
08/06/01 01:24:49
Win32のSetThreadAffinityMaskはaffinity maskがDWORDで32bitしかない
64/128/256のSuperdomeはOSからは256プロセッサに見えるんだがどうするんだ？ｗ
606:デフォルトの名無しさん
08/06/01 01:27:16
hyper threadingは鬼門
607:デフォルトの名無しさん
08/06/01 01:29:44
>>606
Pen4のHyper Threadingだけが鬼門？ SMT全般が鬼門？
ちょっとだけPower使ったときは何もなかったけどな
608:デフォルトの名無しさん
08/06/01 02:01:39
>>605
いずれSEtThreadAffinityMaskExが出来るだけよ
609:デフォルトの名無しさん
08/06/01 02:05:55
>>608
いずれってかSuperdomeにWindowsが乗ってから5年以上経ってないか？
Windows乗ったSuperdome俺は見たことないけどｗ
610:デフォルトの名無しさん
08/06/01 02:08:16
テキトウに仮想化でもしたほうが効率よさそうな気が
611:デフォルトの名無しさん
08/06/01 02:14:38
>>610
それは現実的すぐるｗ
とりあえずタスクマネージャーはこうなる
URLﾘﾝｸ(www.microsoft.com)
これで「関連の設定」は64CPU設定できるのか？
つかItaniumだから64bit Windowsか…
612:デフォルトの名無しさん
08/06/01 02:54:12
Win64ではﾓｰﾏﾝﾀｲだた
BOOL WINAPI GetProcessAffinityMask(
__in HANDLE hProcess,
__out PDWORD_PTR lpProcessAffinityMask,
__out PDWORD_PTR lpSystemAffinityMask
);
DWORD_PTR WINAPI SetThreadAffinityMask(
__in HANDLE hThread,
__in DWORD_PTR dwThreadAffinityMask
);
613:デフォルトの名無しさん
08/06/01 03:25:02
>>607
606じゃないけど、HTは面倒な存在じゃない？
普通のマルチプロセッサなら異なるプロセッサ間で同じキャッシュラインに
アクセスしない方が良いが、HTの場合は逆でしょ？
ベンチ取ってないんで、どのくらい影響があるのかは具体的には分からんが。
614:デフォルトの名無しさん
08/06/01 03:36:55
menndouda
615:デフォルトの名無しさん
08/06/01 03:41:14
>>613
それはPower含めてSMT全般にいえるし、少しレイヤをずらすと
2(3)次キャッシュ共有のマルチコアやNUMAにもいえるんで、
そんなに特殊なことではない。
さっきWin64調べてたらこんなAPIがあった
BOOL WINAPI GetNumaNodeProcessorMask(
__in UCHAR Node,
__out PULONGLONG ProcessorMask
);
これで距離の近いノード内のプロセッサマスクを取得できる。
NUMAアーキテクチャに限定せず、SMTやキャッシュ共有のコアを
ノードと見なすことができると、細粒度並列実行で効果的なヒントを
与えられるかもしれない。
616:デフォルトの名無しさん
08/06/03 13:35:38
マルチコア対策としてこんなのがあります。
URLﾘﾝｸ(www.axon7.com)
また、これも参考になります。
URLﾘﾝｸ(www.cspjapan.org)
617:デフォルトの名無しさん
08/06/03 13:45:14
>>616
>537
618:デフォルトの名無しさん
08/06/03 13:58:55
マルチプロセス、マルチスレッド、マルチコア、マルチプロセッサ、SMT、メモコン共有、キャッシュ共有、演算器共有。
これが複合的に絡んだときの最適化は複雑すぎる。
619:デフォルトの名無しさん
08/06/03 14:44:35
>>617
>549
620:デフォルトの名無しさん
08/06/03 14:47:41
間違えた、>619は>616へ。
>>618
それをコンパイラで成し遂げることが前提のItaniumは不可能に挑んだようなものだな
621:デフォルトの名無しさん
08/06/05 13:51:00
マルチコアは、今までのソフトウェア技術を台無しにしてくれる素晴らしい技術だよね。
これからはソフトウェアとハードウェアの境界が無くなって、
プログラムを作るのは、より一層大変になる。
622:デフォルトの名無しさん
08/06/05 14:08:33
ハードとソフトが緊密に絡む領域はこれまでもあったんだけどな
無停止システムとか
623:デフォルトの名無しさん
08/06/05 14:08:49
今までのマルチプロセッサ向けのソフトウェア技術の延長にあるから
台無しという事は無いよ。もう何十年も研究が続けられている分野だ。
624:デフォルトの名無しさん
08/06/05 15:54:23
何十年も研究とか、無駄の極地だねｗｗｗ
625:デフォルトの名無しさん
08/06/05 16:04:53
ロックフリーのアルゴリズムやトランザクショナルな変数アクセスが
もっと一般化してくれば、そんなに恐れる物でもない気がするけどね
626:デフォルトの名無しさん
08/06/05 17:43:57
>>621
いったい何に怯えているんだろうか
627:デフォルトの名無しさん
08/06/05 18:51:05
まあそりゃ単一スレッドで速くなるほうがありがたいけどな
628:デフォルトの名無しさん
08/06/05 19:06:01
荒い粒度の並列化や、ベクトルの並列処理はとっくに研究され尽くされてるけど、
その中間が非常に厄介。
しかし、これからは単一スレッドでは速くならないわけだから、それをやらないといけない。
629:デフォルトの名無しさん
08/06/05 19:53:53
ループを展開する自動並列化くらいはインフラとして整備して欲しいね
630:デフォルトの名無しさん
08/06/05 23:02:40
>>629
自動じゃなくてもparallel array使えばおk
631:デフォルトの名無しさん
08/06/05 23:56:43
>>628
divide and conquer
work stealing
fork/join
parallel array
632:デフォルトの名無しさん
08/06/07 23:32:29
遅レスだが
ハードウェア・ソフトウェア協調設計等は組み込みでは昔からよく見られるんじゃないか？
まあ、シミュレーター等の開発統合環境が整えられているなら最適化はむずかしくないよ。
ただ工数と時間と労力が膨大に費やされていくだけで
633:デフォルトの名無しさん
08/06/13 19:49:18
組み込みの場合は、環境のプロセッサ数やプロセス数は固定されてるから、難易度は低いんじゃないかな。
PCの場合は、対象のプロセッサ数は予想できないし、同時にどんなプロセスが動くかも分からないから、難易度が高い。
というか、PCの場合は、何らかの動的最適化メカニズムが必要になるんだよね。
URLﾘﾝｸ(pc.watch.impress.co.jp)
インテルはCを拡張してJITコンパイラで最適化する研究をしてるようだけど、
実用化はまだまだ先だよな。
634:デフォルトの名無しさん
08/07/06 06:28:11
１．マルチなんたらとか並列化とか、なにも考えずに作る。
２．あとは開発環境とOSがなんとかしてくれる。
３．下手なこと考えるより、そのほうが最終的に効率が良い。
こういうのが理想なんだけどなぁ…。
635:デフォルトの名無しさん
08/07/06 09:34:03
スレ民じゃないけどマルチコアネタがあったのでぺたぺたしていきます。
「Ruby 1.9は1.8より平均5倍速い」、YARV笹田氏 − ＠IT
URLﾘﾝｸ(www.atmarkit.co.jp)
今後のテーマは並列処理によるスケーラビリティ向上
今後の研究テーマとして笹田氏は、並列処理への対応など
スケーラビリティに取り組みたいと話す。ただ、「Rybyの言語仕様の
枠組みでスケーラビリティを上げるのは難しい」ため、マルチコア、
マルチプロセッサといった密度の高い並列化よりも、クラスターや
グリッドのようにネットワークで接続された複数ホストによる並列化を
実現していくのがいいのではないかという。
636:デフォルトの名無しさん
08/07/06 10:51:06
>>634
それ何て第五世代
>>635
むしろマルチコア関係なくね？
637:デフォルトの名無しさん
08/07/06 10:59:42
マルチコア向けの最適化はしない方向だ、という内容だな。
638:デフォルトの名無しさん
08/07/06 16:27:58
今後もRubyのスレッドはマルチコアを使いこなすようにはしない方針ということだな
639:デフォルトの名無しさん
08/07/06 16:42:50
Rubyなんて並列化のこと何も考えてないじゃん。
書いててわくわくするとか日和ったこと言ってる言語では到底無理。
640:デフォルトの名無しさん
08/07/06 20:49:23
並列化に興味をもったRuby使いはErlangあたりに移行するのだろうか
641:デフォルトの名無しさん
08/07/06 23:42:11
アルファブロガー（笑）あたりに煽ってもらえばイッパツよ
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5385日前に更新/215 KB
担当:undef