- 1 名前：デフォルトの名無しさん [2006/01/18(水) 08:31:11 ]
- 最近のCPUはマルチコアが技術トレンドになっています。
それに伴い、ソフトウェアは並列化というパラダイムシフトが
求められています。効率のよく並列化を実現するためにはアル
ゴリズムやデータ構造といった部分を根本から見直す必要が
あります。しかし、トレンドができてからあまり時間が経って
ないため、そいういったノウハウが蓄積されていません。
そこで、マルチコアを生かすためのソフトウェア設計というのは
どういうものか？という議論をするためのスレッドを立てました。
ソフトウェアの並列化に対して考えのある人や、インターネット
上のリソース、論文等があればどんどん書き込んだりリンクを
貼ってください。
【関連スレ】
OpenMPプログラミング
pc8.2ch.net/test/read.cgi/tech/1102483474/l50
- 29 名前：デフォルトの名無しさん [2006/01/19(木) 00:20:01 ]
- Erlang
→www.kmonos.net/alang/etc/erlang.php#process1
スレッド間のやりとりにはメッセージ通信で実現するみたいですね。
思ったんですが、確かにタスク間のやりとりは共有メモリみたいな
ものでなくて、メッセージ通信の方がスマートな感じがします。
この手のメッセージを行うライブラリにはMPIがあるようですが、
これは完全に独立したプロセス間の通信ですよね。フリーで気軽
につかえるスレッド間通信のライブラリって誰かしらない？
組み込みではμTRONがOSはメッセージボックスつーのがあって
タスク間の通信ができるのですが、Windowsってそういう仕組み
がないですよね。一応SendMessageとかのAPIはスレッドセーフに
なっているけど機能不足だし。
- 30 名前：デフォルトの名無しさん [2006/01/19(木) 00:39:57 ]
- 関連スレ
数百のコアプロセッサ用新言語「Baker」
pc8.2ch.net/test/read.cgi/tech/1110031339/
日本発、次世代言語： 織田信長
pc8.2ch.net/test/read.cgi/tech/1047230229/
- 31 名前：デフォルトの名無しさん [2006/01/19(木) 00:44:50 ]
- >>27
関数型言語では、変数代入でなく束縛（再束縛禁止）が普通なので、
式の前のほうと後ろのほうに依存がなく、
処理系が勝手にバラバラのスレッドで実行できる。
副作用なしなので当然スレッド間の干渉はない。
とよく知らんけど妄想。
- 32 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 01:01:21 ]
- 副作用なしっていう制約下でマットウにプログラムかけるやつがどれくらいるのか
という問題はある
- 33 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 01:01:38 ]
- >>29
Javaが5.0になってからマルチスレッド回りの処理が大幅にパワーアップしたけど
これもマルチコアを見据えてのことなのかなぁとおもった
JavaやC#とか高級言語はどんどんこの辺は容易になって来るでしょうね
逆にC++とかはガリガリかけるけど、つらいものが
- 34 名前：デフォルトの名無しさん [2006/01/19(木) 01:08:49 ]
- >>33
C言語も重い腰を上げて言語レベルでの並列処理を(C++0xとかで)
サポートしようという動きもあるみたい。今まで言語で並列処理
を何でサポートしなかったんだというのはあるけど。
- 35 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 02:09:16 ]
- トータルの処理コストは 1.5 倍になるが、完全に並列化出来るから、
実行時間は 2 スレッド時で 0.75 倍みたいな世界が来るのかしら。
- 36 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 02:36:54 ]
- C++はBetter Cだからなぁ。正直あんなつぎはぎの言語仕様
ぜんぜん使いたくない。JavaとかC#のほうがよほど洗練され
ていると思う。ヘッダファイルとかローテクすぎ。
- 37 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 03:30:19 ]
- >>C++はBetter Cだからなぁ。
馬鹿発見。
- 38 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 04:09:42 ]
- >>9
現実のアプリケーションで性能差がどれくらい出るの?
プログラムをチューニングするほどの差がないなら、終了、だよ。
- 39 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 04:13:09 ]
- 複数のスレッドに分割するのが大変なアプリで、速度を要求するものってあるの?
重いアプリは、
今まで通りに、おおきな粒度で水平垂直に分割すれば、速くなるじゃないか。
- 40 名前：デフォルトの名無しさん [2006/01/19(木) 04:21:39 ]
- そうは言っても、
昔なら遅くなるし面倒だからやらない、なんて感じだった
付加的な処理でも、ＣＰＵの速度向上や生産性の向上で
どんどん付ける様になってる。
そうやってソフトが進化してきたのが、ＣＰＵのコア速度頭打ちで終わってしまう。
- 41 名前：デフォルトの名無しさん [2006/01/19(木) 04:25:16 ]
- >>32
最初からそういうプログラミングを教育をすれば良いじゃない。
Cやアセンブラから入ったＤＱＮＰＧはオブジェクト指向が理解できないけど、
同レベルの奴でも最初からJavaとかで始めると理解できる、なんて話があるらしい。
- 42 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 08:21:16 ]
- 関数型もいいが、Prologとかの論理型も並列処理に向いてそうな希ガス
- 43 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 10:36:06 ]
- 手続き型が一番向いてないね。
- 44 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 10:41:34 ]
- 逐次処理なのがネックだよねぇ・・・。
ただ、今のCPUとOSは、スレッド間の同期が重いと思う。
粒度を小さくしていくと、同期のオーバーヘッドが無視できなくなる。
だから、今のCPUとOSを使う限り、粒度の大きなマルチスレッド化しかない。
そのスレッド分割を人間がやるか、自動化するか、ってことだよね。
- 45 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 11:08:34 ]
- よくは知らんけど純粋関数型言語ってのは
入出力に副作用時だけ同期させてればいいのかな？
- 46 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 12:50:11 ]
- >>42
織田信長がそうだな。並列論理型言語。
しかし、論理型言語なんて使ってる奴いるのか？
- 47 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 13:10:46 ]
- "Functional Concurrent Language" の検索結果 約 178 件中 1 - 10 件目 (0.53 秒)
"Concurrent Functional Language" の検索結果 約 744 件中 1 - 10 件目 (0.58 秒)
"Logic Concurrent Language" の検索結果 約 16 件中 1 - 10 件目 (0.77 秒)
"Concurrent Logic Language" の検索結果 約 344 件中 1 - 10 件目 (0.55 秒)
"Concurrent Procedure Language" の検索結果 約 3 件中 1 - 2 件目 (0.44 秒)
"Concurrent Procedural Language" の検索結果 3 件中 1 - 3 件目 (0.47 秒)
"Procedure Concurrent Language"に該当するページが見つかりませんでした。
"Procedural Concurrent Language" の検索結果 4 件中 1 - 4 件目 (0.46 秒)
- 48 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 14:41:43 ]
- マルチコアの片方をGC専用にするのはありですか?
- 49 名前：デフォルトの名無しさん [2006/01/19(木) 14:44:05 ]
- "Concurrent Programming Language" の検索結果 約 24,700 件中 1 - 10 件目 (0.37 秒)
- 50 名前：デフォルトの名無しさん [2006/01/19(木) 15:24:48 ]
- そのうちマルチコアって言ってもCPUが4個とか8個とか16個とかが当たり前になるんだろうな。
そしてその後1スレッドを1CPUで動かす時代が来る。
- 51 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 15:31:48 ]
- 10年後。
CPUのクロックは100GHzになり、16384コア32768コアも当り前になり、
メモリは256Gバイトが3千円ぐらい。HDDは250Tバイトが1万円を切る。
もちろんPCの電源を入れると複数個のOSが同時に起動する。
- 52 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 15:50:07 ]
- > CPUのクロックは100GHzになり、
わかってないな、こいつ
- 53 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 15:53:03 ]
- >>52
なるだろう。
- 54 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 15:54:53 ]
- >>52
電気で動くCPUとも書かれていないから良いんじゃない?
- 55 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 21:01:49 ]
- これが技術的に可能になれば100GHzのCPUや256GBのメモリもできるだろ。
ttp://www.nanoelectronics.jp/kaitai/moletronics/index.htm
そのころにはHDDもこれに置き換わっているかも･･･
www.nanoelectronics.jp/kaitai/mram/index.htm
究極の並列処理素子。ここまで行ったら･･･
ttp://www.nanoelectronics.jp/kaitai/quantumcom/index.htm
- 56 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 21:44:58 ]
- 実現してない話はどうでもいい
- 57 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 22:59:21 ]
- シングルコアで順調に速くなっていくんだったら、マルチコアなんて要らんだろ。サーバはともかく。
１０年で分子コンピュータ技術が実用レベルに達して商用になるかと言えば、ならない方に賭けるな。
だってCPUの基礎技術は２０年以上変わってないのでは？
- 58 名前：デフォルトの名無しさん [2006/01/19(木) 23:01:19 ]
- ￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
( ＾ω＾) ∧＿∧
／ ＼ （ ）何言ってんだこいつ
.＿＿| | .| |＿ / ヽ
||＼ ￣￣￣￣ ／ .| | |
||＼..∧＿∧ (⌒＼|_＿./ ./
||. （ ） ~＼___＿_ノ| ∧＿∧
/ ヽ 氏ねよ ＼| （ ）
| ヽ ＼/ ヽ. ｵﾏｴ馬鹿だろ
| |ヽ、二⌒) ／ .| | |
.| ヽ ＼∧＿∧ (⌒＼|_＿./ /
- 59 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 23:04:43 ]
- 前：デフォルトの名無しさん ：2006/01/19(木) 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
( ＾ω＾) ∧＿∧
／ ＼ （ ）何言ってんだこいつ
.＿＿| | .| |＿ / ヽ
||＼ ￣￣￣￣ ／ .| | |
||＼..∧＿∧ (⌒＼|_＿./ ./
||. （ ） ~＼___＿_ノ| ∧＿∧
/ ヽ 氏ねよ ＼| （ ）
| ヽ ＼/ ヽ. ｵﾏｴ馬鹿だろ
| |ヽ、二⌒) ／ .| | |
.| ヽ ＼∧＿∧ (⌒＼|_＿./ /
- 60 名前：デフォルトの名無しさん mailto:sage [2006/01/19(木) 23:34:08 ]
- 分子コンピュータの開発なんてもう10年以上前からやってるわけだが
- 61 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 00:04:15 ]
-
C MAGAZINE 2006年2月号
ttp://www.cmagazine.jp/
デュアルコア・マルチコアのCPUで大活躍
OpenMPで賢いマルチスレッドプログラミング（前編）
- 62 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 00:06:04 ]
- いい最終回だった
- 63 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 00:37:36 ]
- 実際のところ最もパワーが必要になるのは鯖とかエンコとかゲームだから
それらはマルチスレッド化での効果はわりと大きいからべつにいいんじゃね？
>>48
あり
Java5のインクリメンタルGCのデフォ並列世代別GCになってる
通常のアプリが動いてる後ろでガリガリGCしてくれてる
そしてストップが必要になるGCについてもこれもオプションで並列動作可能
あずーるとかみたいにハードのサポートが来るのが一番だと思うけどね
そうでなくとも中間言語系はバックグラウンドでかなり動いてるから
アプリは何もしてなくても2コアでもびっくりするほど恩恵を受けるよ
- 64 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 00:51:17 ]
- Emacsのマルチスレッド化はいつのことになるやら・・・
- 65 名前：デフォルトの名無しさん [2006/01/20(金) 02:55:56 ]
- >>61
前編で終るのか・・・。
- 66 名前：デフォルトの名無しさん mailto:sage [2006/01/20(金) 03:01:37 ]
- 最終号はなにか凝ったことするのかな
- 67 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 12:49:44 ]
- メモリー自体にCPUを乗せて、簡単な処理はメモリーが直接計算する、という案は駄目でつか？
今の技術なら、Z80CPU1万個を一枚のチップに乗せて、並列に計算させるぐらいの事は、
できそうな気がするけどな・・・無茶か？
- 68 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 12:50:44 ]
- >>67
消費電力が物凄い事になりそうだぞ？
- 69 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 12:52:41 ]
- >>67
似たようなアーキテクチャがNTTのCELLでなかったかい？
- 70 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 12:54:05 ]
- オブジェクト指向はクラスタ化のためにやるんだと思ってた・・・
- 71 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 12:56:33 ]
- 普通の会社はメモリと密接にってのはまず無理
メモリってデータ取り出すだけでどういう動作するか分かってる？
せいぜいメモリコントローラ作ってフロントエンドで処理するしかないよ
Z801万個くらいの性能デイならFPGAでできそうだが
- 72 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 13:00:46 ]
- 描画メモリーならレイトレースするエンジンがそんな感じだと思った
- 73 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 15:20:43 ]
- ようわからんが、これってそんな感じ？
GPGPU
pc8.2ch.net/test/read.cgi/tech/1128780920/
- 74 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 15:46:47 ]
- >>73
保守乙
- 75 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 16:43:50 ]
- よく知らんが、WRAMとかSGRAMとかVRAMとか、その系統じゃね？
もう名前を聞かなくなって久しいが。
まだ特定用途向けに使われてるのかな。
- 76 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 17:26:33 ]
- 箱○に載ってるね。メモリアクセスだけで、Zバッファや
アンチエリアシングの処理をするのに使われている。
- 77 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 01:29:23 ]
- Cellはゲームに特化したプロセッサだから汎用には不向きだぞ。
- 78 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 03:06:27 ]
- だねえ、CELLは倍精度演算とか弱いし、特定のメディア用プロセッサであって
汎用CPUにはなれない。
そのかわりDSPの塊みたいなものだから用途が合えばめちゃ速いと思う。
- 79 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 10:13:15 ]
- mpeg2やDivXの高品質リアルタイムエンコ、とかは?
- 80 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 10:15:50 ]
- デジタル回路で処理してるだけかと
- 81 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 11:16:09 ]
- メモリというかレジスタだな。
- 82 名前：1=メガデモスレ660 [2006/01/22(日) 21:10:22 ]
- pc7.2ch.net/test/read.cgi/jisaku/1136822334/
マルチスレッドスレに貼り付けてあったんだけど、面白そうなので
ここにも貼っておく。アンチマルチコアって自分だけじゃないのを
初めて知った。PC自作板ってつまんないから全然みないんだよね。
- 83 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 21:16:12 ]
- つーか、アンチうざい
新しいのが出てきてそれについていけないやつだと思うけど
- 84 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 23:21:03 ]
- 2コアぐらいなら、OSとアプリケーションでおおまかにひとつづつ使い切るような感じで、
別にシングルスレッドのアプリケーションでも意味あると思うんだよね。
だけど、４、８とコアが増えてくるとそうはいかない。負荷がかかってるのにも関わらず
アイドル状態のコアが出てきちゃいそう。
- 85 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 23:31:53 ]
- >>84
> 2コアぐらいなら、OSとアプリケーションでおおまか
> にひとつづつ使い切るような感じで、
流石にお馬鹿の Windows でも、そんなにＯＳのオーバー
ヘッドはでかくない。シングルスレッドプログラムではマル
チコア/マルチプロセサの恩恵はほぼないので、
> 負荷がかかってるのにも関わらずアイドル状態のコアが
> 出てきちゃいそう。
と言うのは、２コアでも十分ある。
- 86 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 00:49:24 ]
- >>85
自作板を見てると、DualはWindowsの体感速度が上がるからっていう理由で
買ってる人が多いみたいなんだよね。IEやエクスプローラを含めたOS全般と
自分の使ってるアプリケーションの両方が同時にスムーズに動くと。
だけど、そういう人たちでもさすがに４個や８個もの多コアは買わないだろうな
という気がした。
- 87 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 00:52:06 ]
- >>83
そういうやつが周りに一杯いるけどそういう奴は蹴落としていくしかないと思う。
なんとなく小泉総理が親友を作らず孤独な少年であったというのが分かる気がする
- 88 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 01:15:57 ]
- 淘汰されるなら淘汰されるで歓迎
- 89 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 02:47:28 ]
- >>85
常に一個位アイドルなCPUが居るのって結構重要だったりする。
エンコやら異常事態やらで地獄の様に重い時でもUIの応答が軽いのはストレスを生まない。
- 90 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 06:14:19 ]
- それはnice値変えるだけでもいいような
- 91 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 07:30:41 ]
- それはniceなアイディアだ
- 92 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 08:55:09 ]
- アンチってなんなの？
マルチスレッドプログラムがかけない人なの？
シングルコアの性能をもっとあげる方法を発明できる人なの？
アンチとして存在してる意味がﾜｶﾗﾈ
- 93 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 09:40:16 ]
- >>92
今まで普通にプログラムを作ってきたプログラマー達だね。
彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
>>63の言うとおりにガベージコレクションの性能が上がったとしたらそれだけで彼らは失職の危機にさらされる。
まあ、主にゲームプログラマーだけどね。
実際ゲームはシングルスレッド信仰がすごい強い分野だと思う。
ただ、滑稽なのはゲームなんてクリエイティブな分野でそんなに技術屋さんがでしゃばっていること。
本当はマルチコアでどんな新しいゲームが作れるかを考えるべきなのにそれを邪魔するだけの典型的な既得権益者なので
外野としてはそんな害虫どもにはさっさと消えてもらうことを祈るだけだね
- 94 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 12:54:33 ]
- ＞彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
＞おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
それで困るのは半端な連中だけだ
きっちっとした技術を積み上げてきたヤシなら、それほど恐怖でもない
むしろ他の連中と差をつけるチャンスだ罠
- 95 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 13:25:29 ]
- >>93
ガベコレの性能とゲームプログラマの失職に何の関係がある？
あと、ゲームのどの変の処理にマルチスレッドを導入するべきだと思う？
- 96 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 14:51:31 ]
- >>95
GCの性能が上がったら高級言語でもそこそこゲームが作れるようになるじゃないか。
ベンチマークではC++と関数型なんてほとんど変わらないしな。
そうなるとある程度ライブラリとかフレームワーク作ったり業務系と同じようになってくるんじゃないかな?
単純にシングルコアの性能だけでも相当向上してるのだからそうやってやり方が変わって脱落者が出るのでは？。
どんなゲームがいいかは例えばRTSのようなゲームで個々のユニットを複雑なアルゴリズムで動かすとかはどうだ?
- 97 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 15:35:46 ]
- D言語の時代ｸﾙｰ?
- 98 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 15:56:06 ]
- DってGC性能が低いんだったっけ？
それ以前に仕様がまだ固定化されてないのが気になるが
それとDはスレッドの機能が初期のJavaベースで非常に少ない気がするんだが
今後マルチスレッドプログラミングが増えればこのへんとかネックになってくるかもね
ま、必要になってくれば標準APIとして実装されるとは思うけど
今後スレッドが言語に組み込まれてない環境は厳しくなるよね
- 99 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 16:43:54 ]
- >>96
処理速度の向上によって今までC/C++でしかできない・C/C++が望ましかったような
ゲームが、Javaや関数型言語でも実装できるようになるだろう、という予測？
それともイチから実装する難易度が超絶的に上がり、結果必然的に高レベルなライブラリが
整備されるので、高級言語だけでもなんでもできるようになるだろうという話？
後者は理解できるけど、前者は疑問なような気がする。
生産性の向上によって確保した知的資源は、更なる難問の解決に使われるのが普通だから。
（そうじゃないと低賃金労働でしか生き残れない）
- 100 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 19:08:23 ]
- 豪華なマシンになってPGが楽になる・・・なんてことはなく、
実際は性能を限界まで出しきることを期待されてひどい目に遭うだけ。
- 101 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 19:23:38 ]
- >>100
ゲーム業界だとSFC,PS,PS2の時に聞かされた、PS2はまぁ期待にそえんでもなかったが。
- 102 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:29:20 ]
- ゲームってシングルスレッド信仰というより、わざわざマルチスレッドで
コンテキストスイッチするメリットがあまりないだけじゃないだろうか。
負荷もでかいし同期が必要なものは余計やりにくい。
- 103 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:34:00 ]
- むしろ並列演算言語が欲しい所だな
つ〜か、マルチスレッドである必要は全く無いんだよ
並列演算が可能なら、シングルスレッドでもかまわない
その意味では、昔はＭＭＸに期待したわけだが・・・
- 104 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:39:09 ]
- >>99
どっちかというと前者かな?Javaや関数型がそのまま使われるかは知らないけどPS3でオープンソースな人たちが勝手に実験始めるでしょ
低賃金労働から逃れるためにはライブラリ屋になるのが自然。ライブラリ屋が儲かるか知らんけど。
後者は手動での最適化するのが本当にできるのか疑問視していて、並列化言語を実用化させたほうが早いと思ってる。
- 105 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:40:22 ]
- マルチスレッドによる並列性の引き合いにMMXによる並列性
を出すのはどうかと思う。
- 106 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:40:59 ]
- >>103
バス幅とバスクロックの壁は厚かった
- 107 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:46:54 ]
- >>105
下手にマルチスレッドを使うよりは、並列演算を行った方が処理が早くなると思わないか？
- 108 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:49:21 ]
- １０個のコアがあるのなら、１０個別々に処理するよりも、
同時に同一処理を行わせるのもアリだと思うんだよな。
- 109 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:50:41 ]
- >>104
するってえと高賃金乙な国内の業者さんたちは結局ライブラリだの物理モデルだの
並列処理向き言語＋プラットフォーム開発だの、GCがどうとかいうレベルではなく難しい
ことをやらざるを得なくなって、「余った知的リソース⇒難しい仕事」という流れになるような・・・
成功しないのでそういう流れにはならない、という可能性も高いけど。
数学はインド人の方が得意そうだし。
- 110 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:51:37 ]
- >>107
いやだから用途が違うと思うんだけど。MMXつかって速くなるところに
マルチスレッド使っても速くなるようなケースは限られると思うが。
（逆もまた然り）
- 111 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:56:48 ]
- >>110
コアがたくさんあったとしても、一つのスレッドの扱えるコアは一つ？
- 112 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:00:41 ]
- >>111
話の流れがわからん
- 113 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:01:05 ]
- >>103
NeoMagic の MiMagic6 なんかがその路線で、16x16ピクセルの画像を
対象とした演算なんかを1命令でできる演算ユニットを積んでます。
中〜大規模SIMDってのも、応用範囲は限られるものの確かに面白い。
けれどもクロック上げて水で冷やしてガンガンパワー使えるなら不要な
手法なのかなという気もしないでもない・・・
小さいモノの中ではダイナミック・リコンフィギュアラブルLSIとかが
そういう思想のもののような気がするけど違うかもしれない。
- 114 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:06:50 ]
- >>112
つまり、10個のコアがある場合に10個演算する場合は、10個スレッドを立ち上げて、
10個同時に演算して、演算が終われば元のスレッドに戻せば、10倍の速度で演算できるのでは？
って事。
- 115 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:14:20 ]
- >>114
しかしバス幅とバスクロックの壁は、非情なまでにも分厚かった
- 116 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:15:56 ]
- >>114
それふつうにマルチコアの利点
今後はどの点が並列処理できるかという設計レベルの重要性がますわけだ
今まではそのCPUにあわせてどうすれば少ない時間で処理できるかの最適化をする
という点だったからね
JavaのコンカレントAPIみたいなのが普及せんときついかもね
- 117 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:19:09 ]
- >>114
俺が言いたいのは、SIMDは局所的な並列で、マルチスレッドはもっと大域的ってこと。
MMXは隣接ピクセル間の並列性、マルチスレッドはブロックごとに区切るような
（マルチレンダリング）用途でしょう。俺なら同時に使うけどね。どっちかが
肩代わりするもんじゃない。
- 118 名前：デフォルトの名無しさん [2006/01/23(月) 22:54:48 ]
- 関連スレ追加
pc8.2ch.net/test/read.cgi/tech/1099819556/
- 119 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 01:34:42 ]
- >>117
スレッドのというか処理の粒度の問題って解くべき問題との関係が深すぎるからこのスレのタイトルだと混乱するかもしれない。
- 120 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 02:24:55 ]
- スレッドとマルチコアは何の関係もないだろ。
- 121 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 03:39:30 ]
- マルチプロセッサ(SMT含)を想定してのマルチスレッドプログラミングと全く同じだもんな。
プロセッサ間の通信速度や、外部(メモリ)との通信速度が違う、というだけで。
- 122 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 04:37:07 ]
- >>109
つまり技術的にはインドに負けることが前提なわけですな。
- 123 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 11:46:28 ]
- マルチコアのマルチスレッドって、通常のマルチプロセッサに比べて
注意するところあんの？ ハイパースレッドプロセッサだったら
スピンロック問題とか言うのがあった気はするけど。
- 124 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 12:57:29 ]
- >>86
自作板のあれは、多くの場合、負け惜しみです。
体感速度が云々と言ってる人達は、遅いCPUをdualにしています。
本当にCPU速度が必要な人達は、
マルチスレッドで動くアプリを使っていて、
ユーザの操作のためにCPUが丸々1個アイドルで待機しているのでレスポンスが良い
なんてことにはならないのです。
- 125 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 12:59:39 ]
- >>102
ゲームはCPUを他のスレッドに譲るという概念がないから。
ビジーウェイトとか平気でやるからな、ゲームプログラマは。
- 126 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:00:32 ]
- >>107
並列演算を行った上で、
さらに、
マルチスレッドですよ。
- 127 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:58:16 ]
- できるやつは新しいのが出てきてもいい物を作る
できないやつは昔からの作り方にこだわり進歩しない
ゲーム製作スレのオブジェクト指向いらねという話と似てる
- 128 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 14:03:03 ]
- >>125
そんなアホはさすがに居ない。
、、と思いたいが、居る所には居るのか。
- 129 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 14:41:26 ]
- >>127
君みたいなのをみるとイライラする。
みんなマルチコア、マルチコアいっているけど、はっきりいって現状、中身がないって
いっているつもりなんだけど。マルチコアの性能を生かした設計というのは難しいし、
まだそれは誰も解決していない。それを簡単だというならそれをちゃんとわかるように
それをどうやって解決したか書いてくれ。ここはそれを解決するためにみんなで考えま
しょうっていうスレだ。
マルチコアをマンセーするのとその技術をマスターするのは、天と地ほど差があるよ。
マンセーするだけでマスターした気になっているのは中身が無い。
もうちょっと真剣に技術に対して考えてくれ。
|
 |
