【マルチコア】並列化について語る【使いこなせ】

最近のCPUはマルチコアが技術トレンドになっています。

それに伴い、ソフトウェアは並列化というパラダイムシフトが
求められています。効率のよく並列化を実現するためにはアル
ゴリズムやデータ構造といった部分を根本から見直す必要が
あります。しかし、トレンドができてからあまり時間が経って
ないため、そいういったノウハウが蓄積されていません。

そこで、マルチコアを生かすためのソフトウェア設計というのは
どういうものか？という議論をするためのスレッドを立てました。

ソフトウェアの並列化に対して考えのある人や、インターネット
上のリソース、論文等があればどんどん書き込んだりリンクを
貼ってください。

【関連スレ】
OpenMPプログラミング
http://pc8.2ch.net/test/read.cgi/tech/1102483474/l50

乙
ネタ的には面白そうなネタだと思う

マルチコアの場合、メモリーとのアクセスはどうなってるの？
バス幅やバスクロックは変わらないようにも思えるけれど・・・

マルチなバスがあって、マルチにメモリーにアクセスしてるとか？

関連

マルチスレッドプログラミング相談室 その４
http://pc8.2ch.net/test/read.cgi/tech/1130984585/

>>3
コアが複数になってもメモリへのアクセスは変わらないので、
今まで以上にメモリ帯域やバスがネックになりそうな感じ。

コアが複数でもI/Oの数（メモリやハードディスク、グラフィ
ックカード等）は変わらないので、それをどうするのか？
というのは問題ですよね。

そのうち、それぞれのハードにバスキャッシュが乗るんじゃね？ｗ
バス同士のデータのやりとりで、アクセスロックが発生しかねんが。

>>3
各社各様。当然クロスバーにしている所もある。

マルチコアの特定のCPUにチューニングするとかしない限り、
従来のマルチプロセッサ向けのマルチスレッド化との違いは、
ないと思われ。

ということで、終了。

コア間の転送スピードが速いとかキャッシュの共有が可能とか
わりとマルチプロセッサとは違う動作する

マルチプロセスだとうまみはないが、マルチスレッドによる最適化は
こっちのほうが影響を受けやすい

シングルコアだとcopy on writeが有効だけど、メニーコアだとすぱっとcopyしてしまったほうがコア間の依存関係を断ち切れて、かえって効率が上がる、と言う話を聞いたことがある。
こういう、従来の高速化手法をひっくり返すようなものって他にどんなのがあるの?

CoWってどのCoW？

ライブドア全力で逝った人は自業自得としか言いようが無いね。
今年は少し負けてるけど、我慢してずーっと東１銘柄だけ取引してたから
良かったよ。

新興はもうだめだな。しばらくは様子見しよう。

↑
はげしく誤爆。すまそ。

>>12
今年で負けてるってどんな銘柄買ってんの？
下手なのはいいけど、人の不幸見て喜ばないように。

昔の同僚がやってる会社の株を持ってるぜ。買わされたようなもんだが。

京都の漬物ｳﾏｰ

>>14

昨日今日の市場暴落劇知らないのか？
今年はまだ半月しか経ってないから犠牲者多数出てるよ。
職場で昨日から青ざめてる上司とか今日いきなり欠勤した人
とかいない？

>>12
知ってていっているんだけど。今日は完全にブラマンだよね。
去年の年末は稼がせてもらったけど、最近はノーポジ。
底で口をあけて待っているところ。

というかスレ違いだ。

ライブドアか・・・今なら貝かな？ｗ

ﾜﾛｽ
メガデモ、マルチコアときて次は株スレ@ムが立つか？

効率なんて人間に考えさせてるようじゃだめ。
人間は人間にとって作りやすく分かりやすい
ようにプログラムを作って、あとは全自動で
それを効率よく動かすようなシステムを作る
べきだ。

人間に最適化をやらせるとろくなことはない。
そんなもんはC言語で散々やられてわかっって
るだろう? 無理にポインタ使って効率よく
作ったプログラムは読みづらいばかりか後の
コンパイラでは最適化の邪魔になったじゃないか。

未来のコンパイラのために今のプログラムを劣化させるべきだというのかい？
しかも未来のコンパイラがどんな最適化をしてくれるのかもわからないというのに

あったあった。
ttp://pcweb.mycom.co.jp/news/2005/12/19/046.html
こういうのがほんとに普遍的に作用してくれるなら楽だろうね。

ただ、こういうのを使ったとしてもハード側とソフト側の両方に対して見識が深くないと
有意な高速化はできないだろうなあ。
どうやっても複数コアでは高速化できない類のプログラムってのも存在するはずだし。

>>23
やっぱり理想は自動並列化だよね。特に自動並列化コンパイラ
には期待だけど、マイクロソフトなんかは今になってやっと
OpenMPを実装したから、普及は思っているより先になりような
予感はする。

ところですまないんですが、浅はかな質問をさせてください。

並列化の割合を上げるには、タスクをアトミックな単位で
分割して並列実行するのがよろしいのかと思います。
おそらくもっともアトミックかつすでに自動的な並列化である
CPU内部のスーパースカラの本数を増やすとか同時実行できる
命令の種類を増やすために実行ユニットを増やすといった
方法はなぜとられないんでしょうか。多分、CPUメーカーの
人とかは解っててやっているんでしょうが。

>>24
たぶん
＞並列化の割合を上げるには、タスクをアトミックな単位で
＞分割して並列実行するのがよろしいのかと思います。

これが間違いだからじゃない？
既存のタスクを自動的に分割しても並列度はあまり上がらない。

そこでいよいよ並列化プログラムを書きやすいと言われている関数型言語の出番か？

>>26
そうなの？ポインタあったら教えて。

(純粋な)関数型言語ではモナドなんかを使わないと状態が
扱えないから、ふたつのスレッドで変数を共有したりとか
できないから、何らかの工夫がないと普通のスレッドみた
いなことはできないよ。まあ、そのままだと状態が扱え
ないから資源の競合なんかは絶対発生しないけど、殆どの
場合それじゃだめでしょ。

確かに何となく自動並列化みたいなのはできそうな気も
するけど、気がするだけでよくわかんないな。

関数型で並列か。そろそろ Erlang の時代が来るかな。

>>24
>CPU内部のスーパースカラの本数を増やすとか同時実行できる
>命令の種類を増やすために実行ユニットを増やすといった
>方法はなぜとられないんでしょうか。

過去、どんなに頑張っても４並列くらいまでしかいかなかったから。

Erlang
→http://www.kmonos.net/alang/etc/erlang.php#process1
スレッド間のやりとりにはメッセージ通信で実現するみたいですね。

思ったんですが、確かにタスク間のやりとりは共有メモリみたいな
ものでなくて、メッセージ通信の方がスマートな感じがします。
この手のメッセージを行うライブラリにはMPIがあるようですが、
これは完全に独立したプロセス間の通信ですよね。フリーで気軽
につかえるスレッド間通信のライブラリって誰かしらない？

組み込みではμTRONがOSはメッセージボックスつーのがあって
タスク間の通信ができるのですが、Windowsってそういう仕組み
がないですよね。一応SendMessageとかのAPIはスレッドセーフに
なっているけど機能不足だし。

関連スレ

数百のコアプロセッサ用新言語「Baker」
http://pc8.2ch.net/test/read.cgi/tech/1110031339/

日本発、次世代言語：　織田信長
http://pc8.2ch.net/test/read.cgi/tech/1047230229/

>>27
関数型言語では、変数代入でなく束縛（再束縛禁止）が普通なので、
式の前のほうと後ろのほうに依存がなく、
処理系が勝手にバラバラのスレッドで実行できる。
副作用なしなので当然スレッド間の干渉はない。

とよく知らんけど妄想。

副作用なしっていう制約下でマットウにプログラムかけるやつがどれくらいるのか
という問題はある

>>29
Javaが5.0になってからマルチスレッド回りの処理が大幅にパワーアップしたけど
これもマルチコアを見据えてのことなのかなぁとおもった

JavaやC#とか高級言語はどんどんこの辺は容易になって来るでしょうね
逆にC++とかはガリガリかけるけど、つらいものが

>>33
C言語も重い腰を上げて言語レベルでの並列処理を(C++0xとかで)
サポートしようという動きもあるみたい。今まで言語で並列処理
を何でサポートしなかったんだというのはあるけど。

トータルの処理コストは 1.5 倍になるが、完全に並列化出来るから、
実行時間は 2 スレッド時で 0.75 倍みたいな世界が来るのかしら。

C++はBetter Cだからなぁ。正直あんなつぎはぎの言語仕様
ぜんぜん使いたくない。JavaとかC#のほうがよほど洗練され
ていると思う。ヘッダファイルとかローテクすぎ。

>>C++はBetter Cだからなぁ。

馬鹿発見。

>>9
現実のアプリケーションで性能差がどれくらい出るの?
プログラムをチューニングするほどの差がないなら、終了、だよ。

複数のスレッドに分割するのが大変なアプリで、速度を要求するものってあるの?

重いアプリは、
今まで通りに、おおきな粒度で水平垂直に分割すれば、速くなるじゃないか。

そうは言っても、
昔なら遅くなるし面倒だからやらない、なんて感じだった
付加的な処理でも、ＣＰＵの速度向上や生産性の向上で
どんどん付ける様になってる。

そうやってソフトが進化してきたのが、ＣＰＵのコア速度頭打ちで終わってしまう。

>>32
最初からそういうプログラミングを教育をすれば良いじゃない。

Cやアセンブラから入ったＤＱＮＰＧはオブジェクト指向が理解できないけど、
同レベルの奴でも最初からJavaとかで始めると理解できる、なんて話があるらしい。

関数型もいいが、Prologとかの論理型も並列処理に向いてそうな希ガス

手続き型が一番向いてないね。

逐次処理なのがネックだよねぇ・・・。

ただ、今のCPUとOSは、スレッド間の同期が重いと思う。
粒度を小さくしていくと、同期のオーバーヘッドが無視できなくなる。

だから、今のCPUとOSを使う限り、粒度の大きなマルチスレッド化しかない。
そのスレッド分割を人間がやるか、自動化するか、ってことだよね。

よくは知らんけど純粋関数型言語ってのは
入出力に副作用時だけ同期させてればいいのかな？

>>42
織田信長がそうだな。並列論理型言語。
しかし、論理型言語なんて使ってる奴いるのか？

"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 秒)

マルチコアの片方をGC専用にするのはありですか?

"Concurrent Programming Language" の検索結果 約 24,700 件中 1 - 10 件目 (0.37 秒)

そのうちマルチコアって言ってもCPUが4個とか8個とか16個とかが当たり前になるんだろうな。

そしてその後1スレッドを1CPUで動かす時代が来る。

10年後。
CPUのクロックは100GHzになり、16384コア32768コアも当り前になり、
メモリは256Gバイトが3千円ぐらい。HDDは250Tバイトが1万円を切る。
もちろんPCの電源を入れると複数個のOSが同時に起動する。

> CPUのクロックは100GHzになり、

わかってないな、こいつ

>>52
なるだろう。

>>52
電気で動くCPUとも書かれていないから良いんじゃない?

これが技術的に可能になれば100GHzのCPUや256GBのメモリもできるだろ。
ttp://www.nanoelectronics.jp/kaitai/moletronics/index.htm
そのころにはHDDもこれに置き換わっているかも･･･
http://www.nanoelectronics.jp/kaitai/mram/index.htm
究極の並列処理素子。ここまで行ったら･･･
ttp://www.nanoelectronics.jp/kaitai/quantumcom/index.htm

実現してない話はどうでもいい

シングルコアで順調に速くなっていくんだったら、マルチコアなんて要らんだろ。サーバはともかく。
１０年で分子コンピュータ技術が実用レベルに達して商用になるかと言えば、ならない方に賭けるな。
だってCPUの基礎技術は２０年以上変わってないのでは？

￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
　　　　( 　＾ω＾) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　氏ねよ 　　 　 ＼| 　 （　　　　）
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. ｵﾏｴ馬鹿だろ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/

前：デフォルトの名無しさん ：2006/01/19(木) 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
　　　　( 　＾ω＾) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　氏ねよ 　　 　 ＼| 　 （　　　　）
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. ｵﾏｴ馬鹿だろ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/

分子コンピュータの開発なんてもう10年以上前からやってるわけだが

C MAGAZINE 2006年2月号
ttp://www.cmagazine.jp/
デュアルコア・マルチコアのCPUで大活躍
OpenMPで賢いマルチスレッドプログラミング（前編）

いい最終回だった

実際のところ最もパワーが必要になるのは鯖とかエンコとかゲームだから
それらはマルチスレッド化での効果はわりと大きいからべつにいいんじゃね？

>>48
あり
Java5のインクリメンタルGCのデフォ並列世代別GCになってる
通常のアプリが動いてる後ろでガリガリGCしてくれてる
そしてストップが必要になるGCについてもこれもオプションで並列動作可能

あずーるとかみたいにハードのサポートが来るのが一番だと思うけどね
そうでなくとも中間言語系はバックグラウンドでかなり動いてるから
アプリは何もしてなくても2コアでもびっくりするほど恩恵を受けるよ

Emacsのマルチスレッド化はいつのことになるやら・・・

>>61
前編で終るのか・・・。

最終号はなにか凝ったことするのかな

メモリー自体にCPUを乗せて、簡単な処理はメモリーが直接計算する、という案は駄目でつか？
今の技術なら、Z80CPU1万個を一枚のチップに乗せて、並列に計算させるぐらいの事は、
できそうな気がするけどな・・・無茶か？

>>67
消費電力が物凄い事になりそうだぞ？

>>67
似たようなアーキテクチャがNTTのCELLでなかったかい？

オブジェクト指向はクラスタ化のためにやるんだと思ってた・・・

普通の会社はメモリと密接にってのはまず無理

メモリってデータ取り出すだけでどういう動作するか分かってる？
せいぜいメモリコントローラ作ってフロントエンドで処理するしかないよ

Z801万個くらいの性能デイならFPGAでできそうだが

描画メモリーならレイトレースするエンジンがそんな感じだと思った

ようわからんが、これってそんな感じ？
GPGPU
http://pc8.2ch.net/test/read.cgi/tech/1128780920/

>>73
保守乙

よく知らんが、WRAMとかSGRAMとかVRAMとか、その系統じゃね？
もう名前を聞かなくなって久しいが。
まだ特定用途向けに使われてるのかな。

箱○に載ってるね。メモリアクセスだけで、Zバッファや
アンチエリアシングの処理をするのに使われている。

Cellはゲームに特化したプロセッサだから汎用には不向きだぞ。

だねえ、CELLは倍精度演算とか弱いし、特定のメディア用プロセッサであって
汎用CPUにはなれない。
そのかわりDSPの塊みたいなものだから用途が合えばめちゃ速いと思う。

mpeg2やDivXの高品質リアルタイムエンコ、とかは?

デジタル回路で処理してるだけかと

メモリというかレジスタだな。

http://pc7.2ch.net/test/read.cgi/jisaku/1136822334/
マルチスレッドスレに貼り付けてあったんだけど、面白そうなので
ここにも貼っておく。アンチマルチコアって自分だけじゃないのを
初めて知った。PC自作板ってつまんないから全然みないんだよね。

つーか、アンチうざい
新しいのが出てきてそれについていけないやつだと思うけど

2コアぐらいなら、OSとアプリケーションでおおまかにひとつづつ使い切るような感じで、
別にシングルスレッドのアプリケーションでも意味あると思うんだよね。
だけど、４、８とコアが増えてくるとそうはいかない。負荷がかかってるのにも関わらず
アイドル状態のコアが出てきちゃいそう。

>>84
> 2コアぐらいなら、OSとアプリケーションでおおまか
> にひとつづつ使い切るような感じで、

流石にお馬鹿の Windows でも、そんなにＯＳのオーバー
ヘッドはでかくない。シングルスレッドプログラムではマル
チコア/マルチプロセサの恩恵はほぼないので、

> 負荷がかかってるのにも関わらずアイドル状態のコアが
> 出てきちゃいそう。

と言うのは、２コアでも十分ある。

>>85
自作板を見てると、DualはWindowsの体感速度が上がるからっていう理由で
買ってる人が多いみたいなんだよね。IEやエクスプローラを含めたOS全般と
自分の使ってるアプリケーションの両方が同時にスムーズに動くと。
だけど、そういう人たちでもさすがに４個や８個もの多コアは買わないだろうな
という気がした。

>>83
そういうやつが周りに一杯いるけどそういう奴は蹴落としていくしかないと思う。
なんとなく小泉総理が親友を作らず孤独な少年であったというのが分かる気がする

淘汰されるなら淘汰されるで歓迎

>>85
常に一個位アイドルなCPUが居るのって結構重要だったりする。
エンコやら異常事態やらで地獄の様に重い時でもUIの応答が軽いのはストレスを生まない。

それはnice値変えるだけでもいいような

それはniceなアイディアだ

アンチってなんなの？
マルチスレッドプログラムがかけない人なの？
シングルコアの性能をもっとあげる方法を発明できる人なの？
アンチとして存在してる意味がﾜｶﾗﾈ

>>92
今まで普通にプログラムを作ってきたプログラマー達だね。
彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
>>63の言うとおりにガベージコレクションの性能が上がったとしたらそれだけで彼らは失職の危機にさらされる。
まあ、主にゲームプログラマーだけどね。
実際ゲームはシングルスレッド信仰がすごい強い分野だと思う。

ただ、滑稽なのはゲームなんてクリエイティブな分野でそんなに技術屋さんがでしゃばっていること。
本当はマルチコアでどんな新しいゲームが作れるかを考えるべきなのにそれを邪魔するだけの典型的な既得権益者なので
外野としてはそんな害虫どもにはさっさと消えてもらうことを祈るだけだね

＞彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
＞おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち

それで困るのは半端な連中だけだ

きっちっとした技術を積み上げてきたヤシなら、それほど恐怖でもない
むしろ他の連中と差をつけるチャンスだ罠

>>93
ガベコレの性能とゲームプログラマの失職に何の関係がある？

あと、ゲームのどの変の処理にマルチスレッドを導入するべきだと思う？

>>95
GCの性能が上がったら高級言語でもそこそこゲームが作れるようになるじゃないか。
ベンチマークではC++と関数型なんてほとんど変わらないしな。
そうなるとある程度ライブラリとかフレームワーク作ったり業務系と同じようになってくるんじゃないかな?
単純にシングルコアの性能だけでも相当向上してるのだからそうやってやり方が変わって脱落者が出るのでは？。

どんなゲームがいいかは例えばRTSのようなゲームで個々のユニットを複雑なアルゴリズムで動かすとかはどうだ?

D言語の時代ｸﾙｰ?

DってGC性能が低いんだったっけ？
それ以前に仕様がまだ固定化されてないのが気になるが

それとDはスレッドの機能が初期のJavaベースで非常に少ない気がするんだが
今後マルチスレッドプログラミングが増えればこのへんとかネックになってくるかもね
ま、必要になってくれば標準APIとして実装されるとは思うけど

今後スレッドが言語に組み込まれてない環境は厳しくなるよね

>>96
処理速度の向上によって今までC/C++でしかできない・C/C++が望ましかったような
ゲームが、Javaや関数型言語でも実装できるようになるだろう、という予測？

それともイチから実装する難易度が超絶的に上がり、結果必然的に高レベルなライブラリが
整備されるので、高級言語だけでもなんでもできるようになるだろうという話？

後者は理解できるけど、前者は疑問なような気がする。
生産性の向上によって確保した知的資源は、更なる難問の解決に使われるのが普通だから。
（そうじゃないと低賃金労働でしか生き残れない）

豪華なマシンになってPGが楽になる・・・なんてことはなく、
実際は性能を限界まで出しきることを期待されてひどい目に遭うだけ。

>>100
ゲーム業界だとSFC,PS,PS2の時に聞かされた、PS2はまぁ期待にそえんでもなかったが。

ゲームってシングルスレッド信仰というより、わざわざマルチスレッドで
コンテキストスイッチするメリットがあまりないだけじゃないだろうか。
負荷もでかいし同期が必要なものは余計やりにくい。

むしろ並列演算言語が欲しい所だな
つ〜か、マルチスレッドである必要は全く無いんだよ
並列演算が可能なら、シングルスレッドでもかまわない
その意味では、昔はＭＭＸに期待したわけだが・・・

>>99
どっちかというと前者かな?Javaや関数型がそのまま使われるかは知らないけどPS3でオープンソースな人たちが勝手に実験始めるでしょ
低賃金労働から逃れるためにはライブラリ屋になるのが自然。ライブラリ屋が儲かるか知らんけど。

後者は手動での最適化するのが本当にできるのか疑問視していて、並列化言語を実用化させたほうが早いと思ってる。

マルチスレッドによる並列性の引き合いにMMXによる並列性
を出すのはどうかと思う。

>>103
バス幅とバスクロックの壁は厚かった

>>105
下手にマルチスレッドを使うよりは、並列演算を行った方が処理が早くなると思わないか？

１０個のコアがあるのなら、１０個別々に処理するよりも、
同時に同一処理を行わせるのもアリだと思うんだよな。

>>104
するってえと高賃金乙な国内の業者さんたちは結局ライブラリだの物理モデルだの
並列処理向き言語＋プラットフォーム開発だの、GCがどうとかいうレベルではなく難しい
ことをやらざるを得なくなって、「余った知的リソース⇒難しい仕事」という流れになるような・・・

成功しないのでそういう流れにはならない、という可能性も高いけど。
数学はインド人の方が得意そうだし。

>>107
いやだから用途が違うと思うんだけど。MMXつかって速くなるところに
マルチスレッド使っても速くなるようなケースは限られると思うが。
（逆もまた然り）

>>110
コアがたくさんあったとしても、一つのスレッドの扱えるコアは一つ？

>>111
話の流れがわからん

>>103
NeoMagic の MiMagic6 なんかがその路線で、16x16ピクセルの画像を
対象とした演算なんかを1命令でできる演算ユニットを積んでます。

中〜大規模SIMDってのも、応用範囲は限られるものの確かに面白い。
けれどもクロック上げて水で冷やしてガンガンパワー使えるなら不要な
手法なのかなという気もしないでもない・・・

　小さいモノの中ではダイナミック・リコンフィギュアラブルLSIとかが
そういう思想のもののような気がするけど違うかもしれない。

>>112
つまり、10個のコアがある場合に10個演算する場合は、10個スレッドを立ち上げて、
10個同時に演算して、演算が終われば元のスレッドに戻せば、10倍の速度で演算できるのでは？
って事。

>>114
しかしバス幅とバスクロックの壁は、非情なまでにも分厚かった

>>114
それふつうにマルチコアの利点

今後はどの点が並列処理できるかという設計レベルの重要性がますわけだ

今まではそのCPUにあわせてどうすれば少ない時間で処理できるかの最適化をする
という点だったからね

JavaのコンカレントAPIみたいなのが普及せんときついかもね

>>114
俺が言いたいのは、SIMDは局所的な並列で、マルチスレッドはもっと大域的ってこと。

MMXは隣接ピクセル間の並列性、マルチスレッドはブロックごとに区切るような
（マルチレンダリング）用途でしょう。俺なら同時に使うけどね。どっちかが
肩代わりするもんじゃない。

関連スレ追加
http://pc8.2ch.net/test/read.cgi/tech/1099819556/

>>117
スレッドのというか処理の粒度の問題って解くべき問題との関係が深すぎるからこのスレのタイトルだと混乱するかもしれない。

スレッドとマルチコアは何の関係もないだろ。

マルチプロセッサ(SMT含)を想定してのマルチスレッドプログラミングと全く同じだもんな。
プロセッサ間の通信速度や、外部(メモリ)との通信速度が違う、というだけで。

>>109
つまり技術的にはインドに負けることが前提なわけですな。

マルチコアのマルチスレッドって、通常のマルチプロセッサに比べて
注意するところあんの？　ハイパースレッドプロセッサだったら
スピンロック問題とか言うのがあった気はするけど。

>>86
自作板のあれは、多くの場合、負け惜しみです。
体感速度が云々と言ってる人達は、遅いCPUをdualにしています。

本当にCPU速度が必要な人達は、
マルチスレッドで動くアプリを使っていて、
ユーザの操作のためにCPUが丸々1個アイドルで待機しているのでレスポンスが良い
なんてことにはならないのです。

>>102
ゲームはCPUを他のスレッドに譲るという概念がないから。
ビジーウェイトとか平気でやるからな、ゲームプログラマは。

>>107
並列演算を行った上で、
さらに、
マルチスレッドですよ。

できるやつは新しいのが出てきてもいい物を作る
できないやつは昔からの作り方にこだわり進歩しない

ゲーム製作スレのオブジェクト指向いらねという話と似てる

>>125
そんなアホはさすがに居ない。
、、と思いたいが、居る所には居るのか。

>>127
君みたいなのをみるとイライラする。

みんなマルチコア、マルチコアいっているけど、はっきりいって現状、中身がないって
いっているつもりなんだけど。マルチコアの性能を生かした設計というのは難しいし、
まだそれは誰も解決していない。それを簡単だというならそれをちゃんとわかるように
それをどうやって解決したか書いてくれ。ここはそれを解決するためにみんなで考えま
しょうっていうスレだ。

マルチコアをマンセーするのとその技術をマスターするのは、天と地ほど差があるよ。
マンセーするだけでマスターした気になっているのは中身が無い。

もうちょっと真剣に技術に対して考えてくれ。

>>129
>はっきりいって現状、中身がないって
>いっているつもりなんだけど。

これって「一般人の使うデスクトップに関しては」って事かな。
範囲を限定しないと、議論にならないと思われ。

>>130
最初から使い道がはっきりしているHPCやサーバ用途を除いては、です。
適確なつっこみスンマソン。

>>125
ジャンルにもよるが、ゲームってのは譲り合いの最たる分野だよ。
処理落ちと戦うアプリが他にどれほどあると思う。ただ他のプロセス
のことを考えるのはPCやらんとわかりにくいね。

あと、ユーザの立場からデュアルコアまではメリットがあるといのも了解事項?

デュアルコアのメリットはスループットとレスポンスタイムを両立出来る事。
裏で重い処理を走らせていても（要スループット）、表の処理のレイテンシを
少なく出来る（要レスポンスタイム）。裏の処理の例としては、ダウンロード、
スパムフィルタリング、エンコード、ウィルススキャン等。表の処理の例としては
GUI 描画等。今時のウェブブラウザとかは既にマルチスレッド化されているし。

その上で、プログラマの立場から、メニー／マルチコアのメリットを最大限に
活かせる様な設計とは何かという事だよね?

>>129
PCがまた売れるようになってきた原因がいわゆるTVつきでキャプチャとか出来るパソコンなわけだが
これらはデュアルコアの恩恵が非常に大きい

コンシューマレベルでも十分恩恵受けてると思う

それにゲームでもマルチスレッドを使うことによって、プログラムがより簡単になるとかあるんだよ

とりあえず4コアまでならコンシューマレベルでもかなり恩恵は出るとおもうけど
8コア以降は俺はしらね

>>134
>プログラムがより簡単になるとかあるんだよ

例えば?
ネットワーク回りを別スレッドにするとか、そういうの?

>>135
そういうこと

サウンド回りにしてもね
シンプルになるよ

>>136
その辺はシングルプロセッサでも別スレッドだべ？

サウンドやネットワーク周りをメインスレッドで動かすのはちっと
考えられん。

昔のゲーム機でサウンドをVSyncで処理している事例はあるにはあったけどね

>>137
だね

BGMにしろ通常圧縮フォーマットからそれをPCMデータへ展開、キューに突っ込む
キューから取り出してデバイスへ転送
の2スレッド構造にすれば非常にシンプル

効果音にしても別スレッドでキューからのコマンドを下に転送支持とか
まぁマルチコアになって楽できるべ


>>139
つーか割り込み使ってる時点で別スレッドと同じような動きだろう

やっぱり、プログラム板的にはマルチコアだからって何ら特別なことは
なく、マルチスレッドでプログラムを書けばよい、でOK？

>>140
＞の2スレッド構造にすれば非常にシンプル
分けると同期が逆に面倒な気がする。読み込む部分が
ネットワークからのストリーミングだったらおっしゃるように
二段構えになるけど、それはネットワークのレスポンスが
タイミング違いすぎるから。

＞つーか割り込み使ってる時点で別スレッドと同じ
ぜんぜん違う。サウンドプログラムは中でループ回す
構造にできない。サウンドプログラムもイベント駆動型
にする必要ある。

とはいえ大違いでも、大差ないと言えば大差ないが。

>>141
それじゃあ話がおわっちまうが確かにその通りじゃね

>>142
だから同期のライブラリが充実している高級言語が有利なんだよ

そもそもスレッドだってループするように作ってなくていいわけで

>>144
高級言語という話の流れはどこから？

＞そもそもスレッドだってループするように作ってなくていい
ループしないってことは割り込みみたいに毎度毎度スレッドを
生成するのか？　そんな馬鹿なことしてるとは思えないから
一度生まれたスレッドを殺さずに使い続けるのは何かしら中で
ループしてるってことだろ？

>>145
スレッドプールとかあるし、ユーザーは意識させないよ

高級言語ってのは上のほうででてたJavaとか.NETとかそういうレベルの話
GCの大幅な速度上昇とふくめて有利に働くことが多い

Cとかでシングルスレッドでガリガリにチューニングしたアプリより
マルチスレッド使って適当にのほほんと書くアプリのほうが早いとか
わりと普通だからな

んな細かいことはどーでもいいから、
読み書き速くするとか、読み書き中にゲーム続行できるようにしといてくれ。

そりゃプロセッサが複数あればそうだろう。依存関係のない部分
は簡単に並列化できるからね。

あと、スレッド内でループしない構造にするメリットってある？
記述は明らかにイベント駆動より簡単なのに。

>>147
ごめん、難しいんだ（笑）　まあ、非同期読み込みは
サポートするようにはしてるよ。でもこの辺はマルチ
プロセッサでなくても恩恵受けるところだね。一方が
極端に遅いデバイスを扱う場合は特に。

>>148
スレッド数をスレッドプールでコントロールする場合ループさせないほうがいい

スレッドプールってサーバなんかのトランザクション処理以外にも使うんだ?
どんな用途で使ってるの?

スレッドプールはイベント駆動との中間みたいなもんか。

中で滞るものがあってもある程度緩衝材になるってのが
シングルスレッドの純なイベント駆動に対するメリット？

同時に資源の消費しすぎを抑えられるってことね。

イベントディスパッチの代わりにプールからスレッドを起動するのか。何か重そうな。

例えば、Winsock2系で(非標準だけど)最速といわれているIOCPは
スレッドプールを利用した仕組みだよ。

>>151
プールに既にあるから起動しなくて良い。ので高速。
現状のシングルスレッドでのイベントディスパッチャが、
スレッド数１のスレッドプールに相当します。

例えば10,000程度の物をアレコレ処理するとき、
10,000個スレッドを作らずに、論理CPU数x2程度の
スレッドに効率よく処理を分散できるとか。

ふぅん、面白そうだね。ちょっと調べて実装してみたいな。
ｻﾝｸｽ。

とはいえ話にあったBGMにはスレッドプールは向かないんじゃね？
詰まっていて鳴らせませんじゃすまないし。

元々リニアにスケールする処理→スレッドプール
特殊な処理をメインスレッドから外出ししたい→普通にスレッド作る

...なんじゃないの。

スレッドプールはシングルスレッドでもいいんだけどマルチプロセッサ
に不可分散させたい時に便利だってことかー？

簡単に別スレッド使える構文が欲しい。C++では何度も導入の
意見が出て却下され続けてるそうだが、

make_thread for(i=0; i<100; i++){
hogrhoge....;
}

って書いたら勝手にスレッド作ってメインは続行、for内は
独立したスレッドで動き出すみなたいな。

CreateThreadしたりオブジェクト作ったりﾏﾝﾄﾞｸｾ

現状のsmpのままだとメモリのボトルネックがもっとひどい事にならない？
コア数が増えるとクロスバースイッチとか導入するＰＣも出るのかな？

>>159
シングルコア･シングルプロセッサの場合でも、
とあるスレッドがI/Oで待たされてる間に他のスレッドで
他の処理ができる（かもしれない）、という普通のマルチ
スレッドの利点も提供される。

イベントやトランザクションを処理するのに用いる。
スレッドは、1粒度の処理を行ったらプールに戻って
次に利用されるまでイベント待ちなどで待機する。
ずーっと続くセッションみたいなものの処理には無意味。

普通は>>155の「論理CPU数x2」とかよりもっと多くのスレッドを使う。

>>160
スレッド生成クラスとラムダで事足りるからじゃないの？
make_thread終了の同期とる方法をOSから隠蔽する方が面倒くさそうだし。

＞スレッド生成クラスとラムダ
それなあに？

どっちかっていうと閉包欲しいよ閉包。
ちょっとスレッドとかにも便利だよ。

make_thread foo();

ってやったら別スレッドで関数起動してくれるのが欲しい。

http://216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt

BGMの補充に関してはいわゆるブロッキングキューでいい
充填する側はキューサイズがいっぱいだとキューがあくまで待つ
そして取り出す側はキューが取り出せる状態になるまで待つ

取り出す側が待つようだと音が途切れてるので意味はないけど、
充填する側をキューサイズでコントロールできるとバッファのサイズを
コントロールしたり自前でリングバッファ持ったり待機させたりとか
面倒なことはしないですむ

ロジックだけに集中できるってことだーね

こういうのをJavaとかは用意してる
ほかにもカウントダウンラッチとかサイケリックバリアとか優先度つきキューとかもある
もうロック処理も優先順位つけたり細かく動けるようになったし
使い方は難しいがロックフリーでスレッドセーフのアトミックもある

ソフトに限らずハードも異なるクロックでキュー使うの普通だし
そういう考え方は必要だと思う

おいしいところは真似しないとな

で、まあ、今話題になっているような内容は
マルチコアとは直接関係無く
普通にマルチスレッド、或いはマルチプロセッサに関する話題でして。

↓以下ループ

一々、茶々入れんと気が済まんのか。御主は。

普通にマルチスレッドの話でいいんでないの？
スレの名前も並列化だけだし。
マルチコアが普及することによって・・・というだけでしょ。

あっちよりこっちが賑わってるのはスレタイの勝利ですか

>>172
あっちってOpenMPスレ？

マルチスレッドって名前付いてるスレ

まあ、賑わってるって言ったって、住人の顔ぶれは
ほとんど変わらないと思うけどな。

あっちはC＋Win32ベースでしかも基本的なところから先に進んでない
単純な排他制御だけではお話になりませぬ

ロジックとしてどういうのがいいかという話のレベルまでいってないんだよな
>>1とかみてもこっちのほうが広い目というかもっと上位の話題にみえる

マルチコアを生かすのに簡単なのがマルチスレッドってだけで
マルチスレッド以外で現実的な並列プログラミングの方法があれば・・・というところだろう

このスレッドの場合は極端な事を言い出しても、
まだまだ使い古されて無い技術だから叩きづらいんだよ
だから好き勝手に色々な事が言える

>>164
多分、どっかの誰かが作ったスクリプト言語だったと思う

まあ結局、並列化を効率よくやろうとすると、自前でスクリプト言語を作るか、
現時点で存在するスクリプト言語に頼るかの、二者択一になってくるんだよな

あるいは、同期機能を駆使してC++で作るとか・・・

でも、自前でスクリプト言語を作ったりすると、
わざわざマルチスレッドにする必然性が、
高速化以外には全く無くなったりする罠。ｗ

Javaもまあ、スクリプト言語の一種といえば一種か

>>160
一カ所のメモリーに対する多重アクセスを防ぐのが難しくなるからかと

>>178
Boost か何かのライブラリの機能でしょ。

>>179
スクリプト言語は、GC という並列化と相性が悪い物を抱え込む事になる。

何でマルチコアの話で「スクリプト言語」がでてくるんだ？

気にしちゃダメ

>>186
スレッドの管理が面倒だからかと
面倒な処理は、誰かが勝手にやってくれる方が楽だからな

>>160
Javaならすぐかけるのにね

そろそろC++も言語にスレッドを組み込んでしまって、何らかの
シンタックスシュガーが欲しいところ。

たしかにJavaだと

Thread t = new Thread(){
　public void run(){
　　for(int i=0;i<100;i++){
　　　hogehoge
　　}
　}
}.start();

hugehuge//メインスレッドの処理
t.join();//おわるまでまつ

とインナークラスでかけるな
スタック変数とのやり取りでは面倒なことになるが

スレッドの話はスレ違いだろ。スレッドだけにスレ違いw

>>191
へ〜、Javaだと仮想関数をそんな風に作れるんだ・・・

マルチコア時代もJavaで決まり！！！
ドントネット死滅ケテーイ（禿藁嘲笑）

>>191
記述は楽なんだけど、外側のローカル変数を受け継いで欲しい。
中の処理にパラメータはどうやって渡すのがお行儀いいの？

>>193
仮想関数？

>>195
受け継ぐだろ。finalにするだけで。
final必要にしたのは、リークが見つかりにくくなるからとSUN社員のブログか何かに書いてあった。

ぜんぜん並列と関係ないな…。

final宣言されたローカル変う右派コンストラクタでコピーされて渡されてる
そもそもfinalは変更が不可能なのでお手軽に変数を渡すわけにはいかないよ
普通にクラス作ればいいだけだけどね

>>191
>>160の例はそういうことじゃなくて、i=0からi=99までの初期状態を持つ
100個のスレッドの生成と実行と待ち合わせが簡易な構文でできればなー、
という話なのでは？

そうじゃないならCでも関数一個定義するだけだからそう面倒じゃないし、
このスレ的に迫力ないし。

>>196
ホント？Javaっていつのまにかクロージャが使えるように成ってたんだ。
世の中には信じられないようなことが起きているなあ。

Javaのそれをクロージャと呼ぶと、変な人が湧いてくるよ。

>>133
お前はスレッドの優先度を設定しないアホプログラマか。

Win32限定なら、QueueUserWorkItem()一発かな。
自動的にスレッドプールを作って関数を実行してくれる。

>>198
匿名内部クラスでぐぐれ

マルチスレッドなんて時代遅れ。
これからはマルチコア。これだね。

>>199
コンパイラ・スクリプトエンジン相談室によく出没するあいつらか？

Lispこそがすべての起源。
Lispを知らずしてプログラミングを語るべからず。

>>200
いや、プライオリティの問題もあるが、それだけじゃない。

マルチコアだと重いタスクを裏に回せるのがメリットかね。
シングルコアで重いタスクを裏に回しても、裏のタスクの
進行が遅くなるか表のタスクが足を引っ張られることが
多い。

マルチコアなら重いタスク専門に１コア割り振れるから
表はノーペナルティ（に近い速度）で動ける。

まあ重いったって基本的にはI/Oとメモリを大量に使う
処理ぐらいしかないんだけどな。

×マルチコアなら
〇マルチプロセッサ(HTT含)なら

で、結局、バス幅とバスクロックの壁はどうにかなりますか？

>>206
いくらプライオリティが低くても、
一旦CPUを割り当てられたら、割り込みがかかるまで、一定時間はCPUを占有する、
という問題はあるけれど、ユーザのインタラクティブな操作は割り込みをかけるので問題なし。

スループットを犠牲にしてでもレスポンスを良くしたければ、
CPUの割り当て時間を短くしてしまうのも手ですよ。

たとえばWindowsの場合は、HALによっては変更をサポートしてる。
ちなみにデフォルト値がWindows2000の場合、
マルチプロセッサだとシングルプロセッサの1.5倍の時間に設定される。
WindowsXPの場合、シングルプロセッサでも、マルチプロセッサと同じ時間に設定される。
WindowsXPがモッサリな原因の1つが、1.5倍に設定されたことだよ。

>>211
アフィニティを下げたら各コアのキャッシュが汚れるから、デュアルコア時のメリット薄いんじゃないかな。
シェアードキャッシュなら良いんだろうけど、普通 L1 はシェアしないでしょ。

インテルのデュアルって肩並べて爆熱してるだけのツインプロセッサじゃないのか？

IntelCoreしらんのか

しらんがな

>211から>212へ行く話の流れがわからない。
>212は何に関するaffinityのことを言っているの？
CPUの割り当て時間との関係は？

Windows では Thread Affinity って言葉は使わないのかな。

と思ったが、>>211 は CPU Quantum の事を言っていたのか...
ｽﾏｿ。勘違いしてた。

Windowsでアフィニティと言えば、
プロセスやスレッドを特定のCPUだけにしか割り当てないようにアプリがOSにお願いすることだよね。

それは UNIX で Processor Bind と呼んでる機能かな。

名前を前例に倣わんのはMSの悪いところ。とはいえスレッド関連は
NTのほうがUNIXより早いんかね？

お前ら並列プログラミングを語る前にLispについて学べ

>>221
なんで？いまの並列化言語は論理型のほうがすすんでないか?

Lispを知らずしてプログラミング言語を語るべからず

ム板にいながらこんな常識すら知らないとは・・・

>>223
各所で Lisp を貶めるのは止めてくれ

>>223
おまえみたいなのがいるからLisp使いがバカにされる

>>223はこういう念仏を唱えるだけのアホウがいる、という話かと思ったら
アホウ当人だったのか。

こいつ、どうせLispスレじゃ何にもレスしてないよ。
以前もRuby使えないくせにあちこちのスレにRuby万歳突撃やってた基地外がいたが、
同一人物かもしれん。

そんなことしてるのがリアルに居るとは信じられんが、ｶﾅｼｽ

正直なところ、Lisp知らん奴が語ってるのって、幼稚なんだよね。
本質でない、些細な部分に無駄に労力を費やしてるって感じ。
議論も設計もコーディングもスマートにやれるのがLisp、
これを学ばない手はないね。

>>228
>>224

Lispって何でもありすぎる。あれならマシン語で
プログラミングしてるのと代わらんような。
適度に制限されたフレームを提供するのが言語の大事な役割
というキガス。

>>230
>適度に制限されたフレーム

こういうのは時間とともに綻びが生じて来るから、新しいパラダイムが来たら
無理矢理建て増しするハメになるよ。既定のフレームに沿わなくてはいけない
環境では、未知の問題への適応能力も自ずと低下してしまうから、Lisp の
出自を考えると受け入れられないだろうね。

とは言っても、Lisp は元祖超高級言語なわけで、マシン語と比較する物では
無いでしょう。適度な強制が好きなあなたには Python をお勧めします。

あ、それから…、

ここは並列化のスレなんで、言語の善し悪しの話は完璧にスレ違いです。
お引き取りください。

俺はlisp知らんけど、
もし本当にlispが並列処理向きだったとして


現状のlispインタプリタは、マルチスレッドで並列処理してるのか？
仮にマルチスレッド動作しているとしても
並列可能な処理数はかなり大幅に増減すると思うのだが(for_eachとかあったよな？)
全部並列にやろうとするのか？スレッド数も増減させて。

まあ、スレッドプールとか使ってうまくやっているのかも知れないが。

>>232
>もし本当にlispが並列処理向きだったとして

Common Lisp の事なら、そもそも ANSI 規格では並列化は考慮されていない。
フリーの実装に限って言えば、マルチスレッドのコンパイラは少ない。
並列／分散処理の研究に Lisp が使われてたりはあったと思う。

並列化言語の側も盛り上がってないし、今の並列処理の枠組みは pthread とかに
依存しているんで、今後も C とか Java でどうするかって話が主流なんじゃないかな。
関数型言語にもちっと頑張って欲しい所。

どの言語がいいだの悪いだのはモノ作れるようになってから語れ
('A`)

自分で言語を作るのは、手間がかかるんだよ。ｗ

続きは「コンパイラ・スクリプトエンジン」のスレッドでやらないか？

別に実装の話まで入り込む必要は無いんだけど、並列化を支援する言語のフィーチャーに
どんな物があるのかは興味がある。

>>237
そういう話題は、「マルチスレッドプログラミング相談室」で。

あっちは実践、こっちは理論や研究レベルってことで、こっちでもいいんじゃない？

並列化の支援というか、上にもあったと思うけど、
関数型言語なんかはプログラマが並列化なんか気にせずに並列化できたりする、理屈の上では。

これなんか実際に、後から何スレッドで動かすか指定するみたい。
http://www.haskell.org/haskellwiki/GHC/Concurrency#Multiprocessor_GHC

と思ったら普通にプログラムの方でも指定するみたいだな。
並列に出来るからって勝手に全部並列化したらオーバーヘッドの方が大きくなっちまうか。

ウザいLisp厨のせいで折角のふいんきが台無しだな

スレ頓挫か？

なんかネタがねぇ。だれかネタ提供してくれ。

http://www.coins-project.org/
そうそう、こういうのを最近みつけた。
日本のコンパイラ界の重鎮、中田育男先生とか、その他にも
Javassistの千葉滋先生とかオールスターメンバーっぽい。

SIMDによる自動並列化や、自動的に普通のコードをOpenMPに
変換してくれたりするらしい。関連した論文もたくさんでて
いるみたい。

個人的には大学で研究やっている先生方が、どの程度の実用的な
コンパイラがつくれるか注目している。マイクロソフトやインテル
なんかとも張り合えると思っているんでだけど、期待しすぎ？

たまにはageとく

　　 　 -‐-　　
__ 〃　　 　 　 ヽ
ヽ＼　ノﾉﾉ）ﾍ)､!〉
　(0_)!　(┃┃〈ﾘ　 はわわ〜マルチが245ゲットですぅ〜〜
　 Vﾚﾘ､" lﾌ／ 　　　
　　　　(　￣￣￣《目
　　　　|　 ＝＝＝《目
　　　　|＿＿|　　　 ‖
　　　∠|_|_|_|_ゝ 　　‖ 　　　　　　∧＿_∧
　　　　 |__|_|　　　　 ‖ 　　　　　 ┝・∀・┥ﾄﾗﾗｰも2ｹﾞｯﾄ。
　　 　　|　| |　　　　 ‖ 　　　　　 （　　　　 ）　
　　　　 |__|__|　　　　 ‖ 　　　　 　|〓 | 〓|　 　
　　 　　|　＼＼　　 皿皿 　　 　 （＿_） ＿_）.　

トララーがﾜｶﾝﾈ

OSがプリエンプティブであればマルチコアかどうかは
さほど問題ではないと思うのだがどうか。

>>247
それは必要条件であって十分条件じゃない。

そもそも何に対して問題無いって言ってる訳さ?
スケジューラがプリエンプティブに出来ていたら、カーネルが
ジャイアントロックしても問題無い?

大体、マルチコアつっても色々ある訳だが、どのマルチコアを
指して問題無いって言ってるんだ?
非対称コアなのか対称なのか、キャッシュは共有されている
のかいないのか、スレッディングはあるのか無いのか、それは
SMT なのか CGMT なのか FGMT なのか??
NUMA なマルチプロセッサとマルチコアじゃ最適化ポイントが
全然違うんだぜ。

それに、マルチコアは OS だけの問題じゃ無い。コンパイラは
CPU の実装を理解して最適化を掛けているのか、アプリは
MT でスケールするように作られているのか???

ネタ振りとしてはこれくらいで良いか?

シングルスレッド最強

シングルスレッドで作って、適当にexecすればいいじゃん。
何を悩んでいるのかわからない。

もう面倒くさいよ。

おわりか

http://japan.cnet.com/news/ent/story/0,2000047623,20097056,00.htm
Cell向けにOctopilerツールが発表されるらしい。
どういう形で支援するか謎だ。そのあたりの情報が外部にも出してもらえると、
今後のマルチコア向けアプリケーションの開発に少しは参考になりそう。

聞きかじりなんだけど、Cellってバス予約という機能があって、コアごとに
あらかじめ必要なバス帯域をキープできて、一度に複数のバスアクセスが
集中しないようにできているみたいだね。バス帯域の問題はどうにかして
欲しいけど、PCでは同様の解決方法は難しいかな？

仕事でCellとか触れる人はいいね。自分は関係ない職種だから触れません。

マルチコアでマルチスレッド処理が平気でできれば、これから食いぶちがありますあ？

なにやっても食っていける。重要なのは仕事取る（就職含む）対人スキル。
プログラミングはそれからだ。

とはいえ、金出す側の鼻が利く場合に備えて腕は磨いとけ

ドカタ乙

特に意味はないが、保守っとく。
ちょっと古いけど、Timed Calculus of Communicating Systems つーのを調査中。

保守

>>257
googleで検索したけど、TCCSって何ですか？TimedがつかないCCSなら
たくさん説明があるんですが、似たものもしくは同じものなんですかね。
Calculusいうぐらいだからπ計算とかの親戚の計算モデルっぽいのは
わかるんですが。

ここを読んでいる人でプロセス代数とかやってる人っています？

そりゃCCSなら説明がたくさんあるだろうな・・・

>>253
OpenMPのpragmaを流用するみたい

TextSS　のWindowsXP(Professional)64bit対応化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

>>261
そうなんですか。できることは限定されているような気がしますが、
普通にCellに最適化されたプログラムを書くより大分楽にはなり
そうですね。

http://it.nikkei.co.jp/digital/news/index.aspx?i=20060320ew000ea
やっぱり開発が難しいそうですよ。新しいノウハウが必要らしい。予想通りだ。
マルチコアはいいけどソフトウェアの負担は大きい。

86とか汎用の石のマルチコアが難しいというのと
Cellが難しいというのとはたぶん難しい場所が違う

CellはPS2の延長と考えればすっきりするしその程度

>>265
それが新しいノウハウだろｗ
PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど

８６系ってＣＰＵの思想があれだから、マルチコア化を困難にさせてるんだよな・・・

↑
こういう知ったかがわくのはどうにかならないのか？

>>267
思想がアレなのはiApx432だろ。

レジスタが専業化されてるってやつだろ？
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。

uOp fusion のコストが高すぎるといってるのか？
俺には的外れに思えるが。

↑
こういう知ったかがわくのはどうにかならないのか？

267が論旨を明確にすればいいだけの話。

デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない？

という意味だと漏れは思う。

つまりメタセコイアは生きた化石だということか。

鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。

そうでもない

ho

>>276
2-4 並列くらいでいいんだから余裕じゃ。
大変って言ってる奴が居たら、それは「ﾏﾝﾄﾞｸｾ」って意味か、「もっと金寄越せ」って
意味かのどちらか。

Objective-C + Cocoa なソースで OpenMP って使えるの??

Cilkってどう？

ｲｿﾃﾙが発表した４コアってプログラミング的にはどうなん？
性能を活かせるコンパイラってあるの？

80コアか・・・
機械的に最適化できる方法あるのかな？
ttp://techon.nikkeibp.co.jp/article/NEWS/20060927/121563/?ST=edaonline&ref=rss

まぁ数年間は OpenMP 使ってチマチマ並列化するのが手っ取り早いだろーね。
でも 80 コアの時代には言語レベルで並列化/分散処理をサポートした
新しい言語が主流になってると思う。
そうじゃないとプログラミングがしんどくなるね。

そこまでしてx86である必要がないような。

互換性が重要だからね。
x86系は（PC/AT互換機が業界標準になったおかげで）業界標準になったから過去の互換性切れないんだよ。

ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。

そういうわけに行かない業界と素人と過去の遺産の都合を考えろってこと。
カーネルやドライバ部分なんかはCPU変わったらほぼ完全に書き直しだろうし。
CPUごとに使用するコンパイラ＆ミドルウェアが変わることで開発やサポートのコストは跳ね上がる。
(商用ソフトがほとんどの場合ライセンス上の理由でソースコード公開できないことくらいは分かってると思うけど)

×公開
○開示
だな。まぁ公開も商用である限りまず望めないだろうね。

倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw

>>290
ユーザーが増えないから売れそうもないので対応しない
バイナリが流通しないから新しいアーキテクチャのユーザが増えない
以下繰り返し

この悪循環が始まるだけなんでそういう事を言われても困る。

「対応しないと売れない」の間違いじゃね？
つか、対応せずに済むというのはユーザー側の思考で、本来なら企業のビジネスチャンスのためにも積極的にハードウェアアーキテクチャを変更するべきなんだよ。
儲かるのはマイクロソフトだけ。っていう図式が何を意味しているかしっかりと考えてみろ。

OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・

>>293
それは使い方間違ってるだけだろ。
俺が反論してやるからURLｷﾎﾞｿ

そいつの考え方がおかしいんじゃねーのかどこか知らんが

>>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。

挙動不審

マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
あるいはSETI@homeみたいに部分に分けて処理させるのはどうなの？
あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）

というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？

volatile最強宣言ｋｔｋｒ

> マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
釣りですか？

> あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）
プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。

> というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
分散処理の研究が進んでいるのと、それ様のプラットフォーム(MPIとか)が
整備されているから。何も考えずに無為にやっているけど大丈夫なわけでない。

訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
↓
> プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。

ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか
学者さんは嫌いそうだが必要になりそう

おお、こんなスレが。
並列プログラム用のライブラリを作成しています。（C++/Unix用）
http://pards.sourceforge.jp/
よろしければ御意見下さい。

>>166 の人のお望みの通り、SPAWN(foo());とすると関数fooを並列に実行します。
スレッドじゃなくてプロセスだけど。
プロセス間の通信、同期はSync<int> a;のように宣言した変数に対して、
a.write(1), a.read() のようにすることで行います。readはwriteが終わるまで
ブロックします。

実用的な例として、bzip2の並列化も行っています。
詳しくは上記URLをご参照下さい。宣伝失礼致しました。

sureddo版を作る気はないのかえ？

スレッド版？ >>304
スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
温床になっているという主張なのですよ > このライブラリ
グローバル変数触るだけでMT-unsafeになるので、スレッドを使った
既存のプログラムの並列化は難しいのですが、プロセスはメモリ空間を
分けるので、そんなことは無いと。
もちろんその分オーバヘッドはあるのですが、最近のOSなら我慢できる範囲では
無いかと思います。
# とか言いながらスレッド版作ったりして

なるほろ。

コードはそのままで、
デバッグ中は別プロセス、リリース時はスレッドで実行できるとかだと
超カッコＥかもしれませんな。

ぬー、でもあんまり差が出ない気がしてきた。

>>303
ネットワーク越しあり？

あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。

実際にどれだけパフォーマンスに差がでるかわからないけど、
スレッド版を用意してくれると実際に使う人がベンチマークが取れて
プロセス版かスレッド版かどちらかを選択するか判断できていいですな。

> スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
> 温床になっているという主張なのですよ > このライブラリ
さすがに含蓄のあるお言葉ですな。

>>307
いや、SMPだけを対象にしてます。
MPC++/SCoreとか、ネットワークで接続されたコンピュータを
SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;

JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか？

>>310
JAVAはマルチスレッドにしても速度は上がらんよ。

>>310
速度を気にするならJAVAは問題外

てっきり　>>194　みたいなことが書いてあるから…
.netは対応？済みらしいがマルチコア環境じゃないから試せない。

マルチスレッドは速度を向上させるのが目的ではないと思うがなあ

サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン？は既にやってるとこもあるみたいだけど。

>>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。
マルチノード、マルチインスタンスにはした方が良いけど、
かなりの大規模ノードじゃなければ十分。

>>285
x86である必要があってx86なのではなく、
数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。

>>314
何が目的なのか、ハッキリ言ってよ。

>>316
クライアントが同時に複数いる状況で性能を要求されるサーバならば、
2コアとか4コアくらいなら、
同期する必要のない部分と同期する必要がある部分に分けるだけで、
十分だったりするしね。

>>315
XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、
パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。

>>310
他の言語と同じように恩恵はあるよ。
恩恵がないのは遥か昔の green thread の頃かな。

Intel，80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
ttp://www.4gamer.net/news.php?url=/news/history/2007.02/20070213183701detail.html

トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。

職場の女がニコニコしながら、
「上司の○○さんが呼んでいたので『地球の平和を守りにいってます！』と答えておきましたよ〜」

死にたい気持ちになった。

へたくそなコピペじゃねーぞ！
あまりにショックなので、こんな過疎スレに書き込んでいる。
今夜は一人で飲みたい。

↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる！

オッス、オラうんこまん！
地球防衛隊員ってのをやってるんだ。よろしくな！

>>324
恥ずかしい自演乙

>>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。

それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん（結構かわいい）がレジで支払いしてるトコだった。そのレジ台に置いてあったの
がイチジク浣腸の１０個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入
れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。
噂を流したら俺だってわかるし山下さんもかわいそうだから。

動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの？

linuxでやれ。

やってみる価値は非常にありそうだな。

つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ？

>>331
たぶんそうなんじゃない。
動画は前の画像の圧縮して解凍したものを使うから
ある程度の時間の動画をひとつのスレッドにしたほうが
効果ある上に作るのがとても楽だね。

キャッシュ効率が下がるんじゃない？

下がるだろうね。

キャッシュ重視で1枚の画像を複数のスレッドでMPEG圧縮する。
手間かける余裕があるかどうか。

CPUのマルチコア化を一般ユーザが使うようになるころは
メモリとかHDDの性能はどうなるのかしら。

エンコードに必要なワーキングセットをＮとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね
・・・そこまでやるか？

ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい？

ダンゴ様の許可があればいい

>>336
Xeonは除外?

>>336
どんな話がどう濁されているのか具体的に。
そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。
>>338
XeonもCore2ファミリじゃね?

初期のXeonもCore2だっけ?

ダンゴ的にはどうよ？

結局は高クロックのシングルコアが速い？

それができないからthe free lunch is overなのでは？

Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか
Pen3やNetBurst系とは逆？

この質問はダンゴじゃないとマトモに返答できないと見た

.

32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら
皆知ってるけどね。

人間活動 → スカラ
自然現象 → ベクトル
中途半端 → 今のCMP全般

　 　 　　　＿＿＿_
　 　　　／⌒　　⌒＼ ﾎｼﾞﾎｼﾞ
　　　／（ ●） 　（●）＼
　 ／::::::⌒（__人__）⌒::::: ＼ 　＜で？
　 |　　　 ｍj |ー'´　　　　　 |
　 ＼　 〈＿_ﾉ　　　　　 　／
　　　　ノ　　ﾉ

おちんぽ

結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。

既出かもしれんけど
http://cag.csail.mit.edu/ps3/index.shtml

JCSPの話はここでいいのか？

良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。

保守

逐次処理を並列処理に分割する手法で代表的なものって何？

OpenMP とか関数型言語で書き直すとか？

>>356
OpenMP、pthread、MPI 辺りですかね。

# SMP 環境でわざわざ MPI する人も少ないかもしれませんが。

ちなみに性能的には MPI > pthread > OpenMP、
お手軽さでは OpenMP > pthread > MPI の順でしょうか。

>>358
>ちなみに性能的には MPI > pthread > OpenMP、
ええっ!? SMP環境でMPIってpthreadより性能いいの?

OpenMP、pthread、MPI ってどこにあるの？

一番星を右に進んだ所、虹の彼方に

ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう？
データですか？タスクですか？

適材適所。

栄枯盛衰

>>359
MPIは複数の計算ノード（例えばPCとか）を高速な通信回線で接続した
HPCクラスタ用ですね。

pthreadは共有メモリシステムじゃないと使えないので、CPUの数を増や
してもいくつかの理由（メモリアクセスの集中やキャッシュコヒーレンシ
維持のためのオーバーヘッド増加）のために、システム全体の性能はある
程度で飽和してします。大体 CPU 8〜16 個くらいが限界でしょうか。

クラスタシステムではCPUだけではなくメモリも分散配置しているので、
うまく仕事を複数のノードに配分するようにプログラムを作ることがで
きれば、もっとCPUを増やしてもシステム性能を向上させることができ
ます。

# でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な
# 学生が使える教育機関でしか人気が無いような気がする…。

>>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね

>>358
># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
>
>ちなみに性能的には MPI > pthread > OpenMP、
>お手軽さでは OpenMP > pthread > MPI の順でしょうか。
「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?

358じゃないけど、
>>366
>「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
SMPだけどNUMAなアーキテクチャとかどうなんだろ。Opteronマシンみたいなの。
pthreadでNUMA考慮して書けばいいけど、間にMPIはさんどくと、誰かが最適化してくれるかもしれない。
もう最適化されてるのかな？

MPIはHPCクラスタ用っていうけど、日立やNECも自社のスパコン用にMPI提供してて、
クラスタならmpich、スパコンならベンダオリジナルのMPIってことで計算コードを使いまわせるんで、
MPIの利用率は高いと思う。10年ぐらい前スパコン使ってたころは高かった。
メモリ共有ノード内と、分散メモリになるノード間の通信の使い分けとか考えたら、
トップスピード出すにはMPIか、その手のライブラリ使うことになると思う。

>>367
>SMPだけどNUMAなアーキテクチャ

これは定義矛盾
Opteron は NUMA
NUMA への最適化は最近のカーネルなら大抵入ってるよ

>>367
もまいはこれよめ
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40555.pdf

これってどう？
http://www.rbbtoday.com/news/20051219/27869.html

機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな

>>370
ttp://www.nec.co.jp/press/ja/0512/1902.html
これのことか？

何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に
なるだろうけど、そんな簡単な用途は極めてまれなわけで。
宣伝の一人歩きだろう。

＞極めてまれ
そうでもない。
処理はシンプルでも大量に捌かないといけない場合はままある。
#尤も、そういうケースは並列化の自動化も難しいが。

んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな？

画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは
並列化してナンボな物が多い。

デスクトップアプリは 4 コアもあれば十分だと思うけど。

大規模マルチコアプロセッサの発売に向け準備を進めるインテル
http://japan.cnet.com/news/ent/story/0,2000056022,20350948,00.htm

IntelのTera-Scale Computing Research Program担当共同ディレクタ
ーJerry Bautista氏によると、現在、Intelの研究者らは、コンピュータ
メーカーやソフトウェア開発者らが、大量のコアを搭載するマルチコア
チップにより簡単に適応できるようにするため、それらのチップの複雑
な機能性を意識させないための手段を模索しているという。

異種マルチコアチップ内のすべてのコアを外骨格のようなもので覆い、
それらすべてのコアを複数の従来型x86コア、あるいは1個の大きなコア
に見立てる。Bautista氏は、「それは、いわば1つのリソース貯蔵庫のよ
うになり、ランタイムがその中から適当と思うものを使用する」と述べ、
「これはプログラミングを簡略化するためだ」と付け加えた。

1個のチップ内の多様なコア間で演算タスクを分配するハードウェアスケ
ジューラを使用することにより、特定の演算タスクをより短時間で完了
できるとBautista氏は指摘する。

プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング
技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要
はない。これらのオペレーションは大抵、チップ自体によって処理される
ため表面化しないのである。

>>377
素晴らしい！！
テクノロジーの進化ってとんでもねぇなｗ

Windows出たばかりの頃の宣伝の様だが

まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、

　コンパイラ屋ガンガレ、死ぬまでガンガレ by Intel

って漏れの耳には聞こえてるが気のせい？

>>380
そういうのは NetBurst や Itanic で懲りていると思いたい…

>380
俺にはIntel以外のコンパイラは淘汰されてしまえ
と聞こえるが

ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん

INTELはいっつもAMDいじめて悦に浸ってる変態だし
しねってかんじだ

そらそうよ、Intelはパラノイアが社訓だもん

いよいよAMDの時代
http://northwood.blog60.fc2.com/blog-entry-928.html
http://northwood.blog60.fc2.com/blog-entry-932.html
http://northwood.blog60.fc2.com/blog-entry-935.html
http://blog.livedoor.jp/amd646464/archives/50980564.html

Intel社、ソフトウエアの並列化が研究開発部門の最重要課題に
http://www.eetimes.jp/contents/200705/19305_1_20070528174750.cfm
マルチコア・プロセッサに対する需要の高まりを受け、米Intel社はソフトウエア
の並列化を最重要課題に掲げている。その取り組みの一環として、特定用途
向けプログラミング言語や既存のプログラミング言語/アプリケーションの並列化
に関する研究に250名を投入している。「オレゴン州にある研究開発部門では、
全業務の実に約3/4をソフトウエア関連が占める」

インテルが開発ツールの新版を発売、ソフトウエアの並列化を支援
http://www.eetimes.jp/contents/200706/19707_1_20070605170230.cfm
コンパイラは、ベクトル化が可能な場合、SSE命令セットを利用したコードを
生成する。また、C++のテンプレート・ライブラリとして実装されているTBBを
利用すると、ソフトウエア開発者が明示的にコードを記述しなくても、マルチ
スレッド化できる。OpenMPライブラリを利用しており、実行時に利用可能な
コア数分だけスレッドを生成する。

AMDは甘ちゃん
IBMとIntelはプロフェッショナル

次世代スパコンはスカラーとベクトルの複合型に，日立/NEC/富士通の「3社連合」で開発へ
http://techon.nikkeibp.co.jp/article/NEWS/20070613/134173/

アーキテクチャの概要は，スカラー型プロセサからなる演算システムにアクセ
ラレータを付加し，さらにベクトル型プロセサからなる演算システムを組み合わ
せる，というもの。スカラー部とベクトル部は，共有ファイル・システムを介して
データをやり取りする。これによって様々な大規模計算シミュレーションが計算
のタイプに合わせた演算環境を選べるようになる。

ハードウエアだけでなく，ソフトウエアも同時に開発する。「制御フロントエンド」
のジョブ管理を通して，ユーザーはこれら二つのシステムの違いを意識せずに
最適な演算環境を選べるようにするという。

>>384
コンピュータ様って事ですね？市民。

もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・

http://pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm

いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。

シーケンス図廃止からやってみようかな？
で、その代わりに何を使えばいい？？

並列システム用のモデリングviewをUMLに策定してくれんかな。

あのさー

マルチコアに限らずソフトの最適化なんて、現場レベルでボトルネック分析し
どこを重点的に並列化するか設計フェイズにフィードバックしながらやっていくもんで
日本伝統のウォーターフォールモデルじゃ、いくらお絵かきツールが便利になっても
全然役に立たんよ。

むしろUMLの本質は抽象化なんでそもそもマルチコアを意識する必要ねぇ。
逆に具体化しちゃうと、コア数の増減やパフォーマンスの見積もり違いで破綻する希ガス。

マルチスレッドは一般的にはObserverパターン、と本で得た知識をそのまま晒してみる。
ttp://www.hyuki.com/dp/cat_Observer.html

それにしても結城先生お茶目だな。

さてと、、、

Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が
ご迷惑をおかけしております。

ゲハ厨自演乙

>>396
バカかお前ｗｗｗ
何も知らないんだなｗｗｗｗｗ
ム板で厨認定された糞団子が帰る場所は














学歴とゲハだよｗｗｗｗｗｗｗｗ

該当するスレが見付からず、
かといってどこにかけばいいかわからないのでここで質問をします
(どこか適当なスレがあれば誘導していただければ幸いです)

今、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の方で勝手にタイムアウトをしているのですが
このような場合はどのようにすれば回避できるのでしょうか？

簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある？
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。

UNIXのパイプ

フィックスターズが出している
http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1462-1
は、役に立つのだろうか？
立ち読みした限りでは内容がちと薄い気がするのだが。

>>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。
とりあえずコードを何回も書いて覚えている途中。

変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。

そんなレベルの奴が並列化なんかに手を出すのが間違い

並列かなんてたいして技術いる事じゃないだろ

そういうやつが平気でぼけぼけかますのが並列化

科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。
javaERの俺にはﾀﾞｸﾞﾘｰ先生の本のほうが面白かったけど。

>>406
一緒にするなよ

Amazonでの評価は微妙だね。
http://www.amazon.co.jp/dp/4798014621

俺は釣られないぞ

なんでOpenMPばっか期待されてんの？
どこにもOpenMPなんて書いてないように見えるが（本のタイトルとかに）

デザインパターンの本。
↓
Javaについてはほとんどのってないので期待はずれ。
↓
デザインパターンの本、評価は微妙。

だれもJavaって言ってないじゃん…

たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。
俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。

Win32マルチスレッドプログラミング
http://www.amazon.co.jp/dp/4756114040/

http://www.ebjapan.com/content/l_news/2007/07/l_news070702_0101.html
これってハードレベルで並列を実現したってこと？

>>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。

業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね？

>>415
FPGAのparallel random access machine/model
じゃねーのそれって？

しかし今回はそれを1個だけしか作れていないはず。
64個最大実装時（現在開発中）が現行CPUの100倍程度って事だな

まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が
書きやすいと思われる。価格も現実的だし。

http://seisei.s8.xrea.com/thread/
これはどうなんだろうね？

>>418
うさんくさすぎねーかw

これが全部実現できるならIPAとかに公募して金もらうはず。

なんか穴があるはずだ。実用上の

>>418
すげぇ、胡散臭すぎて読む気にもならないよ。

読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。

で？

XORをまるちすれっど？

で？

オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案？

で？　
　
　

順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる！
俺天才！！！

って事？ｗ
URL削るともっと胡散臭いｗ

えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、

という感じ？

じゃなくてこれは単なる dish の簡単な使用例か。
ttp://www2.chem.nagoya-u.ac.jp/matto/90/70Proj/dish/index.phtml

>>424
やばい、ドキュメントDLで金とるよ的なページもある。

419です。
スマン、どうやらスレ汚しをしてしまったようだ。
削除依頼してくるわ。

ごめん、↑は418の間違いね

そりゃ潔癖すぎる
気楽にやろうぜ

クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。
タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。


無理か？

200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。

メガドラか

200メガギガヘンリー

200万ギザエッチ

200マゾガチハーレム

ダンゴさんのレスが望まれるところだ

悪趣味だな。

だーんごー
だーんごー

たーっぷりー

だーんごー

>>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。

>438
それ、たらこだろ？

キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ

イチローの出番だわな

>>430
ヘテロなマルチコアならcellがあるじゃまいか

そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ
れば効率よくマルチプロセス・スレッドができると思ったのよ。

>200MGH
200MHと間違えたよorz

＞クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして

重い処理をするコアが数パーセントの稼働率でその処理やればいいんじゃない？
あまった時間はクロックダウンして各種電源OFFしてればいいし。

ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな
低速簡単タスクはPICとか使ってやってるシステムもあるよね。

どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、
低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。
その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを
考えたほうが建設的だと思う。

分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。

人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに

>分散すれば仕事が早くなるってアホな幻想

お前がアホなんだろｗ

無理なものは無理

つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。

工場の単純労働者は1000人必要かもしれない
だからといって社長（＋役員）は20人もいらない

でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw

>>452
それなんていう暖房機具？

1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。

今なら１U3台で済むよ

QuadXeon 6個＋ﾏﾏﾝ3枚でｵｹ

Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか?
おめでたいな。

頭が4つもついてる役員は怖いです。

バスが飽和しそうです。

>>454-456
お前らブレードサーバも知らんのか？

6U で Xeon 20個 コア 80個ぐらいは積めるだろ。

http://japan.cnet.com/news/ent/story/0,2000056022,20353310,00.htm

GPL？

記事読んだ感じだと、例外付き GPL なんじゃないの

LGPLだなたしか。

でも実際これら使っても効果出る範囲狭いみたいだぞ。

タスク境界を自動で検出するTOOLないかね？

foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。

http://www.itmedia.co.jp/news/articles/0708/21/news021.html

>>465
どういう計算だよｗ

http://pc.watch.impress.co.jp/docs/2007/0821/tilera.htm

http://www.atmarkit.co.jp/news/200708/21/tile.html

http://pc.watch.impress.co.jp/docs/2007/0821/tilera.htm

Wikiﾍﾟﾃﾞｨｱより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず

マジか

>>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは
ないことは理解してる？

一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける
ものの違いだと認識している。


多分

XP HOMEもそうだったでしょ。
物理CPUに対応してるのは１個まで。
物理CPU１個ならコアが４個あっても大丈夫（のはず）

物理CPU２個はXP PROFESSIONALから。４個以上は知らない。

それは違うぞ。

じゃあどうなの

いや、自分でもよくわからないんだけどさ

>>473
ちがうよ。
マルチプロセッサってのは文字通り
マザボに CPU を複数のっけることだよ。
ハードディスクを 2 個繋げたり
メモリを 4 枚さすのと同じ。

http://www.atmarkit.co.jp/fwin2k/special/whatiswin2k_rev1/server4.html
　　　　　　　Windows 2000 Server Advanced Server
最大SMP CPU数 　　　4CPU　　　　　　　　 8CPU

http://win64xp.impress.co.jp/change/index.htm
　　　　　 Windows XP Professional Windows XP Professional x64 Edition
対応CPU数 　　　　　2　　　　　　　　　　　　　　　　　　 2

http://q.hatena.ne.jp/1185032304
1.WindowsXP HomeEdition … 1 ソケット
2.WindowsXP ProfessionalEdition … 2 ソケット
3.WindowsVista HomePremiumEdition … 1 ソケット
4.WindowsVista BusinessEdition … 2 ソケット
5.WindowsVista UltimateEdition … 2 ソケット
6.WindowsServer2003 StandardEdition … 4 ソケット

コア数は４個だろうが８個だろうが全て認識するようです

コアが32個あるタスクメジャー見たなｗｗｗｗｗｗｗｗ

並列化・並列計算のスレってこの板には多分ここくらいしかないので、
ここで質問します。

太陽系の惑星の軌道を並列計算をするときに、
時刻tでの惑星の速度と位置のデータを
他のプロセスに渡して次の時刻(t+1)の速度と位置を計算させて、
全ての惑星の分を計算し終わったら次の時刻の計算を・・・
と繰り返す処理をPVM ＋ C言語で組んでいるのですが、
どうもデータの送受信部分のコーディングがうまくいきません。

繰り返し1回目はちゃんと結果が帰ってくるんけど、
2回目は送信はできるけど計算結果が帰ってこない、
というような状況になっております。

並列計算で繰り返し処理を行う場合は
データの送受信の処理はどのようにコーディングすればいいのでしょうか。
(作りかけのプログラムをどっかにうpしたほうがいいんですかね・・・？)

>>481
MPIのスレがあるぞ

>>482
そうなんですがMPI以外の話になっちゃうので
抵抗がありまして・・・

地球時間とか木星時間の一年周期で同期したらいいんじゃね

cygwin+gccだとどのような方法がありますか？

ない

lam-mpiならcygwinにインスコできた。
mpichもたぶんできる。

IntelのCt言語っててにはいるのかな？

「小飼弾のアルファギークに逢ってきた」っていう本に
Dave ThomasがErlangの本を書いているって書いてあったんだけど
詳細が分かる人いますか？

07年7月に出版予定とか書いてあったけど、どうもAmazonの洋書でそれらしいものがない。

すみません。
誤爆しました。

128bit レジスタ を 8 コアで SSE 拡張として繋げて、
1024bit のベクトルプロセッサとして使える。

、、、とかだったら面白くなりそうなんだけどな

>>491
どれかのプロセスがそれをやっている間他のプロセスが割りを食いそうだからやだ。

>>491
逆に並列性が下がりそう

素朴な疑問だけど、これからはメニーコアの時代、とかいうが、
コア間で「人月の神話」と同じ問題は発生しないのかえ

する。

つーか、大昔からのマルチプロセッシングの課題が
いかにリニアにスケールさせるか、です。

それじゃ漠然としすぎて無意味だよ

大昔からリニアにスケールさせるにはどうしたらいいかって話で
結局は個別対応になるから、一般論として本当に軽い話しかできない

古い記事だけどマルチコア、マルチスレッドで
どこらへんに苦労したかっていうのは書いてあるけどほとんど一般論
http://www.4gamer.net/specials/capcom_x_intel/capcom_x_intel_01.shtml

ＥｆｆｉｃｉｅｎｔC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。

>>497
知りたいことの的を絞ってくれればある程度話ができるよ。

mac osx ppc64 で tbb を使って遊んでみようと思ってます（当然シングルコアなので雰囲気だけ）

ところが、libtbb.dylibとlibtbbmalloc.dylib を入れてもリンクエラーが発生します。
自分でソースからビルドしてdylibを作り直してもダメ。
dylibの中をみてもそれらしいシンボル名がないようなんですが、どうすれば動くんでしょうか。

おおむね一年研究してみたが、マルチコア化でいちばん厄介なのは

1.どれだけスレッドセーフなコードを簡単に作れるか
2.どれだけスレッドセーフを意識しなくてもよくできるか

の二点にかかっている、これに伴って

スレッド化が問題を引き起こすのは、作る側、使う側の間で、仕様伝達がもつれてしまったり、
一旦スレッド化すると、非スレッドセーフに戻したり、逆に非スレッドセーフに作ったコードを簡単にスレッド化できない事で
オブジェクト指向で言えば、オブジェクト間の結合がスレッドによってむやみに強められてしまう点がまずい。
スレッドセーフは、メソッドにつけられる属性の一つとして機能するが、言語機構てきに簡単には取り付けられない。
なにしろ、何につていスレッドセーフかという問題もあって厄介だ。
逆のこの点を解消すれば、むしろ色々な物(IO同期処理等)が統合できて便利だと思った。
『やりたいことの記述と、どう実装するかの記述を分離する事』が最も重要だ。

>結局は個別対応になるから、一般論として本当に軽い話
初めて見た時は不可能そうに見えたが、一般論化しないかぎり成功しない、そしてそれは不可能でもないと思った。
逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。
一言でいえば、いかにサクッと書けるか書き換えられるか、同期が必要なデータが明白化できるかが、そのまま並列化の性能になってしまう。
並列化はパフォーマンスを求めるために使う技術だが、パフォーマンスを求ている内は使い物になりそうにない。
VBが、GUIのコードをあっさり書けるようして、実用的にしたように、マルチコア化も同様なものが必要でスケールとかは意識しても仕方がないと思った。
概念として重要そうなのは、C#やVBのLINQやHaskell等で実装されている遅延評価が使えそうだという点か。

CPU・・・衝突、不一致を嫌う設計
脳・・・衝突、不一致を積極的に利用

CPUの設計原理を変えずに、脳の真似をするのは難しい。

>>501
> 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。

業務用ゲーム業界に職人技的に伝えられてきたというあの「タスクシステム」？

タスクシステムなんてこのＷＥＢ全盛時代にはもはや化石だなｗ

並列化のキーワードは網羅って聞いたことがあるような。
例えばソートだと、順列(全パターン)を作ってそれが並んでいるか調べるだけでいい。

現在の手法は今までのアルゴリズムを並列化しようとしているからロックとかで問題になっているんでしょ？
アルゴリズムを根本から変えれば良いと思うけど。

>>503
カプコンのMTフレームワークは使うかどうかはともかく、見ておく価値はあるよ。
http://watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm
十分とは思えないが、役に立たない理屈と違い実戦的な並列化手法の一つだから。

>>505
量子コンピュータ時代になれば、役に立つかもなw

>>507
ある程度コア数が大きくなったら役立ちそうだと思うけど
別に1パターン1コアに分けなくてもいいし。

>>508
> ある程度コア数が大きくなったら役立ちそうだと思うけど

算数からやり直した方がいいと思う。

>>508
たとえば1000の組み合わせの数を数えてみたらどうかな？
n qubitに対して、並列度が 2^n である量子コンピュータなら
2^1000程度の並列度を持たせれば、その組み合わせ数にも打ち勝てる可能性はあるが、
10個や20個のコアでなんとかなるかな？

あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。
アルゴリズムが分かりやすいし。

>>511
極めて単純なものだけに有効でしかないよ
総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。
宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。
そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。
量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、
自分たちが感知できない別の宇宙にコンピュータを配置する、
今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。
これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。
ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。
それにしても一番気になるのは計算機よりも並行宇宙そのものだ。

量子コンピュータを神秘視しすぎだろwww

>>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ？
どうころんでも、どう解釈してもキモ過ぎだよ

量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。

キモいと言えばキモい性質ではある。

並行宇宙ﾜﾛﾀ

並行宇宙ヤバイ

>>512マジキモイ

2XXX年のオリコン一位

「並列宇宙」

>>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか
量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。

Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。

宗教の話は他でやってくれないか。

ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ

>>520
量子コンピュータが量子力学の正しさを証明しても
並行宇宙解釈が主流になる事は無いと思われ

ここム板やで。

>>1
boinc環境を用意してねらーを煽る。

懐かしの宇宙ヤバイを思い出した。

ちょっと、細かい質問なんだが、
tbbの本３８ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。

たとえば、2コアのＣＰＵで１０００回のループのを並列処理するときに、grainsizeを５００にする、
４コアならgrainsizeを２５０にすることで、理想的にスケールするということなんでしょうか。

この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか（TBBのもいい参考書だとおもいますけど。）。

>>528
その本持ってないから意味不明で困る。

処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。

>この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁

>>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。

>>530
ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎

>>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。

調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってｗ

>>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw
例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。

>>534
「複数のマルチスレッドライブラリが組み合わさった状態」
になったら「ショボイ開発」って思わなきゃダメだよ

10000行で完成する程度のコードしか組んだことないんだなw

並列・分散処理に関しては以下のホームページが参考になります。
主要な言語に対応したツールなどの紹介もあります。

www.cspjapan.org

>>537
宣伝でつか？
マルチポストでやるのは、あまりイメージ良くないですよ。

>>537
ちらっと見ただけだけど、通信部分が浮いている感じがするな、もっと洗練できると思う。

グリッドコンピューティング？には合ってる部分もあるのかもだけど
昨今のマルチコア活用方向とは全く合わんのじゃ…
大体想定環境・状況が古すぎるような…

プロセス代数は基本だと思うし、オブジェクト間通信という考えの元でも問題はないと思う。
マルチコア活用を阻害している最大の要因はパフォーマンスではなくて
直感的に記述することや効率よく記述すること、デバッグを容易にすることが重要だという点に気付いているかが気になった。

もうひとつあるな、現行残っているシングルスレッドモデルで記述された大量のコードを徐々に移行していくための仕組みがいる。

>>534
想定しなくていいように作るもんだろ
それに囚人のジレンマは場違いもいいとこ

>>532
> コードがスマートになる粒度にハードウェアを調節しないと駄目だ。

プログラマからするとソフトウェアもコードがスマートになるように作ってほしいですよね。

>>543
俺も思ったけど、Wikiみたら使い方あってるみたい。

> 囚人のジレンマ
> 個々の最適な選択が全体として最適な選択とはならない状況の例としてよく挙げられる問題。

>>543
すべてのライブラリが自家製とかありえないだろ、ふつう

>想定しなくていいように作るもんだろ
想定しなくていいように作る＝毎回開発でスクラップアンドビルド
だが、良いのか？

>想定しなくていいように作る＝毎回開発でスクラップアンドビルド

うわっバカだ

マルチスレッド並列化で解決すべき深刻な問題の一つだからな、保守性の無さと再利用性の低さは。

>>537
今更CSP紹介されてもな…何十年前の話題だよ。
CSPを普通に実装するとプロセス間をデータが流れることになり、
キャッシュを越えるコア間のデータ転送が増えて、途方もなく
効率悪いと思うんだが。
その辺まで言及してくれればこのスレ的な話題になる。

>>548
＞ 保守性の無さと再利用性の低さは。

STM はその辺強いのかね

>>550
変な用語を使うのはヤメレ、シングルスレッドモデルといいたいのだろうが・・・
ちょっとでも触ればマルチスレッドを使った並列化の現状が論外な状態だと判るはず。
可能ならとっくに流行っている。

>>549
現在のプロセッサの最大の弱点はプロセッサ相対で低速なメモリーであって
キャッシュ間の転送は、小さくはないが致命的でもない。

>>551
アフォか。Software Transctional Memoryだろが

>>552
一般論としてはそうだが例えばfork/joinはスティールされない限り
同じスレッドで実行することでデータ転送を減らすよう考慮されてる
スティールされるのが古いタスクからなのも同じ理由
それに比べてCSPはどうだ？

>>554
>fork/joinはスティールされない限り同じスレッドで実行することでデータ転送を減らすよう考慮されてる
SMT(ハイパースレッディング)が登場してから、おかしな対処をしないと性能がでなくなって必ずしもそうなっていないよ、今は。

>>555
そうか？tbbやjsr166yのfor/joinは>554で書いたようになってると理解してるが。
ソースｷﾎﾞﾝ

しかしまぁ、オペレーションズ・リサーチは情報系出身なら常識だろうと思うが、こういった基本すら知らない奴はどうしてくれるかなぁ
ゲーム理論や囚人のジレンマも知らないというのはどうかと思うんだ・・・

>>556
Core 2 Quadマシンと、Windows Vista 買ってきて、ひとつアプリを走らせろ
そして、タスクマネージャーなり、ガジェットからCPUメーターをダウンロードして睨めっこをするんだ
そうすれば、ソースも必要ないし説明するまでもない筈。

>>558
まさかProcessor affinityの話をしてるのか？

>>559
謎用語出す前に、基本を勉強しとけ

>>560
謎用語て…単なる煽りか？それなら消えてくれ
煽りじゃないなら>558とjork/joinのタスクスケジューリングの関係を説明してほしい

ソースだせと、なぞ用語で捲し立てるのが趣味なら消えてくれ

>>557
常識だと思うけど、大学卒業して10年の俺はさっぱり覚えてないw

頭の悪いGKがいる、絶対いるw

>>562
Processor affinityはWindowsでもLinuxでも商用UNIXでもAPIになってる
特定のプロセス／スレッドを特定のCPUに割り当てられやすくするもの。

fork/joinのスケジュールがスレッドのローカルなキューからタスクを
取ってくるのも新しいタスクをキューの先頭に入れるのも
他のスレッドからキューの後ろからスティールするのも
Processor affinityの元でスレッドが同じコア上で実行される場合に
キャッシュが効率的に使われることを目指していると俺は理解している。

さて、>555や>558について説明してもらえないかな

>>565
CPUメーターみてみなよ、OSが勝手にスケジュールを調整してこちらの意向を無視している。

>>566
そのアプリがSetThreadAffinityMask読んでないなけだろ

>>567
単に、特定アプリに依存すると障害が多いからMSが調整しただけかと

>>568
意味が分からない
SetThreadAffinityMaskを呼び出していないスレッドをOSが勝手に
スケジュールするのは当然のことだ
お前さんの言ってるアプリはSetThreadAffinityMaskを呼び出してるのか？
呼び出してないアプリでCPUメーター見ても全く意味がないんだが
Processor affinityを知らなかっただけじゃね？

そっちの言っている事こそ意味不明だわw

じゃあさ、>558で「ひとつアプリを走らせろ」のアプリが
SetThreadAffinityMaskを呼び出してるアプリのことかどうかだけ答えてくれ
yes/noだけでいいからさ

こんなの、つまらないコード書いて、パフォーマンス確認目的でパフォーマンスカウンタ見れば一発なんだが・・・
なんでこんなややこしい話が登場するのかと・・・

バカ相手にするのは疲れる

>>572
ややこしい話はしていない
そのつまらないコードでSetThreadAffinityMaskを呼んだのかどうか、それだけだ。
これもyes/noだけでいいから答えてくれ

SetThreadAffinityMaskじゃなくSetProcessAffinityMaskなら
タスクマネージャーから設定できる。
プロセスタブでプロセスを選んで右クリック、関係の設定でCPUを選ぶだけ

逃げたようだな。結局Processor affinityすら知らなかっただけだけか
何が「基本を勉強しとけ」だよｗ
きっとfork/joinも何のことかわかってないんだろうな…

割り込んでごめんなさい。
windows 2k serverってマルチコアに対応してますか？

windows serverは全部対応してるって記事をネットで見たけど、
記事自体、いまいち信用できないんです。

雑誌記事が信用できずに、誰の発言かもわからない
掲示板の話を信用するんですか？

>>578
どっちもどっちですが、広告だらけのブログで「対応してる。」って言われるのと比べるなら、
まだ、ここのほうが信用できます。

「ここで公式に書いてるよ！」みたいなレスがあればなぁなどと思った次第です。

それプログラミングと関係ないだろスレ違いだしageんな

>>578
P4-2.4Cで2個見えてるから、2個までは対応してると思うよ
＃手元に2コアまでしかないからそれ以上は分からんｗ

初心者ですまんが
Ｐｇ作るのにマルチコアなんて気にする必要アンの？
いいところスレッド処理とか流せば
しかたねえな　ってかってに動いてくれそうだけど

そのいいところってのが難しいんじゃない？
いままでみたいな粗い粒度のスレッドの使い方じゃなくて、もっと積極的に
例えば単なるクイックソートを2〜4スレッドで並列実行して高速化しようとか、
そういうのを考えるんじゃないかなたぶん

>>582
ここは君が来るところではないんだよ。
ここはデュアルコアならシングルコアの2倍、クアッドコアなら4倍の
パフォーマンスを目指すスレ。

今のところ有益な議論は一度もないけどな。

Processor affinityも知らないSoftware Transactional Memoryも知らない
wait freeやlock freeの話も出ない
有益な議論のしようがないなｗ

>>584
キャッシュに入るような小さな処理から頻繁にメモリアクセスが必要な処理をした際
実際のパフォーマンスを比較したものってどっかにないの？

マルチスレッドスレと話題かぶるからなぁ

>>582
俺も気になった。
winのapiには無いと思う。

２つのスレッドを２つのコアにわけるなら話も早いけど、
１つのスレッドを２つのコアにわけると、なんか、戻りとか処理のオーバーヘッドがでかそう。
win上で動くプログラムからそこを制御できるかも、よくわかんないし。

と、初心者は思うのでした。

初心者だと思うなら、「winのapiには無いと思う。」なんてろくろく調べもしないで
レスするなよ。

マルチコア対応apiはwinにはないね。未熟なOSなのかも。

同一ソケット上のマルチコアに特化したAPIはないわな。未熟だわなｗｗｗ

windows上なら、SetXXXAffinityMaskってのを使うみたいだけど、
OSに任せたほうが無難だろうな。
ビットマスクに何指定するのか、俺の古いMSDNだとわかんないし。

あとNT3.5から対応してるんだな。
これ使ってプログラム組んでれば、
別にwin 2kでもwin 2k severでもマルチコアに対応できる気がする。
（OSが認識さえできれば、で、マルチコアは2kで認識できるはず。非公式だけど。）

>>577への回答ね。マルチコア対応プログラムなら、おそらくwin2kでもおっけ。
むしろ余分な他プロセスのバックグラウンド処理が少ない分、win 2kがxpやvistaより早いと思う。

それ以外は、OSの判断だけど、多分２つCPUあるときと同じだから、win2kでも大丈夫な気がする。
こっちはあんま自信ない。

以上、>>577の自己回答でした。

>>589
嫌味な上級者は、絶対何も言わないんだよな。

さっきからずっと、むかつくレスしてんのこいつだろ？
上司でたまにいるんだよ。
知ったかして、具体的に何も言わないで、誰かが言ったら便乗するやつ。

そりゃ、言うべきじゃない時を心得てるのが上級者というものだからなあ

>>592
MSDN見たなら「参照」も見るといいよ

>>592
あんまり調べる気無い。
何か映像関係の高速処理組むなら別だけど予定もないし。
スレッド、プロセス関連は完全に２、３継承のクラス化しちゃってるし、
いまさらOSの判断以上の速度が出るように直す気はない。

時代がマルチコアなのになぜ対応apiがないのか？
これはMSの怠慢ではないだろうか
高いOSライセンス代（１台につき１万〜３万）を定期的（５年程度）に払っているというのに
ひどい話だ

>>597
マルチコア対応APIって具体的にどういうものよ？

>>597
だからwindowsにもあるって。
プロセッサを直接指定できるapiが。
やっぱNT系のカーネル作った連中は偉いわ。
おれもまだまだ2kで行く。

マルチコアねぇ…
TPC風にProcessor/Core/Threadで表すと、Core2Quadの1/4/4はマルチコアだよな。
じゃあシングルコアXeonを4個使った4/4/8とかItaniumを64個使った64/128/256は？
後者もマルチコアならマルチコア対応APIは既にある。

マルチダイもマルチコアに含めてるしな、、、思想的には
ていうか、やっぱまだ２ｋって需要あるかなー？
今新規にフリーソフト作ってるが、どこまでサポートするか悩む

>>599
Processor affinityはDECのVMSの時代からある。
WindowsNTと作った連中は同じだけどなｗ

>>601
俺、フリーソフトは、2kで作って、xpで軽く動かしてテスト終わり。
2kで動いて、xpで動かなくなったことはない。
基本、Direct X関係に気をつけるだけ。

CPUが別パッケージかオンダイかを気にするような場面には出くわしたことないなあ
キャッシュの奪い合いとか同期の頻度とかが問題になるのかな？

むしろhyper threadingが特別だったんじゃないかと思う

Win32のSetThreadAffinityMaskはaffinity maskがDWORDで32bitしかない
64/128/256のSuperdomeはOSからは256プロセッサに見えるんだがどうするんだ？ｗ

hyper threadingは鬼門

>>606
Pen4のHyper Threadingだけが鬼門？ SMT全般が鬼門？
ちょっとだけPower使ったときは何もなかったけどな

>>605
いずれSEtThreadAffinityMaskExが出来るだけよ

>>608
いずれってかSuperdomeにWindowsが乗ってから5年以上経ってないか？
Windows乗ったSuperdome俺は見たことないけどｗ

テキトウに仮想化でもしたほうが効率よさそうな気が

>>610
それは現実的すぐるｗ
とりあえずタスクマネージャーはこうなる
ttp://www.microsoft.com/japan/sql/images/ssj/ki03_02_l.jpg
これで「関連の設定」は64CPU設定できるのか？
つかItaniumだから64bit Windowsか…

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
);

>>607
606じゃないけど、HTは面倒な存在じゃない？
普通のマルチプロセッサなら異なるプロセッサ間で同じキャッシュラインに
アクセスしない方が良いが、HTの場合は逆でしょ？
ベンチ取ってないんで、どのくらい影響があるのかは具体的には分からんが。

menndouda

>>613
それはPower含めてSMT全般にいえるし、少しレイヤをずらすと
2(3)次キャッシュ共有のマルチコアやNUMAにもいえるんで、
そんなに特殊なことではない。

さっきWin64調べてたらこんなAPIがあった
BOOL WINAPI GetNumaNodeProcessorMask(
__in UCHAR Node,
__out PULONGLONG ProcessorMask
);

これで距離の近いノード内のプロセッサマスクを取得できる。
NUMAアーキテクチャに限定せず、SMTやキャッシュ共有のコアを
ノードと見なすことができると、細粒度並列実行で効果的なヒントを
与えられるかもしれない。

マルチコア対策としてこんなのがあります。

http://www.axon7.com/

また、これも参考になります。

http://www.cspjapan.org/

>>616
>537

マルチプロセス、マルチスレッド、マルチコア、マルチプロセッサ、SMT、メモコン共有、キャッシュ共有、演算器共有。
これが複合的に絡んだときの最適化は複雑すぎる。

>>617
>549

間違えた、>619は>616へ。

>>618
それをコンパイラで成し遂げることが前提のItaniumは不可能に挑んだようなものだな

マルチコアは、今までのソフトウェア技術を台無しにしてくれる素晴らしい技術だよね。
これからはソフトウェアとハードウェアの境界が無くなって、
プログラムを作るのは、より一層大変になる。

ハードとソフトが緊密に絡む領域はこれまでもあったんだけどな
無停止システムとか

今までのマルチプロセッサ向けのソフトウェア技術の延長にあるから
台無しという事は無いよ。もう何十年も研究が続けられている分野だ。

何十年も研究とか、無駄の極地だねｗｗｗ

ロックフリーのアルゴリズムやトランザクショナルな変数アクセスが
もっと一般化してくれば、そんなに恐れる物でもない気がするけどね

>>621
いったい何に怯えているんだろうか

まあそりゃ単一スレッドで速くなるほうがありがたいけどな

荒い粒度の並列化や、ベクトルの並列処理はとっくに研究され尽くされてるけど、
その中間が非常に厄介。
しかし、これからは単一スレッドでは速くならないわけだから、それをやらないといけない。

ループを展開する自動並列化くらいはインフラとして整備して欲しいね

>>629
自動じゃなくてもparallel array使えばおk

>>628
divide and conquer
work stealing
fork/join
parallel array

遅レスだが
ハードウェア・ソフトウェア協調設計等は組み込みでは昔からよく見られるんじゃないか？
まあ、シミュレーター等の開発統合環境が整えられているなら最適化はむずかしくないよ。
ただ工数と時間と労力が膨大に費やされていくだけで

組み込みの場合は、環境のプロセッサ数やプロセス数は固定されてるから、難易度は低いんじゃないかな。
PCの場合は、対象のプロセッサ数は予想できないし、同時にどんなプロセスが動くかも分からないから、難易度が高い。
というか、PCの場合は、何らかの動的最適化メカニズムが必要になるんだよね。

http://pc.watch.impress.co.jp/docs/2008/0613/hot554.htm
インテルはCを拡張してJITコンパイラで最適化する研究をしてるようだけど、
実用化はまだまだ先だよな。

１．マルチなんたらとか並列化とか、なにも考えずに作る。
２．あとは開発環境とOSがなんとかしてくれる。
３．下手なこと考えるより、そのほうが最終的に効率が良い。

こういうのが理想なんだけどなぁ…。

スレ民じゃないけどマルチコアネタがあったのでぺたぺたしていきます。

「Ruby 1.9は1.8より平均5倍速い」、YARV笹田氏 − ＠IT
ttp://www.atmarkit.co.jp/news/200709/07/yarv.html
今後のテーマは並列処理によるスケーラビリティ向上

　今後の研究テーマとして笹田氏は、並列処理への対応など
スケーラビリティに取り組みたいと話す。ただ、「Rybyの言語仕様の
枠組みでスケーラビリティを上げるのは難しい」ため、マルチコア、
マルチプロセッサといった密度の高い並列化よりも、クラスターや
グリッドのようにネットワークで接続された複数ホストによる並列化を
実現していくのがいいのではないかという。

>>634
それ何て第五世代

>>635
むしろマルチコア関係なくね？

マルチコア向けの最適化はしない方向だ、という内容だな。

今後もRubyのスレッドはマルチコアを使いこなすようにはしない方針ということだな

Rubyなんて並列化のこと何も考えてないじゃん。
書いててわくわくするとか日和ったこと言ってる言語では到底無理。

並列化に興味をもったRuby使いはErlangあたりに移行するのだろうか

アルファブロガー（笑）あたりに煽ってもらえばイッパツよ

jruby

Erlangが騒がれてるのは副作用がないのとメッセージングがあるからなの?
ほかの言語でも多少見苦しくなっても同じことはできんの？教えてエロイ人。

>クラスターや
>グリッドのようにネットワークで接続された複数ホストによる並列化を
>実現していくのがいいのではないかという。

ハードは明らかにマルチコアに進んでいて、
サーバも集約統合が進んでいるというのに。

Rubyみたいなソフト側が手前の都合だけで
「いいのではないか」とかいって方針だしても何の意味もないわけだが。

誰もそんなハード持ってません。
今のハードにあってません。

ってなるだけ。

なに、寝ぼけたレスしてるんだ？
>>644 は、Ryby という新言語について語っているんだぞ。

>>645
誰に言ってるの?

なに、寝ぼけたレスしてるんだ？
>>644 は、Ruby という言語について語っているんだぞ。

なんだ、キ印か。

>>644 って、Googleのサーバーとか、AmazonのEC2とか、分散環境が流行ってるのを知らないのか。
サーバーの集約統合が進んでるのは、既存のサーバーや負荷の低いサーバーでしょ。

分散環境が流行ってるって…
すごい規模なんだからどっちにしても分散が必要なのは当たり前。
googleなんかは2003年の時点でこれからはマルチコアみたいなこと言ってるぞ。

実際流行ってるんだけどなぁ。
クラウドとかいうキーワードでぐぐってみりゃわかると思うよ。
実効性はともかくね。

クラウドが流行ってるってのはSOAが流行ってるってのと
どっこいどっこいだな。
ごく一部で当たり前になってるのと広く使われてるのとは
全然違ってて、どっちの話をしてるかがズレてるんだな。

P2P→グリッド（言い換え）→クラウド（言い換え２）

オフコン時代の鯖だと鯖っていえば特定の対応関係になってたのが
OOのポリモフィズムみたいな多態になっただけだ

C<->Sの関係が1:1だったのが
C<->Sの関係がN:Mになっただけだ
SOAはC<->Sの関係がN:1だったがな

たしたことない。言葉変えて変化を促そうとしている単なる言い換えだ
詐欺の一種だ

クラウドとマルチコアって関係ないじゃん

まあ関係はないね
ハードの保守性とソフトのスケーラビリティを考えて、
マルチコアのマシンを仮想化してクラウドにするみたいな
話は聴いた事あるけど

>>654
ハイプで成り立ってる所も大きいから、そんなもんかと

http://www.atmarkit.co.jp/aig/04biz/hypecycle.html

とりあえずクラウドはスレ違いだろ
並列化の粒度が違う。クラウドは祖粒度、こっちは細粒度
ネタがないから構わんけど

>>652
どっこいどっこいというか、いままでSOAをかついでたところが、クラウドを担ぐようになってる。
SOAのように、クラウドは流行っている。まあそういう意味だ。
この件は、これで。

すかしっ屁こいてクライアント騙すのがクラウドなのか？

そう思う奴はいつまでも足踏みしてればいいのさ

>>657
×祖粒度
○粗粒度

クラウドもSOAもわかってないやつ多すぎ。
そんなやつらがマルチコア云々なんてしょーもねー。
せいぜい単純労働者としてコキ使われてなｗ

どっちもバズワードなんだから分かっているという方がおかしい

バズワード自体がバズワードというパラノイア

バズワードを使ってる人間はバズワードかどうかなんて気にしていないから、
一回りして結局おk

>>658
SOAと普及でぐぐると
・普及が進まない
・普及促進
・普及狙う
・普及を目指す
・普及を後押しする
こんなんばっかですけど？
流行ってるけど普及しない。笛吹けど踊らずw

クラウドはどうかと思うが、分散は物理的な話でもあるし必要なところには普及するんじゃないかな。
CPUでの並列だと限界が低いし拡張も難しいから、>>656の言うようなマルチコアマシンの仮想化で分散ってのが現実的ではないだろうか

つまり金融工学みたいな
もんですね

「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
http://www.computerworld.jp/topics/cloud/123069.html

644ですが普段アーキスレとかに書いている身からすると、
このスレの住人はレベルが低すぎます。
キミらが並列化について語るのはまず無理。
チップあたりの性能をあげられなくなったら、
分散処理でも同一コストで性能あげられないの。
Rubyの件はいかにもソフトしかしらない人向けの
苦しいいいわけだなあと。

自分以外みんなバカ症候群

ひんと: 賢い奴はこんなスレの住人なんて相手にしない

レベルが低過ぎてどこを縦読みすれば良いのか分からないや

アーキスレってどこ？
殴りこみかけてくる

残念だけど、現状ではマルチコアってサーバサイドや一部の
embarrassingly parallel な処理以外では絵に描いた餅だよね。
デスクトップ機でクアッドコア以上のプロセッサが必要な
場面は思い付かない。それこそハード寄りの知識を持っていない、
スレッド周りの実装の知識も無い様なプログラマが、難しい事を
考えずに処理性能を出せる仕組みが欲しい物だね。fork/join でも
ヘテロなマルチコアでも何でも良いけど。

後はトランザクショナルメモリと投機的実行も期待してるけど
なかなかこういうのは普及しないねえ…

ゲーム機でやってるじゃん

>>676
投機的実行ってRockのスカウトスレッド？
命令レベルの投機的実行と紛らわしいから用語は分けたいな
同時投機スレッド(Simultaneous Speculative Threading)とかな

トランザクショナルメモリはどうかねー
RockのHTMじゃアプリケーションレベルのトランザクション
扱うのは無理だしSTM組み合わせるとオーバーヘッドが大きすぎて
性能出ないと予想してる
つRockの出荷来年の後半とか遅れすぎだろjk

今普及しているデュアルコアマシンみたいな感じで
6 core のマシンが一番売れ筋のマシンになったら
プログラマはどうすればいい?

Vistaをお勧めする
あとセキュリティソフトを３つぐらい重ねがけ
これで万全

>>674
CPUアーキテクチャについて語れ Part.12
http://pc11.2ch.net/test/read.cgi/jisaku/1219884494/

最近は常駐コテの意地の張り合いばかりでつまらないくなってきてるけど
アーキテクチャスレは↑
普段は名無しだが、MACオタ(翻訳)などは漏れ。
がんばって殴り込みに言ってくれや。

>>681
なんでこのスレ来てるの？

>>681
2chらしいスレだなw

40 名前：Socket774[sage] 投稿日：2008/08/29(金) 02:47:03 ID:Yk6PbdtE
ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします

とか書かれててﾜﾛﾀ
お前そんなに態度悪いのかよw

ダンゴさんそこでがんばってたのか

お似合いだなｗ

せっかく収まるところに収まってるのに煽らないでくれ。頼むから。

644みたいな状態って、自分の専門は知ってるんだけど他のことは知らなくて、自分の知らないことはたいしたことないって思ってるだけなんだよね。
というか、自分が他のことを知らないことを知らない。
だから、「このスレの住人はレベルが低すぎ」とか言っちゃう。

でもまぁ、このスレのレベルが低いのは事実だろう。
レベル高い議論って一つでもあったか？ないよな。そういうことだ

マルチコア用のテンプレートライブラリを活用しているという話を聞かないね
良さげなのにググっても実際に使っている例が殆ど出て来ない
C++ の人気が無いのかテンプレートが嫌われてるのか…

http://www.threadingbuildingblocks.org/
http://spc.unige.ch/mptl
http://sourceforge.net/projects/rpa
http://www.extreme.indiana.edu/hpc++/docs/overview/class-lib/PSTL/

ライブラリの話はマルチスレッドスレがあるからなあ
このスレいらない子なんじゃ…

>>687
「住人はレベルが低すぎ」などと書いて無用に荒らすのが一番レベル低いがな。

>>689
要らなかったらスレが亡くなるだけだから気にしなくておk

>>689
マルチスレッドとマルチコアでの並列化は違う。

>>692
どう違うか語ってもらおうか

マルチスレッドは、タイムスライスで同時に動かなくてもおけ

マルチスレッドが並列に動かなくていいわけないだろ
マルチコア以前からマルチプロセッサは当たり前にあるんだしよぉ
本気でレベル低いなここ…

・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできなくてもマルチスレッドは可能ってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。

windowsもクラウドが標準になるんだな
http://japanese.engadget.com/2008/10/01/os-windows-cloud/

>>696
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできない時のマルチスレッドとマルチコア/マルチプロセサでのマルチスレッドじゃ状況が違うってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。

>>692
そもそも、マルチコアとマルチスレッドを比較するなよ。

>>698
おいおい、状況は違うのは分かるが、プログラムは同じにしとかないと
まずいだろ。

どこかのエンコソフトみたいにCPUのコア数によって使うルーチンを切り替える
ようにするなら話は別だが。

誰もプログラムを別にするとかなんて言ってないけど？

状況が違うと言うのはシングルコア and シングルプロセサで問題ないプログラムでも
マルチコア or マルチプロセサで問題が発生するケースがあるってだけ。

種々の要件によって、その状況によってプログラムを切り替える実装はあると思うが、
それはもっと条件を限定しないと議論できない。

デッドロックとかレース状態とかそういう次元の事かな。
確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
マルチコアにした途端に顕在化する場合はあるね。

>>701
マルチスレッドプログラミングとしては単なるバグじゃん

> 確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
> マルチコアにした途端に顕在化する場合はあるね。

そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
プロセサではあり得ない問題」のことだよ。

>>703
それはクリティカルセクションを入れるのが当たり前だろ

>そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
>ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
>プロセサではあり得ない問題」のことだよ。
アトミック操作でないのにロックせずに破壊した場合プログラマの責任だと思うが。

>>703
そんなバグ埋め込んでマルチスレッドとか恥ずかしいぞ

>>703
もうちょっとOS関連の本を読んでマルチプロセス/マルチスレッドに
ついて勉強してから書いた方がいいよ。恥かくだけだぞ今のままじゃ。

>>698
そもそもというなら、マルチスレッドとマルチコアの話は、 >>689に言ってくださいな

「マルチスレッドが並列に動かなくていいわけないだろ」とか言っておいて逆切れせずに。

>>708
比較なんかしてないぞ
マルチスレッドがマルチコア環境で正しく並行動作するのは当然
だからライブラリの話はマルチスレッドスレの方がそれなりに議論してて
適切だろうってことだ
マルチスレッドスレを並行動作しなくていい話題に限定したら
糞スレ確定で速攻落ちるぞw

同じ変数を複数スレッドで更新する可能性があるなら、UP/MPに限らずバリア入れる。
更新するのが一人だけだったら、ちょっと考えてから決める。

そういう話は、その時点でやってくださいな。
あと出しで切れるのカコワルイ

>> 709 ね。

>>711
どこが後出し？w

>>704
そもそもクリティカルセクションをどう構成するかと言うレベルの話だから、
君には用はないので当分 ROM っててくれ。

>>705-706
シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。

マルチコア/マルチプロセサではちゃんと動かないから良くないコーディングと
言うならまだわかるが。

>>707
どこがどうおかしいかちゃんと指摘してくれ。
まさか、>>705-706 の的外れの指摘のこと言ってるのか？ (w

>>714
アホですか
RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
物があるのでアトミックではない場合がある

つーか明らかな自分のミスを認められないグラマって
必要ないな。

こういう奴がいると絶対にプログラムにバグを入れてくれる。

そろそろダンゴさんがピシっと〆めてくれそうだ

つかシングルコアでも他デバイスがDMAしてきたらアトミックにならんやろ

メモリにアクセスするプロセッサがひとつだけっていつの話？

Java のでも GCC 組み込みのでも、OS ネイティブのでも良いけど、
アトミック命令ってみんな使ってるの?

排他やると暗黙的に使われるんじゃね

無意味な連番つけるときに AtomicInteger を使ったことはある

AtomicReferenceFieldUpdaterは友達

レベルの低いスレ/話題は伸びるのが速い。

レベルの低い話題に詳しそうだな

>>715
> RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
> 物があるのでアトミックではない場合がある

そんなプロセサにメモリに対する inc 命令なんかあるのか？
あるんならそのプロセサの型名書いてくれ。

>>716
「明らかな自分のミス」ってどれのこと？
ちゃんと指摘してくれって書いてあるのに指摘できないの？

>>718
ああ、DMA はあるな。
ただ、通常の DMAC はレジスタで制御するから、メモリ上で排他なんかしないでしょ？

> メモリにアクセスするプロセッサがひとつだけっていつの話？

今でも普通にあるよ。PC しか眼中にないの？

また前提が増えたな。

DMA無しだとさ。

>>718見て、Windows 98で386のときのInterlockedIncrementは、
デバイスドライバ内で割り込み禁止してincを実行するって話を思い出した。
http://blogs.msdn.com/oldnewthing/archive/2004/05/06/127141.aspx

>>726
また？
DMA 以外で増えた前提って何のことだ、ちゃんと書いてくれよ。

>>725
> そんなプロセサにメモリに対する inc 命令なんかあるのか？
> あるんならそのプロセサの型名書いてくれ。
無いからバグなんだろ。

>714 の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
に対する返信だろう。

>>728
きっと>714の「シングルプロセサ/シングルコアなら」のことだろうね

>>725
> 今でも普通にあるよ。PC しか眼中にないの？

SPARC/Power/Itaniumサーバも眼中に入ってるよ

>>725
> 「明らかな自分のミス」ってどれのこと？
> ちゃんと指摘してくれって書いてあるのに指摘できないの？

>714の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
のことだろうね

Itaniumなんてもうフェードアウトだろｗ

>>733
FNHではバリバリですよ
FはSPARCに注力した方がいいと思うけど東証決まってるからなあ

なんか、自分のミスはスルー、この反応みると本当に気づいてないようだ。だから自分はノーミスだと思っている。
前提をあとからつけて、人の意見を間違っているという。
まわりが全員レベル低いんじゃなくて、君ひとりがまわりの会話についていけてないんだってば。

>>729, >>732
> 無いからバグなんだろ。

「メモリに対する inc 命令持たないプロセサだとメモリのインクリメントは必然的に
複数命令になるからアトミックじゃないだろ？」って言ってるの？

ならすまん、inc 命令の話してる時にその命令持たないプロセサまで考慮して話せと
言う奴がいることまでは想定できなかったよ。

世の中には自力ではメモリのインクリメント自体ができないプロセサもあったりする
からそこから前提におけということかな？ (w

>>730
>>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

>>731
> SPARC/Power/Itaniumサーバも眼中に入ってるよ

で、それしか知らないと思ってていいのか？
なら、もう少し見聞広めた方がいいんじゃね？ としか言えないけど。

>>735
「ミス」とか「間違っている」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。

指摘されてもスルーなのが笑える

これはひどい。
いくらなんでも釣りだろ？

itaniumはもう終わりだろｗｗｗ




と5年間言われ続けて、無事生存中

>>725
incはアトミックじゃない。
でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。
おまえさんはコンパイラがincに落とすのを当然と考えた上でincがバス制御しない事を忘れてる。

>>736
> >>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

その前提を持ち出してるのが大間違いの元なんだよ。
マルチスレッドプログラミング全般としてはそんな前提はないわけ。
君にとってはシングルプロセッサかつシングルコアがデフォで
マルチプロセッサ／マルチコアが特殊なのかもしれないが、
マルチスレッドプログラミング全般としてはシングルプロセッサかつ
シングルコアはマルチプロセッサ／マルチコアの特殊ケースでしかない。
マルチプロセッサ／マルチコアでちゃんと動かないようなのはただのバグ。

というか、このスレ全体がひどい。
まず、議論になってない。
そして、議論以前に半分以上の書き込みが用語を並べてみているだけで技術的に意味の通る文章になっていない。
コンピュータ用語に語彙の偏った人口無脳がはき出したような文面の書き込みばかりで流れがない。
今時マルチスレッド、マルチコア、分散処理の区別もつけられない人がこんなにいるなんて信じられない。
日本のプログラマってこんなレベル低いんだ…こりゃ将来が危ぶまれるわ。

>>742
だってここ2chだし

>>742
たしかに、この発言とかひどいよね
「マルチスレッドが並列に動かなくていいわけないだろ」

>>744
どうひどいか語ってもらおうか

>>742
「このスレ全体がひどい。」とか「議論になってない。」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。

今このPC、 AthlonXP 1500+ で 53プロセス 562スレッド 動いてるぜー

>>745
マルチスレッドは並列に動かなくてもいい。

マルチスレットは、タイムスライスでもいいから、並列に同時に動く必要はない。

GreenThread

>>748-749
並列に「動かさなくてもいい」ならそうだが
「動かない」ってのはダメだろ
つか確かに議論になってないな
コンテキスト整理するからちょっと待ってろ

そもそも「同時に動く」ってのはどういう意味でいってるつもりなんだ?
意味わからん。
たとえば
・レジスタやメモリに結果を書くのを同時といってる?
・実行ユニットで演算されるのを同時といってる?
・前後を入れ替えても意味が変わらない処理を同時だといってる?
もう少し頭の中で整理してかいてよ。
タイムスライスってどういう意味でいってるの?
コンテキスト情報をスワップすることがよくいわれる時分割の本質的な意味でしょ?
コンテキスト情報が複数ハード上にあるのがマルチプロセッサだったりマルチコアだったり
ハードウエアマルチスレッディングがスレッドレベルで並列であることの本質なわけだけど。
CPUが実行ユニットで同時に計算しているとか同時にメモリに結果を書くとか関係ないよね?
このスレで議論している連中は用語をならべているだけで、その中身についてはよくわかってない気がする。
回路設計が本業の漏れからみてもまず基礎がひどいと思いました。

>>737
どこがスルー？
具体的に指摘しなよ。

>>740
> incはアトミックじゃない。

DMA の話？ それ以外にシングルコア/シングルプロセサを前提としてあるなら、具体的に
書いてくれ。

> でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。

そう言う命令がないプロセサもあるから、ちゃんと前提つけないとクレームつけられるよ。(w

> おまえさんはコンパイラがincに落とすのを当然と考えた

人の心まで読めるの？ 上級エスパーさんにはかなわないな。

>>741
前提つけたら、そんな前提が間違ってると来たか...。
そこまでしてレスしたいの？
まあ、どっちにしろそう言う文句は >>696 辺りにつけてくれ。

>>752
> このスレで議論している連中は用語をならべているだけで、その中身については
> よくわかってない気がする。

自己紹介乙。

結局、そこで議論にならなくなってるわけでね。

そろそろ753はコテハンつけて欲しい

>753は>703なんだよな？
だが>753は>696じゃないのか？
俺流れが見えてねぇw

元々このスレはハードウェア主体でマルチコア化が進んでいるせいで、
ソフトウェアを並列化しないといけなくなったのに不満を持った
アンチマルチコア派ｗがたてたスレだからね。本当はソフト屋さんの
ためのスレッドなんだけど、有意義な話がなかなかでない。

回路屋が何かとソフト屋を馬鹿にしているようだけど、せっかく
マルチコアの石があっても、ソフトウェア側の理論がないと意味がなく、
またソフト屋はソフト屋の理屈があるのでそこら辺勘違いしないように
お願いします。

並列化といっても必ずしもバスアービタがどうとかそういう回路よりの
話だけでなく、並列型言語とかプロセス代数とか形式手法とかそういう話を
期待ているんだけど、やっぱり並列化に対するソフトウェア技術者の
意識は弱く、そういう話をができる人はあまりいないみたいだね。
(俺も話ができない一人だが、そういう人の出現を待ってこのスレ読んでます)

だんごやさんだよ。
色んな意味でマルチスレッドだよ。

> 並列型言語とかプロセス代数とか形式手法とか

ここ強調すると住人総入れ替えじゃないか？w
もし次スレ立てるならスレタイに【Π計算】って入れようぜ

Π革命

>>757
> >753は>703なんだよな？

あたり。

> だが>753は>696じゃないのか？

>>696 じゃなくて、>>698

> 俺流れが見えてねぇw

簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
マルチプロセサ」で、状況が違う例としてメモリに対する inc 命令を取り上げ
たら、inc 命令ないプロセサでは状況が違うとか (当たり前だ)、そもそも
「シングルコアでシングルプロセサ」なんて前提がおかしいとか言う奴が出て
きて騒いでるだけ。

# 正直 DMA のこと忘れてたのは事実。
# DMAC とメモリーを排他制御したことないので、すっかり忘れてた。

まあ、流れを追う価値はないから、安心してくれ。(w

△ やっぱり並列化に対するソフトウェア技術者の意識は弱く
○ ソフトウェアベンダの合理的経営判断に基づいた技術者・コード屋に対する適切な仕事配分の結果

Cilk とか UPC とか?

>>762
> 簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
> マルチプロセサ」で、状況が違う例

その状況の違いは本来不要だったんだよ
どっちもマルチスレッドスレの対象になってるんだから
発端は

>>689
> ライブラリの話はマルチスレッドスレがあるからなあ
> このスレいらない子なんじゃ…

>>692
> マルチスレッドとマルチコアでの並列化は違う。

なんだから、マルチスレッドスレでは扱わないがこのスレ(マルチコアスレ)
の対象になる違いが話題になるべきだったんだ
マルチスレッドスレが「シングルコアでシングルプロセサ」の話題限定なら
外れてないがそんなこたーないわけ

以前からあった並列計算機以上のことはできない罠

>>764
C++なら>688、Javaならjsr166yのfork/joinやParallelArray、C#ならTPLとか？

OpenMP, MPI

>>758
まあ、回路屋といっても計算機のアーキテクチャとかあんまり関係ないんだけど。

それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
このスレを読み返すと前提から大分抜け落ちているように見える。

ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
ことはできない。個人的にはマルチコアは好きではないが、
ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。

一方グーグルはマルチプロセスを使った（クロームで）

> それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
> シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
仕方ないのはいいけど、マルチコアにした後にどうやって使うか回路屋
まったくノーアイデアでしょ。ソフト屋としてはめちゃくちゃケツ
ふかされている感がたっぷりなんですが...。

> CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
> このスレを読み返すと前提から大分抜け落ちているように見える。
こういう風に好意的(というか同情的？)に思うソフト屋は少ないんじゃないの？
だって勝手に回路屋がこれからはマルチコアの時代だよねっ！て勝手に言っているんだもん。
仕方なくやっているんだったら、もうちょっとネガティブな感じでアピールして欲しい。

> ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
> ことはできない。個人的にはマルチコアは好きではないが、
> ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
これは結局お互いさまという当たり前の話になるので、まあ言い分としては
理解できます。

今までの時代がソフトウェア屋さんに優し過ぎたって事なんじゃないの

優しかった時代なんてない

布団で寝てても数ヶ月したらクロックが高いプロセッサが出てくるなんて
夢の様な時代だったじゃない。

相対的にはこの15年くらいはそれ以前より優しかったと言える
でなけりゃJavaがメインストリームになることはなかったはず

>>771
>回路屋
>まったくノーアイデアでしょ。

ノーアイディアっつー事も無いんじゃない?

あまり詳しくないけど、、、
Intel >> TBB
Sun >> JSR166y, Fortress
IBM >> X10

サーバサイドなら仮想化とか Map/Reduce とかもあるし、
マルチプロセッサの歴史が長いから、そもそもスケールする
アプリも多いよ。

PCIバスもバスマスタになるからメモリ書き込むよ

Pentium 4で3GHz到達したくらいまでが天国だったろ？

MapReduceはサーバーサイドじゃないけどね。

>>765
> その状況の違いは本来不要だったんだよ

え゛っ、今更そんな言い訳ですか...。

だったら、RISC がどうのこうのとか言ってた奴はまんまバカじゃん。
まあ、実際バカだと思うけど。(w

て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
グルコアとの違いを書いただけで、常識的なことだから普通に流され
ると思っていたんだが...。

>>780
今更って…>709でも同じように書いてるんだけど
言い訳とか後出し(>711)とか意味わかんないし
話が>689から始まったのを分かってないのか？

> て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
> グルコアとの違いを書いただけで

繰り返しになるが、マルチスレッドスレがシングルコアスレなら
それが違いになるが、そんなこたーないわけ
この話続けてもかみ合いそうもないから俺はもう逃げるよ

この板の連中もたいしたことねーな

>>779
わざわざ説明しなくても良いと思ったんだけど、必要だった?

なんか不思議だよね。CPUのクロックは別にまだ上げられるだろ。
消費電力考えたら、マルチコアにいくのがいいよね〜っていうだけで。

で、マルチコアのプログラム支援が言語レベルであれば理想的だが、
なくてもそこそこやれる（やれてる）でしょ？コア数が100とか
1000とかになってくると、言語レベルの支援がないと厳しく
なってくるかもしれんが。

何がいいたいか、自分でもわからｎ

あげられないからマルチコアになったんだよ。

クロックは上げられるけど、投資対効果が期待出来るスピードで
クロックを上げ続けるのは無理。それより余ったトランジスタで
コアを増やした方が取り敢えず嬉しい。

マルチコアの方が使っててスカスカに軽く感じるじゃん？
当面はそれでいいんじゃないかと思う。

で、ユーザーがマルチコアの潜在能力を活かしてプログラム
全体の速度を上げられないかと言い出したらそういうプログラム
を作ればいいが、そうするとシングルコアと同じく多数のプログラム
は同時に動かしにくくなる。

どうせみんな8つくらい同時にプログラム動かすよね。
じゃあ、クライアントアプリなら、なんも考えなくてもいいんじゃないか

8つくらい立ち上げてても、ほとんどのプログラムは待機状態だと思う

>>781
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>692 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>709 比較なんかしてないぞ

「違う」と書きながら、指摘されたら「比較してない」って言い張るわけですね。
比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

まあ、「逃げる」とか書いてるぐらいだから、流石にもうでてこないだろう。
普通に考えても、恥ずかしくて出てこれないと思うけど。(w

>>790
>692と>709は別人ね。

マルチコアに対応と言っても並列化したいのはほんの一部分だし、
スレッドプールとタスクキューを作れば何とかなりそうな気が…

つまり「ミニOS」みたいな構造にしてCPUにさせる仕事を細かく分解し
やらせる仕事は片っ端からキューに叩き込んで行き仕事を終えたコア
が次の仕事を取りに来る、とか

並列化したい部分なんてのは単純に並列化すればいいだけで何の問題もなく、
特に並列化したいわけでもない普通の部分をいかに並列化してパフォーマンスアップに繋げようかってのが難しいんじゃない？

>>790
>>692の中のアンカー読めるか？>>692は>>689へのレスだぞ
そして>>709の名前欄読めるか？>>709は>>689だぞ
>>692と>>689=709は別人、流れはこうだろう

>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

比較して違うと言ったのは>>692
比較してないと言ったのは>>689

> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

謎なのはお前の読解力だw

長文ウゼ(´Α｀)

よくしらんがコンカレントCとかadaとかか？

>>795
まあレス番素直に読めばそうだな。

そうすると、>>708 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w

すまん、レス番間違えた。

そうすると、>>709 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w

>>784
パイプラインを細分化してもレイテンシが大きくなりすぎて効率が上がらないし
配線間隔が狭くなりすぎてリーク電流を抑えるのに神経使う時代が到来した今
シングルコアでクロックをひたすら上げるアプローチなんてどこもやらないよ。
強いて言えばPOWER6くらいか。

5年で5〜10倍なんてペースで進化する時代はもう終わった。

コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
一番有効な手段だったりする。

>>799
> そうすると、>>709 は話の流れに関係なく唐突に

もう一回書くぞw

>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

AがBに「比較するな」と言い、BがそれはCに言えと言い、
それでCが「比較してない」ってのは「話の流れに関係なく」でも
「唐突に」でもないだろ

>>709=689 (俺は)比較なんかしてないぞ

の方がよかったかもしれんけどな
突っ込むなら比較して違うと書いたくせにCに振ったB(>>708=692)だろ

だったら、おまえら二人で相談でも何でもして解決してくれよ。

俺は、>>692 に「比較するのはおかしい」と指摘しただけで、
お前ら二人が別人かどうかなんてわからんのだし。

>>802
> お前ら二人が別人かどうかなんてわからんのだし。

誤読しといて開き直るなよw

ここ住人は行った人結構いそうだな
ttp://d.hatena.ne.jp/potasiumch/20080827#1219824560

＞一般企業での並列化は遅々として進んでいない。某 Ad○be 社に
＞並列化コンサルティングに行ったところ、「○○処理の部分はプログラマが
＞だいぶ前に死んだのでそれ以降誰も触っていない・触れない」「え、リコンパイル？　
＞そんなことしたらもう動かなくなったりしないかなあ」などと言われた。

＞（だからあの会社の製品はあんなに重いのだろうか？）

ワロタと同時にゾッとした

シングルコアとクロック数の話で　「周波数と消費電力が2乗の関係」
ということが論じられていない件について

ああ、CPUなんて1Hzでいいよ

>>806
fは1乗

CMOSデジタル回路の消費電力

P = Na×C×V^2×f + Nt×Il×V

P:消費電力
Na:動作ノード数
Nt:全ノード数
C:ノード容量
V:電源電圧
f:周波数
Il:ノード当たりのリーク電流

>>806
同じアーキテクチャで同一電圧での話なら2乗だけど
ある程度以上はクロックを上げるのに電圧盛らないといけないので3乗になるんじゃなかったっけ

>>806
ここはソフトウェアの板だから、そっち方面の話題の需要は無いと思われ

ソフトオンリーの人がハードを含む話をすると悲惨たからな。
>>50->>57あたりにソフトウエアの板のマルチコアCPUに対する理解度があらわれているよ。

ソフトウエア板住人の

生活に直結していないから不要な知識なんじゃないの。
多分 >>803 みたいな話がむしろ当然な世界でしょ。
食い扶持に影響する様になったらガッと動くけど、
手を抜ける所は手を抜くのも仕事では重要だし、
コア数が一桁のうちは今のままでも困らないかと。
秘伝のソースを書き換えたりアーキテクチャを一から
変更したりするとテストだ互換性だと色々面倒だし。

ｽﾏｿ。レス番間違えた。

×　>>803
◎　>>805

レンダラーとかゲームの思考エンジンとか、並列処理に向いてるソフトウェアでも
売り物じゃないオープンソースのは並列化されていない事が殆どだね。やっぱり
一手間加えるのがマンドクサイのかな。

>>800

> コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
> 一番有効な手段だったりする。

いやだから、そんなことは当たり前であって。2個とか4個とかなら、その
CPUをフルに活用するようなプログラム作れるかもしれないが。

100個とか1000個とかになったときには言語レベルで支援がないと
きつくなるのじゃないかな？っていう話。まぁ100個とかになる前に、
バスネックになると思うが。

100 CPU 越えのマシンは既にあるよ。
1 socket で 64 並列の CPU もあるし。

>>803
おまえらが別人かどうかもわからんのに誤読とか言われても知らんがな。
にちゃん初心者か？

>>816
なるほろ
確かに、これから先コア数がガンガン増えていったとして
デクストップアプリケーション、例えばExcelなんかが
その性能に比例して進化していけるのか
今までのアプローチでそれが可能なのか
不安が残るな

今のスペックでそこそこ動いているものを挙げたって仕方ないだろ。
コア数が増えるならそれに適応したシステムになるのは当然。
コア数が増えて初めて恩恵を得るようなものを作っていかないといけない。

マシンがすでにあることなど関係ない

>>811
どうみてもまじめにつっこむとことちゃうだろ

>>818
くやしいのうwwwwwくやしいのうwwwwww
「レス番素直に読めば」別人ってわかるだろうがw開き直んなw
もう一回書いてやるよ。こぴぺだけどな

>>692の中のアンカー読めるか？>>692は>>689へのレスだぞ
そして>>709の名前欄読めるか？>>709は>>689だぞ
>>692と>>689=709は別人、流れはこうだろう

>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

比較して違うと言ったのは>>692
比較してないと言ったのは>>689

> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw

オマイ等そろそろ他所でやれよな。
2ch だからって何書いても良いという訳じゃないんだぜ。

ああそろそろ規制議論板に報告して芋掘りしてもらう頃合いだな

>>823
> 別人ってわかるだろうが

そもそもお前が誰かもわからんのに、何を言ってるんだろうこの人。(w

>>826
そうだね、君の読解力じゃ無理だよねw
笑えるよなぁ、コテハン付けて勝利宣言(>790)のつもりが墓穴だもんなwww
そのコテハンそろそろ捨てた方がいいんじゃないの？他の人に迷惑だしさ
普通に考えても、恥ずかしくて出てこれないと思うけど。(w

私のために争うのはやめて！
てのはさておき、いい加減にしたらどうなんだ。

元の話でいえば、シングルコアのCPU上のマルチスレッドプログラム
が、マルチコアのCPU上で動作しなくなることなんて、バグじゃなく
ても当然ありうる。タイムスライス限定とかいうなよ？自分の
知ってる範囲だけがマルチスレッドじゃないのだから。

優先度に基づいたマルチスレッドもあるし、そういう環境で無駄な
排他を排除することは当然ありうる。マルチスレッドじゃないが、
割り込み禁止で排他する場合も、マルチコアじゃぁ別のCPUで
割り込みハンドラが動くこともある。

最初からシングルコアっていうかその環境専用に作ってるならバグじゃないし
マルチコアは想定外と最初から言ってないなら普通はバグと判断される
それだけのこと

>>829
何をいいたいのかわからんが。そのプログラムがどんな
システム向けに作られたかしだいでしょ。最初から
「マルチコアを想定して作ることを求められたプログラム」
ならバグであるし、そうでないならバグではない。

30年前のシングルコアしかなかった時代のプログラム
は全部バグっているというのかい？

折角の週末を無駄にして、君たちは一体何と戦っているんだい？

>>830
俺は>829に同意。
デフォでマルチプロセッサをサポートしてるのが当然な環境が今は多い。
PCでもWindowsNTWSは最初から2プロセッサをサポートしてたよな。
動作環境にNTが含まれていたら、対象外と明示していない限り、
マルチプロセッサ／マルチコアで動かなければそれはバグ。
前提の環境がマルチプロセッサを含まないことが明白な場合は別。

>>832
だから、なんのプログラムに対してバグっているといっているのだ？
仮にあなたが発注元で要求仕様に「マルチコアでも動作すること」
という条件を含めていなかったら、それはバグではなくて仕様。

その変のフリーでころがってるプログラムがマルチコアで動作しな
いとしたら、それは＊あなたが＊バグであるかどうかを判断する
立場にはないよ。作者がマルチコアに対応するつもりでプログラム
作っているなら＊作者＊はバグであるというかもしれないし、
シングルコアのみに対応するつもりなら、＊作者＊は仕様だと
いうだろう。

前提が不明なのだよ。

それはない。逆。
このソフトはマルチコア環境では動作しません。
とうたっていない限り、バグ。

>>833
仮に動作環境がWindows2000やXPだったら、「マルチコアで動作しない」
と書いてない限り、動かなかったらバグだよ。
OSがサポートしている環境ではマルチコアもその範囲内だから。
それは明白だよ。不明じゃない。
はっきり書いてない場合にマルチコアで動いて当然の環境があるんだよ。
作者がマルチコアを想定してなくて動かなかったなら、コードを直すか
ドキュメントの動作環境を直すかのどちらかは必要だろう。
つまりコードのバグか、ドキュメントのバグかのどちらかになる。

極端な話、3GHz以上のCPUでは動きませんと明記していないかぎり、
3.2GHzだろうが5GHzだろうが暗黙の了解でソフトは動いて当然。
動かなかったらバグだろ。それと同じだよ。

特殊なソフトじゃない限り、「シングルコアのCPUじゃないと動きません」なんて、許されんな。

『動く』と書いてあるのに動かないのはバグ。
書いてなくて動かないなら、動かなくてもおｋ

『動かない』と書いてないのに動かないのはバグ。
書いてあって動かないなら、動かなくてもおｋ

>>835
Windozeとか、べつにタイムスライスしかないのだから、ドライバで
ないかぎりマルチスレッドプログラムは、普通にマルチコアでも動く
だろ。何をいってるんだ？

>>840
上のほう読んでよ。アトミック操作を適切に行っていないプログラムは、
マルチコアで動かないけどシングルコアでマルチスレッドなら動くって眉唾なこと言っている奴がいたんだ。

>>838
そう思ってるのは開発側だけだな。

そういや昔、マルチスレッドのプログラムがちゃんと動くかどうかテストするのに
マルチプロセッサのPC組み立てたっけ。
90MHzのPentiumでDaytonaだった。

高速なCPUで動かないｿﾌﾄといったらWindows95だろ
たかだかK6-2の350MHzでｺｹるってどんだけだよと

コア数が増えてoccam復権しねぇかなぁ

>>843
マヌケだなｗ

>>840-841
二人とも0点

一般的なソフトウェア開発の観点では、プロセッサもしくはランタイム環境の、主にメモリモデルに起因する問題が多い

>>864
理解できない時は素直に認めた方がいいぞ。

スルーパス出ました

>>827
>>826

このスレ絶望的にレベルが低いですね。

今日はそうみたいだな。

ダンゴさんが最近発言していないからな

ここ的にはMSのCCRは問題外ですか?

LeopardでLAMMPIをコンパイルしたのですが正常に動きません。
なんでなん

お前がバグだからだ

俺がバグだ
目標を駆逐する

超初心者なんですけど、
quad coreで単純に４つのexeファイルを起動したとき
それぞれのプロセスが各CPUに割り振られて
シングルコアの４倍の速度になると考えて良いでしょうか？

exeファイルはシングルコアで動かすときのプログラムと全く同じで
何も変えずに4つ実行するということで。
要は、quadで動かすときに何か特別なプログラミングをしないといけないの？
ということなんですけど。

cpuしか使わんプログラムなら4倍になる。

>>861
４倍にできない場合ってどういう場合なんでしょう？

ディスクアクセスなど入出力が多い場合とか

メモリアクセスとかにもよるだろ。
CPUのアーキテクチャにもよるだろが。

演算性能上げるのに並列処理を抽出してプログラミングするには、
書く内容がかなり変わる。

シングル用に書かれたプログラムは、そのまま実行できる。

シングル用のプログラムの性能は、ほとんど同じ性能で走ることもあるが、
メモリバス性能など、ネックがある箇所によっては各々が1/4がそれ以下の性能しか
出ないこともある。

例えば大量にメモリアクセスするようなら、メモリアクセスがボトルネックになって性能出なかったりするわな

NUMAにしてローカルなメモリ意外触らない

特別なプログラミングしてるじゃねーか

だから4つコアで4つプログラム動かしたときって言ってるだろ。日本語が読めないのか？

誰に言ってんの？
どれに言ってんの？

IKE NUMA

メモリでボトルネックに成ってたらほとんどの処理は絶望的だな。
ディスクもネットももっと遅い。

OpenMPとOpenCLとboost::threadとpthreadとWindows API threadの良し悪しを教えてくださいませんか？

ほらyo
OpenMP×
OpenCL ×
boost::thread ○
Windows API thread ×

CCRはネ申..._φ(ﾟ∀ﾟ )ｱﾋｬ

PS3薄型と旧型の違い

旧型PS3：
Linuxインストール機能内蔵でPS3をPCとして使うことができる。
PPC Linux用の無料のソフトがいっぱい動く。
また、Cellの開発ツールも無料で入手できるので自分でCellのプログラムを作って実行させることができる。
ドルビーTrueHD、DTS-HDMAはリニアPCM変換で対応。
HDD〜80G。実勢価格30000円程度

薄型PS3：
Linuxインストール機能は除去された。
ブラビアリンク機能でブラビアと連動した電源のON OFFができる。
ドルビーTrueHD、DTS-HDMAのビットストリーム出力対応。
HDD120G。低騒音低発熱。実勢価格29980円

シングルコアのPC上で動作させるwindowsのタイマーを複数使ったプログラミングを
マルチコアのPCで動作させても並列処理にはなりませんか？
何か特別なやり方とかしないといけないでしょうか？

なるわけがなかろう

>>878
やっぱりそうですか。
もう根本的に無理ですか？

シングルコアのPC上で動作させるwindowsのタイマーを使ったプログラム複数を
だったら。

そもそも、そのタイマーの処理は、並列実行しても安全なようにコードを書いてあるのか？

>>880
やっぱり複数のアプリを立ち上げないとダメなんですね。
>>881
普通にタイマーを複数作っているだけで、
どう作れば並列実行に安全かもよく分かりません。

まず、そもそも並列する意味があるかどうかをだな

>>883
意味ははあります。
とりあえず複数プログラム間でのプロセス通信はしてますが、
通信だといろいろ設定やらやり取りがややこしいので、
一つのアプリで並列動作させたいのです。

「タイマとか関係なく、1プロセス内で平行処理させたければ、スレッド起こせ」という結論でFA
まあCreateWaitableTimer + RegisterWaitForSingleObjectのように勝手にそこまでやってくれるような組み合わせもあるけど。

>>884
それってマルチスレッドにすれば解決するか、
マルチコアで並列にしても解決しないか、どっちかだろ。

OpenMPを使えるか調べてみたら？
複雑な同期がいらない並列プログラムなら手軽でいいよ

Interlocked周りを使ったパターンってあるもの？
いままであまり使ったこと無かった。
RWLockとかにもつかえそうなんだが。

そりゃいくらでもある。
全ての同期の基本に近い。

たとえば？

ミューテックス・クリティカルセッションなどと呼ばれるもののの実装とか、
あとは、Lock-freeでググれば、キューとかリストの実装も見つかるだろう。

その話題はマルチスレッドスレでやってる。

マルチスレッドで書けば、マルチコア対応にも成るからなあ。
結局の所、マルチコアを使いこなすならマルチスレッドで書いとけもひとつの解だし。

つーかマルチスレッドとマルチコアってわけんの？
おなじCPU上で動かす云々とかもあるけれどあまりそこまで意識しようとしてないわ-

キャッシュのコヒーレンシの問題あるからなあ
共有メモリで互いのメモリ監視が多い場合、マルチコアのシステムだとかなりパフォーマンスが落ちるはず

互いにほとんどメモリ参照しないで走っている感じだとマルチコアのほうがHTTよりもパフォーマンスがいい可能性もある

プログラムの種類にもよるだろうけどそこら辺を考慮した実装と市内ものでどれだけパフォーマンスに違いあるかみてみたい。
たいてい1割も違わないんじゃ？

いやいや、並列化が本当に必用な領域では、キャッシュ
コヒーレンシ維持のためのオーバーヘッドや各スレッドの
連続する処理でアクセスするメモリのサイズについて真剣に
考慮しないと下手すると何倍もの差が出るのが通常だよ。
少なくとも俺の経験では。

そもそも複数のスレッドでメモリ空間が重複してる時点で
並列化失敗してるんじゃないの？

逆だ。キャッシュの効率を考えて、同じCPUで近いメモリ空間を使うように設計するんだ。
例えば行列演算の場合、2core*2cpuならCPU間では空間を離し、core間は近くする。
巧くすれば、対策前の2倍は充分有り得るね。

>>899
fortran あたりは、よきに図らってくれたりしないのかな？

そんなコンパイラスイッチ見た事無いな。
インテルのCPUが出る旅にバージョンアップが必要とか？

>>901
すまん、スパコンとかそっち方面を考えてた
インテルの fortran って、自動並列化は結構賢いって聞いたことがあるが…

>>899
core毎に隔離した方が良い

>>903 CPU によっては L2 がコア間共用だったりすることもある

まぁそこら辺はプログルマがごちゃごちゃやるよりコンパイラの中のエロイ人にやって欲しいものだ( ﾟДﾟ)y─┛~~

するとプログラマの人件費が減らされて、メーカ謹製のコンパイラ代に変わる訳だが。

共用キャッシュでもいろいろ有るしなあ。プリフェッチ深いのとか。
クラウドコンピューティングとかごった煮環境じゃ最適化厳しいでしょ。
スレッドプログラミングで最大公約数的な所で落ち着くと思うけど。

今時のスパコンってたったの2コアだったりするの？
ALUとか実行ユニット積みまくれば速度は稼げるのかもしれないが。

>906
いやその分プログルマは他の所に時間が割けるようになるでしょ？
自分で考えられる人工知能が出来ない限り要素の調停を行う場所がシフトするだけでプログラマの仕事は変わらないよ。

>>906
> 今時のスパコンってたったの2コアだったりするの？
パッケージ内のコアって意味ならたいして多くない。数使ってなんぼの世界

NEC SX-9: スカラユニット x 1 + ベクトルパイプ x 8 で 1 CPU
シングルノードで4〜16CPU

つか、今時、専用プロセッサ使ってるの NEC 位じゃね
cray は opteron だし
IBM は Power6 とか CELL だし
日立は IBM 製品使うみたいだし
富士通は命令拡張したマルチコア sparc に行くみたいだし

>>908
NECが専用使ってるのは国策？

>>909
10 ペタマシンからおりちゃったし、違うんじゃないかな？

Power5/6はデュアルコアだけどL2が共有だからHPCに使う場合は片方のコアつぶして
シングルコアとして使う

>>911
Power6 は L2 分離だったはず。
調べようと思ったらいつの間にか有料にorz
http://www.research.ibm.com/journal/

>>912
ｽﾏﾝｶｯﾀ

Allowable Card Account Number Lengths Visa Card 16 digits. ,

メニーコアとSMT対応ってどう違うんだ？
4コアCPUと2コア4スレッドCPUのパフォーマンスは同じにならんの？

>>915
普通のアプリだとそこまで気にすることはないと思う。

OSのスケジューラなんかだと、今実行できるスレッドが2つのとき、
2コア4スレッドの環境なら、片方1つのコアで2スレッド実行させるより
2つのコアで1スレッドずつ実行させるほうが効率がよい、なんてことも気に掛けるみたいだけど。

4コアは演算器の完全なセットが4つある
2コアは演算器が2セットぶんしかないが、もし空いてればそのぶんは別のスレッドも動かせる
例えば整数演算メインのスレッドと浮動小数点演算メインのスレッドがあれば、
お互いメインに使う演算器が違うから同時に動かせる率が高いけど、
整数演算のスレッドばっかりだと同時に動かせる率が低い
って感じじゃね

HTはたまたま空いてるCPUの演算機を使って仮想的にもうひとつスレッドを動かす。
だから、仮想スレッドはせいぜい20〜30%までの性能が限度。
普通10〜20%とか、もっと低いくらい。
マルチコアとは全く違うよ。

コンパイラの吐き出すコードの効率が高いほど
HTの効能下がるな。

どういうオプション指定かにもよるので。
シングル用かデュアル用ならHTも悪くない。HT用が最良だけど。

新しいサーバ買ってもらった。16コア。何に使おう

梱包して発想の準備をしてから待っていてくれたまえ。

窓からぶん投げる日を教えてくれ。

パイプラインの長いコアだとHTは効率改善には効果的みたいだな。
１コア辺り８スレッドなんてのもある。
しかし、効率はいいんだろうが、スレッド視点で見たとき
期待通りにうまく動くんだろうか…

(´・ω・｀)

コンピュータサイエンス史上最大の課題「並列処理による性能向上」
〜情報処理学会創立50周年記念全国大会の招待講演
http://www.publickey.jp/blog/10/50.html

>>926
その人の顔入りマグカップが送られてきた気がするが、即捨てたな。

なんともったいない。どんな絵柄であろうとも、マグカップとしての機能には
何の問題もないというのに。

>>926
高水準で問題領域を絞ったDSLが開発される方向を想定してるのか
つまり処理系にできるだけ多くの情報を与えて、最適化をがんばらせると

実用上は、処理系がうまくやってくれないケースもあり得る以上は
抽象を破って低水準をプログラマが直接操作できるメカニズムが必要だと思うんだけどな
かといって、低水準から高水準まで幅広くサポートしようとすると
C++みたいな化け物になりかねない……

飲もうとする時に、その人の顔を見てしまう事で味が変化するとしたら損失だろう。
便所とかに置かれてるとかペット用になってるとかだとアレかもなw

プログラマが最適化出来るとも限らない訳で。

>>930
カップの絵柄で中身の味は変化しない。
貴方の主張は非論理的すぎます。

中身は変化しないが
味覚というのは脳が眼耳鼻舌身(触覚)意識を総動員して感じるものだから
見た目が変われば味が変わるということは非論理的なことでは決してない

うんこ食ってるときにカレーの話なんかするなよ

むしろ化学的な組成という客観量から味という主観的な概念が
一意に決まるという考えの方が非論理的

>>926
汎用言語を捨てるならいっそ汎用プロセッサも
諦めてしまえば…と思ったが、先祖帰りな気がするなあ

そういやjavaプロセッサってもう無いのかな？
ibmの汎用機とかはjava処理用のプロセッサ積めるらしいが。

専用言語が実行速度的には有利だろうけど、習得に時間がかかるので、既存の汎用言語で最適化したほうが、まだ有効だろうね。
全世界を専用言語の英語に統一したほうがコンピューティング処理が向上するから、日本語処理を諦めようというのを日本語で公演する矛盾を感じる。

Jazelleが使われているシーンを見たことが無い
いやどっかでは使われてたんだろうけど・・・

C言語の呪縛
http://techon.nikkeibp.co.jp/article/TOPCOL/20091209/178442/

この記事を思い出した。
理想はともかく現実的にはこういうアプローチも必要なんだろうね。

これからはErlangやScala、CCRのようなメッセージ伝達並列性が主流になる.

WindowsおよびはUnixでC++を使ってプログラミングしています。
4コアのCPUを使っていて、1スレッドのプログラムを実行したとき、
タスクマネージャで見ると使うコアが次々と変わっていくのですが
これを抑止する方法はありませんか？

Windows(Win32)ならsetThreadAffinityMask()

便乗で質問させて下さい。
スケジューリングから外して、このコアはこのプロセス(スレッド)専用だからねっ！！ってできますか？

そりゃ、無理だ。
DeviceDriverの挙動までは手が出せないからねぇ

>>939
Solaris では processor_bind(2) を使えば、スレッドを CPU に完全に貼付ける事が出来るよ。
同じ事をするコマンドで pbind(1M) というコマンドもあります。1スレッドのプログラムなら
コンテクストスイッチが無くなる分、性能も良くなります。

http://docs.sun.com/app/docs/doc/816-5167/processor-bind-2
http://docs.sun.com/app/docs/doc/816-5166/pbind-1m
http://developers.sun.com/solaris/articles/solaris_linux_app.html

>>941
Solaris では psrset(1M) コマンドで CPU のプールを作って、それをあるプロセス（スレッド）
だけに割り当てる事が出来るよ。psrset -f でその CPU がインタラプトを処理しない様にも
設定出来るから、デバイスドライバにも影響されず、ほぼ完全に CPU を占有出来ます。

http://docs.sun.com/app/docs/doc/816-5166/psrset-1m
http://developers.sun.com/solaris/articles/solaris_processor.html
http://docs.sun.com/app/docs/doc/816-5166/psradm-1m

>>943
うわーーー、知らなかった。
ありがとうございます。
Solarisなんて随分触ってなかったけど、ちょっとOpenSolarisでもいじってみます。

OpenMPで各スレッドをそれぞれのコアに貼り付けるにはどうしたらいいのでしょうか？
Linux、g++です。

http://pc12.2ch.net/test/read.cgi/tech/1102483474/
OpenMPプログラミング

あげ

Corei3なんですけどどうすればSSE2命令を並列に実行できますか？

GPUに汎用計算させたほうが行列演算は高速になりますか？

要はどうしたらいいんですか？

何をしたい訳？

それが判らないから聞いているんです。

ヲレには心当たりが無い。残念だったな。

まずは、パンツを脱ぐんだ

既にノーパンで全部剃ってるけどな。舐めても安全。

>>955
おいらの義妹はそんな下品なことは言わない。

マルチコアってマルチスレッドで効果があるみたいだけど
マルチプロセスだとどうなの？
windowsとかのバックグラウンドプロセスにも効果でてる？

>>957
M$のOSはしらんが、make -j<N> とかやるとちゃんと効いてるわな <Unix系OS

>>957
Windows のマルチプロセスは組みにくい。fork() にあたるものがない。
逆に、p-thread って誰得？と時々思う。

つまりですよ、マルチコアを意識して
マルチスレッドプログラミングをわざわざ書かなくても

常に他のプロセスにコアが割り当てられているから
アプリ側はふつうにシングルスレッドプログラムで
作れば十分なんじゃないかなーと思って聞いてみたわけです

十分かどうかは処理の内容によるでしょ。
スレッドの切り替えよりプロセスの切り替えの方がコストが掛かるし、
データの受け渡しも大掛かりになる。

ピクセル単位の画像処理なんかはスレッドを使うのが普通だろうし、
ウェブサーバとかなら I/O 待ちの時間が多いからマルチプロセスでも
良いんじゃねとか、そんな感じ。