トップページ⇒tech
987コメント322KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん2006/01/18(水) 08:31:11
最近のCPUはマルチコアが技術トレンドになっています。

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

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

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

【関連スレ】
OpenMPプログラミング
http://pc8.2ch.net/test/read.cgi/tech/1102483474/l50
0002デフォルトの名無しさん2006/01/18(水) 08:38:30
乙
ネタ的には面白そうなネタだと思う
0003デフォルトの名無しさん2006/01/18(水) 08:42:20
マルチコアの場合、メモリーとのアクセスはどうなってるの？
バス幅やバスクロックは変わらないようにも思えるけれど・・・

マルチなバスがあって、マルチにメモリーにアクセスしてるとか？
0004デフォルトの名無しさん2006/01/18(水) 08:46:11
関連

マルチスレッドプログラミング相談室 その４
http://pc8.2ch.net/test/read.cgi/tech/1130984585/
0005デフォルトの名無しさん2006/01/18(水) 08:49:54
>>3
コアが複数になってもメモリへのアクセスは変わらないので、
今まで以上にメモリ帯域やバスがネックになりそうな感じ。

コアが複数でもI/Oの数（メモリやハードディスク、グラフィ
ックカード等）は変わらないので、それをどうするのか？
というのは問題ですよね。
0006デフォルトの名無しさん2006/01/18(水) 08:53:48
そのうち、それぞれのハードにバスキャッシュが乗るんじゃね？ｗ
バス同士のデータのやりとりで、アクセスロックが発生しかねんが。
0007デフォルトの名無しさん2006/01/18(水) 08:54:15
>>3
各社各様。当然クロスバーにしている所もある。
0008デフォルトの名無しさん2006/01/18(水) 11:43:21
マルチコアの特定のCPUにチューニングするとかしない限り、
従来のマルチプロセッサ向けのマルチスレッド化との違いは、
ないと思われ。

ということで、終了。
0009デフォルトの名無しさん2006/01/18(水) 11:51:57
コア間の転送スピードが速いとかキャッシュの共有が可能とか
わりとマルチプロセッサとは違う動作する

マルチプロセスだとうまみはないが、マルチスレッドによる最適化は
こっちのほうが影響を受けやすい
0010デフォルトの名無しさん2006/01/18(水) 14:54:58
シングルコアだとcopy on writeが有効だけど、メニーコアだとすぱっとcopyしてしまったほうがコア間の依存関係を断ち切れて、かえって効率が上がる、と言う話を聞いたことがある。
こういう、従来の高速化手法をひっくり返すようなものって他にどんなのがあるの?
0011デフォルトの名無しさん2006/01/18(水) 16:46:51
CoWってどのCoW？
0012デフォルトの名無しさん2006/01/18(水) 17:42:46
ライブドア全力で逝った人は自業自得としか言いようが無いね。
今年は少し負けてるけど、我慢してずーっと東１銘柄だけ取引してたから
良かったよ。

新興はもうだめだな。しばらくは様子見しよう。
0013デフォルトの名無しさん2006/01/18(水) 17:43:21
↑
はげしく誤爆。すまそ。
0014デフォルトの名無しさん2006/01/18(水) 17:51:33
>>12
今年で負けてるってどんな銘柄買ってんの？
下手なのはいいけど、人の不幸見て喜ばないように。
0015デフォルトの名無しさん2006/01/18(水) 18:03:08
昔の同僚がやってる会社の株を持ってるぜ。買わされたようなもんだが。
0016デフォルトの名無しさん2006/01/18(水) 18:19:38
京都の漬物ｳﾏｰ
0017122006/01/18(水) 18:30:27
>>14

昨日今日の市場暴落劇知らないのか？
今年はまだ半月しか経ってないから犠牲者多数出てるよ。
職場で昨日から青ざめてる上司とか今日いきなり欠勤した人
とかいない？
0018デフォルトの名無しさん2006/01/18(水) 18:40:23
>>12
知ってていっているんだけど。今日は完全にブラマンだよね。
去年の年末は稼がせてもらったけど、最近はノーポジ。
底で口をあけて待っているところ。

というかスレ違いだ。
0019デフォルトの名無しさん2006/01/18(水) 18:40:33
ライブドアか・・・今なら貝かな？ｗ
0020デフォルトの名無しさん2006/01/18(水) 18:42:00
ﾜﾛｽ
メガデモ、マルチコアときて次は株スレ@ムが立つか？
0021デフォルトの名無しさん2006/01/18(水) 19:17:13
効率なんて人間に考えさせてるようじゃだめ。
人間は人間にとって作りやすく分かりやすい
ようにプログラムを作って、あとは全自動で
それを効率よく動かすようなシステムを作る
べきだ。

人間に最適化をやらせるとろくなことはない。
そんなもんはC言語で散々やられてわかっって
るだろう? 無理にポインタ使って効率よく
作ったプログラムは読みづらいばかりか後の
コンパイラでは最適化の邪魔になったじゃないか。
0022デフォルトの名無しさん2006/01/18(水) 19:20:22
未来のコンパイラのために今のプログラムを劣化させるべきだというのかい？
しかも未来のコンパイラがどんな最適化をしてくれるのかもわからないというのに
0023デフォルトの名無しさん2006/01/18(水) 19:31:05
あったあった。
ttp://pcweb.mycom.co.jp/news/2005/12/19/046.html
こういうのがほんとに普遍的に作用してくれるなら楽だろうね。

ただ、こういうのを使ったとしてもハード側とソフト側の両方に対して見識が深くないと
有意な高速化はできないだろうなあ。
どうやっても複数コアでは高速化できない類のプログラムってのも存在するはずだし。
0024デフォルトの名無しさん2006/01/18(水) 19:46:56
>>23
やっぱり理想は自動並列化だよね。特に自動並列化コンパイラ
には期待だけど、マイクロソフトなんかは今になってやっと
OpenMPを実装したから、普及は思っているより先になりような
予感はする。

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

並列化の割合を上げるには、タスクをアトミックな単位で
分割して並列実行するのがよろしいのかと思います。
おそらくもっともアトミックかつすでに自動的な並列化である
CPU内部のスーパースカラの本数を増やすとか同時実行できる
命令の種類を増やすために実行ユニットを増やすといった
方法はなぜとられないんでしょうか。多分、CPUメーカーの
人とかは解っててやっているんでしょうが。
0025デフォルトの名無しさん2006/01/18(水) 19:58:58
>>24
たぶん
＞並列化の割合を上げるには、タスクをアトミックな単位で
＞分割して並列実行するのがよろしいのかと思います。

これが間違いだからじゃない？
既存のタスクを自動的に分割しても並列度はあまり上がらない。
0026デフォルトの名無しさん2006/01/18(水) 20:15:01
そこでいよいよ並列化プログラムを書きやすいと言われている関数型言語の出番か？
0027デフォルトの名無しさん2006/01/18(水) 21:20:17
>>26
そうなの？ポインタあったら教えて。

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

確かに何となく自動並列化みたいなのはできそうな気も
するけど、気がするだけでよくわかんないな。
0028デフォルトの名無しさん2006/01/19(木) 00:05:07
関数型で並列か。そろそろ Erlang の時代が来るかな。

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

過去、どんなに頑張っても４並列くらいまでしかいかなかったから。
0029デフォルトの名無しさん2006/01/19(木) 00:20:01
Erlang
→http://www.kmonos.net/alang/etc/erlang.php#process1
スレッド間のやりとりにはメッセージ通信で実現するみたいですね。

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

組み込みではμTRONがOSはメッセージボックスつーのがあって
タスク間の通信ができるのですが、Windowsってそういう仕組み
がないですよね。一応SendMessageとかのAPIはスレッドセーフに
なっているけど機能不足だし。
0030デフォルトの名無しさん2006/01/19(木) 00:39:57
関連スレ

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

日本発、次世代言語：　織田信長
http://pc8.2ch.net/test/read.cgi/tech/1047230229/
0031デフォルトの名無しさん2006/01/19(木) 00:44:50
>>27
関数型言語では、変数代入でなく束縛（再束縛禁止）が普通なので、
式の前のほうと後ろのほうに依存がなく、
処理系が勝手にバラバラのスレッドで実行できる。
副作用なしなので当然スレッド間の干渉はない。

とよく知らんけど妄想。
0032デフォルトの名無しさん2006/01/19(木) 01:01:21
副作用なしっていう制約下でマットウにプログラムかけるやつがどれくらいるのか
という問題はある
0033デフォルトの名無しさん2006/01/19(木) 01:01:38
>>29
Javaが5.0になってからマルチスレッド回りの処理が大幅にパワーアップしたけど
これもマルチコアを見据えてのことなのかなぁとおもった

JavaやC#とか高級言語はどんどんこの辺は容易になって来るでしょうね
逆にC++とかはガリガリかけるけど、つらいものが
0034デフォルトの名無しさん2006/01/19(木) 01:08:49
>>33
C言語も重い腰を上げて言語レベルでの並列処理を(C++0xとかで)
サポートしようという動きもあるみたい。今まで言語で並列処理
を何でサポートしなかったんだというのはあるけど。
0035デフォルトの名無しさん2006/01/19(木) 02:09:16
トータルの処理コストは 1.5 倍になるが、完全に並列化出来るから、
実行時間は 2 スレッド時で 0.75 倍みたいな世界が来るのかしら。
0036デフォルトの名無しさん2006/01/19(木) 02:36:54
C++はBetter Cだからなぁ。正直あんなつぎはぎの言語仕様
ぜんぜん使いたくない。JavaとかC#のほうがよほど洗練され
ていると思う。ヘッダファイルとかローテクすぎ。
0037デフォルトの名無しさん2006/01/19(木) 03:30:19
>>C++はBetter Cだからなぁ。

馬鹿発見。
0038デフォルトの名無しさん2006/01/19(木) 04:09:42
>>9
現実のアプリケーションで性能差がどれくらい出るの?
プログラムをチューニングするほどの差がないなら、終了、だよ。
0039デフォルトの名無しさん2006/01/19(木) 04:13:09
複数のスレッドに分割するのが大変なアプリで、速度を要求するものってあるの?

重いアプリは、
今まで通りに、おおきな粒度で水平垂直に分割すれば、速くなるじゃないか。
0040デフォルトの名無しさん2006/01/19(木) 04:21:39
そうは言っても、
昔なら遅くなるし面倒だからやらない、なんて感じだった
付加的な処理でも、ＣＰＵの速度向上や生産性の向上で
どんどん付ける様になってる。

そうやってソフトが進化してきたのが、ＣＰＵのコア速度頭打ちで終わってしまう。
0041デフォルトの名無しさん2006/01/19(木) 04:25:16
>>32
最初からそういうプログラミングを教育をすれば良いじゃない。

Cやアセンブラから入ったＤＱＮＰＧはオブジェクト指向が理解できないけど、
同レベルの奴でも最初からJavaとかで始めると理解できる、なんて話があるらしい。
0042デフォルトの名無しさん2006/01/19(木) 08:21:16
関数型もいいが、Prologとかの論理型も並列処理に向いてそうな希ガス
0043デフォルトの名無しさん2006/01/19(木) 10:36:06
手続き型が一番向いてないね。
0044デフォルトの名無しさん2006/01/19(木) 10:41:34
逐次処理なのがネックだよねぇ・・・。

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

だから、今のCPUとOSを使う限り、粒度の大きなマルチスレッド化しかない。
そのスレッド分割を人間がやるか、自動化するか、ってことだよね。
0045デフォルトの名無しさん2006/01/19(木) 11:08:34
よくは知らんけど純粋関数型言語ってのは
入出力に副作用時だけ同期させてればいいのかな？
0046デフォルトの名無しさん2006/01/19(木) 12:50:11
>>42
織田信長がそうだな。並列論理型言語。
しかし、論理型言語なんて使ってる奴いるのか？
0047デフォルトの名無しさん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 秒)
0048デフォルトの名無しさん2006/01/19(木) 14:41:43
マルチコアの片方をGC専用にするのはありですか?
0049デフォルトの名無しさん2006/01/19(木) 14:44:05
"Concurrent Programming Language" の検索結果 約 24,700 件中 1 - 10 件目 (0.37 秒)
0050デフォルトの名無しさん2006/01/19(木) 15:24:48
そのうちマルチコアって言ってもCPUが4個とか8個とか16個とかが当たり前になるんだろうな。

そしてその後1スレッドを1CPUで動かす時代が来る。
0051デフォルトの名無しさん2006/01/19(木) 15:31:48
10年後。
CPUのクロックは100GHzになり、16384コア32768コアも当り前になり、
メモリは256Gバイトが3千円ぐらい。HDDは250Tバイトが1万円を切る。
もちろんPCの電源を入れると複数個のOSが同時に起動する。
0052デフォルトの名無しさん2006/01/19(木) 15:50:07
> CPUのクロックは100GHzになり、

わかってないな、こいつ
0053デフォルトの名無しさん2006/01/19(木) 15:53:03
>>52
なるだろう。
0054デフォルトの名無しさん2006/01/19(木) 15:54:53
>>52
電気で動くCPUとも書かれていないから良いんじゃない?
0055デフォルトの名無しさん2006/01/19(木) 21:01:49
これが技術的に可能になれば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
0056デフォルトの名無しさん2006/01/19(木) 21:44:58
実現してない話はどうでもいい
0057デフォルトの名無しさん2006/01/19(木) 22:59:21
シングルコアで順調に速くなっていくんだったら、マルチコアなんて要らんだろ。サーバはともかく。
１０年で分子コンピュータ技術が実用レベルに達して商用になるかと言えば、ならない方に賭けるな。
だってCPUの基礎技術は２０年以上変わってないのでは？
0058デフォルトの名無しさん2006/01/19(木) 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
　　　　( 　＾ω＾) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　氏ねよ 　　 　 ＼| 　 （　　　　）
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. ｵﾏｴ馬鹿だろ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/
0059デフォルトの名無しさん2006/01/19(木) 23:04:43
前：デフォルトの名無しさん ：2006/01/19(木) 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
　　　　( 　＾ω＾) 　　 　∧＿∧
　　　 ／ 　　　 ＼　 　（　　　　）何言ってんだこいつ
.＿＿|　|　　　 .|　|＿　/ 　　 　 ヽ
||＼　￣￣￣￣　　 ／ .|　　　|　|
||＼..∧＿∧　 　　(⌒＼|_＿./ ./
||.　 （ 　　　）　　　　 ~＼___＿_ノ|　　 ∧＿∧
　　/　　　ヽ　氏ねよ 　　 　 ＼| 　 （　　　　）
　　|　　　　　ヽ　　　 　　　　　　　＼/ 　　　 ヽ. ｵﾏｴ馬鹿だろ
　　|　　　　|ヽ、二⌒) 　　　　 　　／ .|　　　|　|
　　.|　　　　ヽ　＼∧＿∧　　　 (⌒＼|_＿./　/
0060デフォルトの名無しさん2006/01/19(木) 23:34:08
分子コンピュータの開発なんてもう10年以上前からやってるわけだが
0061デフォルトの名無しさん2006/01/20(金) 00:04:15

C MAGAZINE 2006年2月号
ttp://www.cmagazine.jp/
デュアルコア・マルチコアのCPUで大活躍
OpenMPで賢いマルチスレッドプログラミング（前編）
0062デフォルトの名無しさん2006/01/20(金) 00:06:04
いい最終回だった
0063デフォルトの名無しさん2006/01/20(金) 00:37:36
実際のところ最もパワーが必要になるのは鯖とかエンコとかゲームだから
それらはマルチスレッド化での効果はわりと大きいからべつにいいんじゃね？

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

あずーるとかみたいにハードのサポートが来るのが一番だと思うけどね
そうでなくとも中間言語系はバックグラウンドでかなり動いてるから
アプリは何もしてなくても2コアでもびっくりするほど恩恵を受けるよ
0064デフォルトの名無しさん2006/01/20(金) 00:51:17
Emacsのマルチスレッド化はいつのことになるやら・・・
0065デフォルトの名無しさん2006/01/20(金) 02:55:56
>>61
前編で終るのか・・・。
0066デフォルトの名無しさん2006/01/20(金) 03:01:37
最終号はなにか凝ったことするのかな
0067デフォルトの名無しさん2006/01/21(土) 12:49:44
メモリー自体にCPUを乗せて、簡単な処理はメモリーが直接計算する、という案は駄目でつか？
今の技術なら、Z80CPU1万個を一枚のチップに乗せて、並列に計算させるぐらいの事は、
できそうな気がするけどな・・・無茶か？
0068デフォルトの名無しさん2006/01/21(土) 12:50:44
>>67
消費電力が物凄い事になりそうだぞ？
0069デフォルトの名無しさん2006/01/21(土) 12:52:41
>>67
似たようなアーキテクチャがNTTのCELLでなかったかい？
0070デフォルトの名無しさん2006/01/21(土) 12:54:05
オブジェクト指向はクラスタ化のためにやるんだと思ってた・・・
0071デフォルトの名無しさん2006/01/21(土) 12:56:33
普通の会社はメモリと密接にってのはまず無理

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

Z801万個くらいの性能デイならFPGAでできそうだが
0072デフォルトの名無しさん2006/01/21(土) 13:00:46
描画メモリーならレイトレースするエンジンがそんな感じだと思った
0073デフォルトの名無しさん2006/01/21(土) 15:20:43
ようわからんが、これってそんな感じ？
GPGPU
http://pc8.2ch.net/test/read.cgi/tech/1128780920/
0074デフォルトの名無しさん2006/01/21(土) 15:46:47
>>73
保守乙
0075デフォルトの名無しさん2006/01/21(土) 16:43:50
よく知らんが、WRAMとかSGRAMとかVRAMとか、その系統じゃね？
もう名前を聞かなくなって久しいが。
まだ特定用途向けに使われてるのかな。
0076デフォルトの名無しさん2006/01/21(土) 17:26:33
箱○に載ってるね。メモリアクセスだけで、Zバッファや
アンチエリアシングの処理をするのに使われている。
0077デフォルトの名無しさん2006/01/22(日) 01:29:23
Cellはゲームに特化したプロセッサだから汎用には不向きだぞ。
0078デフォルトの名無しさん2006/01/22(日) 03:06:27
だねえ、CELLは倍精度演算とか弱いし、特定のメディア用プロセッサであって
汎用CPUにはなれない。
そのかわりDSPの塊みたいなものだから用途が合えばめちゃ速いと思う。
0079デフォルトの名無しさん2006/01/22(日) 10:13:15
mpeg2やDivXの高品質リアルタイムエンコ、とかは?
0080デフォルトの名無しさん2006/01/22(日) 10:15:50
デジタル回路で処理してるだけかと
0081デフォルトの名無しさん2006/01/22(日) 11:16:09
メモリというかレジスタだな。
00821=メガデモスレ6602006/01/22(日) 21:10:22
http://pc7.2ch.net/test/read.cgi/jisaku/1136822334/
マルチスレッドスレに貼り付けてあったんだけど、面白そうなので
ここにも貼っておく。アンチマルチコアって自分だけじゃないのを
初めて知った。PC自作板ってつまんないから全然みないんだよね。
0083デフォルトの名無しさん2006/01/22(日) 21:16:12
つーか、アンチうざい
新しいのが出てきてそれについていけないやつだと思うけど
0084デフォルトの名無しさん2006/01/22(日) 23:21:03
2コアぐらいなら、OSとアプリケーションでおおまかにひとつづつ使い切るような感じで、
別にシングルスレッドのアプリケーションでも意味あると思うんだよね。
だけど、４、８とコアが増えてくるとそうはいかない。負荷がかかってるのにも関わらず
アイドル状態のコアが出てきちゃいそう。
0085デフォルトの名無しさん2006/01/22(日) 23:31:53
>>84
> 2コアぐらいなら、OSとアプリケーションでおおまか
> にひとつづつ使い切るような感じで、

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

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

と言うのは、２コアでも十分ある。
0086デフォルトの名無しさん2006/01/23(月) 00:49:24
>>85
自作板を見てると、DualはWindowsの体感速度が上がるからっていう理由で
買ってる人が多いみたいなんだよね。IEやエクスプローラを含めたOS全般と
自分の使ってるアプリケーションの両方が同時にスムーズに動くと。
だけど、そういう人たちでもさすがに４個や８個もの多コアは買わないだろうな
という気がした。
0087デフォルトの名無しさん2006/01/23(月) 00:52:06
>>83
そういうやつが周りに一杯いるけどそういう奴は蹴落としていくしかないと思う。
なんとなく小泉総理が親友を作らず孤独な少年であったというのが分かる気がする
0088デフォルトの名無しさん2006/01/23(月) 01:15:57
淘汰されるなら淘汰されるで歓迎
0089デフォルトの名無しさん2006/01/23(月) 02:47:28
>>85
常に一個位アイドルなCPUが居るのって結構重要だったりする。
エンコやら異常事態やらで地獄の様に重い時でもUIの応答が軽いのはストレスを生まない。
0090デフォルトの名無しさん2006/01/23(月) 06:14:19
それはnice値変えるだけでもいいような
0091デフォルトの名無しさん2006/01/23(月) 07:30:41
それはniceなアイディアだ
0092デフォルトの名無しさん2006/01/23(月) 08:55:09
アンチってなんなの？
マルチスレッドプログラムがかけない人なの？
シングルコアの性能をもっとあげる方法を発明できる人なの？
アンチとして存在してる意味がﾜｶﾗﾈ
0093デフォルトの名無しさん2006/01/23(月) 09:40:16
>>92
今まで普通にプログラムを作ってきたプログラマー達だね。
彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
>>63の言うとおりにガベージコレクションの性能が上がったとしたらそれだけで彼らは失職の危機にさらされる。
まあ、主にゲームプログラマーだけどね。
実際ゲームはシングルスレッド信仰がすごい強い分野だと思う。

ただ、滑稽なのはゲームなんてクリエイティブな分野でそんなに技術屋さんがでしゃばっていること。
本当はマルチコアでどんな新しいゲームが作れるかを考えるべきなのにそれを邪魔するだけの典型的な既得権益者なので
外野としてはそんな害虫どもにはさっさと消えてもらうことを祈るだけだね
0094デフォルトの名無しさん2006/01/23(月) 12:54:33
＞彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
＞おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち

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

きっちっとした技術を積み上げてきたヤシなら、それほど恐怖でもない
むしろ他の連中と差をつけるチャンスだ罠
0095デフォルトの名無しさん2006/01/23(月) 13:25:29
>>93
ガベコレの性能とゲームプログラマの失職に何の関係がある？

あと、ゲームのどの変の処理にマルチスレッドを導入するべきだと思う？
0096デフォルトの名無しさん2006/01/23(月) 14:51:31
>>95
GCの性能が上がったら高級言語でもそこそこゲームが作れるようになるじゃないか。
ベンチマークではC++と関数型なんてほとんど変わらないしな。
そうなるとある程度ライブラリとかフレームワーク作ったり業務系と同じようになってくるんじゃないかな?
単純にシングルコアの性能だけでも相当向上してるのだからそうやってやり方が変わって脱落者が出るのでは？。

どんなゲームがいいかは例えばRTSのようなゲームで個々のユニットを複雑なアルゴリズムで動かすとかはどうだ?
0097デフォルトの名無しさん2006/01/23(月) 15:35:46
D言語の時代ｸﾙｰ?
0098デフォルトの名無しさん2006/01/23(月) 15:56:06
DってGC性能が低いんだったっけ？
それ以前に仕様がまだ固定化されてないのが気になるが

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

今後スレッドが言語に組み込まれてない環境は厳しくなるよね
0099デフォルトの名無しさん2006/01/23(月) 16:43:54
>>96
処理速度の向上によって今までC/C++でしかできない・C/C++が望ましかったような
ゲームが、Javaや関数型言語でも実装できるようになるだろう、という予測？

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

後者は理解できるけど、前者は疑問なような気がする。
生産性の向上によって確保した知的資源は、更なる難問の解決に使われるのが普通だから。
（そうじゃないと低賃金労働でしか生き残れない）
0100デフォルトの名無しさん2006/01/23(月) 19:08:23
豪華なマシンになってPGが楽になる・・・なんてことはなく、
実際は性能を限界まで出しきることを期待されてひどい目に遭うだけ。
0101デフォルトの名無しさん2006/01/23(月) 19:23:38
>>100
ゲーム業界だとSFC,PS,PS2の時に聞かされた、PS2はまぁ期待にそえんでもなかったが。
0102デフォルトの名無しさん2006/01/23(月) 21:29:20
ゲームってシングルスレッド信仰というより、わざわざマルチスレッドで
コンテキストスイッチするメリットがあまりないだけじゃないだろうか。
負荷もでかいし同期が必要なものは余計やりにくい。
0103デフォルトの名無しさん2006/01/23(月) 21:34:00
むしろ並列演算言語が欲しい所だな
つ〜か、マルチスレッドである必要は全く無いんだよ
並列演算が可能なら、シングルスレッドでもかまわない
その意味では、昔はＭＭＸに期待したわけだが・・・
0104デフォルトの名無しさん2006/01/23(月) 21:39:09
>>99
どっちかというと前者かな?Javaや関数型がそのまま使われるかは知らないけどPS3でオープンソースな人たちが勝手に実験始めるでしょ
低賃金労働から逃れるためにはライブラリ屋になるのが自然。ライブラリ屋が儲かるか知らんけど。

後者は手動での最適化するのが本当にできるのか疑問視していて、並列化言語を実用化させたほうが早いと思ってる。
0105デフォルトの名無しさん2006/01/23(月) 21:40:22
マルチスレッドによる並列性の引き合いにMMXによる並列性
を出すのはどうかと思う。
0106デフォルトの名無しさん2006/01/23(月) 21:40:59
>>103
バス幅とバスクロックの壁は厚かった
0107デフォルトの名無しさん2006/01/23(月) 21:46:54
>>105
下手にマルチスレッドを使うよりは、並列演算を行った方が処理が早くなると思わないか？
0108デフォルトの名無しさん2006/01/23(月) 21:49:21
１０個のコアがあるのなら、１０個別々に処理するよりも、
同時に同一処理を行わせるのもアリだと思うんだよな。
0109デフォルトの名無しさん2006/01/23(月) 21:50:41
>>104
するってえと高賃金乙な国内の業者さんたちは結局ライブラリだの物理モデルだの
並列処理向き言語＋プラットフォーム開発だの、GCがどうとかいうレベルではなく難しい
ことをやらざるを得なくなって、「余った知的リソース⇒難しい仕事」という流れになるような・・・

成功しないのでそういう流れにはならない、という可能性も高いけど。
数学はインド人の方が得意そうだし。
0110デフォルトの名無しさん2006/01/23(月) 21:51:37
>>107
いやだから用途が違うと思うんだけど。MMXつかって速くなるところに
マルチスレッド使っても速くなるようなケースは限られると思うが。
（逆もまた然り）
0111デフォルトの名無しさん2006/01/23(月) 21:56:48
>>110
コアがたくさんあったとしても、一つのスレッドの扱えるコアは一つ？
0112デフォルトの名無しさん2006/01/23(月) 22:00:41
>>111
話の流れがわからん
0113デフォルトの名無しさん2006/01/23(月) 22:01:05
>>103
NeoMagic の MiMagic6 なんかがその路線で、16x16ピクセルの画像を
対象とした演算なんかを1命令でできる演算ユニットを積んでます。

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

　小さいモノの中ではダイナミック・リコンフィギュアラブルLSIとかが
そういう思想のもののような気がするけど違うかもしれない。
0114デフォルトの名無しさん2006/01/23(月) 22:06:50
>>112
つまり、10個のコアがある場合に10個演算する場合は、10個スレッドを立ち上げて、
10個同時に演算して、演算が終われば元のスレッドに戻せば、10倍の速度で演算できるのでは？
って事。
0115デフォルトの名無しさん2006/01/23(月) 22:14:20
>>114
しかしバス幅とバスクロックの壁は、非情なまでにも分厚かった
0116デフォルトの名無しさん2006/01/23(月) 22:15:56
>>114
それふつうにマルチコアの利点

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

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

JavaのコンカレントAPIみたいなのが普及せんときついかもね
0117デフォルトの名無しさん2006/01/23(月) 22:19:09
>>114
俺が言いたいのは、SIMDは局所的な並列で、マルチスレッドはもっと大域的ってこと。

MMXは隣接ピクセル間の並列性、マルチスレッドはブロックごとに区切るような
（マルチレンダリング）用途でしょう。俺なら同時に使うけどね。どっちかが
肩代わりするもんじゃない。
0118デフォルトの名無しさん2006/01/23(月) 22:54:48
関連スレ追加
http://pc8.2ch.net/test/read.cgi/tech/1099819556/
0119デフォルトの名無しさん2006/01/24(火) 01:34:42
>>117
スレッドのというか処理の粒度の問題って解くべき問題との関係が深すぎるからこのスレのタイトルだと混乱するかもしれない。
0120デフォルトの名無しさん2006/01/24(火) 02:24:55
スレッドとマルチコアは何の関係もないだろ。
0121デフォルトの名無しさん2006/01/24(火) 03:39:30
マルチプロセッサ(SMT含)を想定してのマルチスレッドプログラミングと全く同じだもんな。
プロセッサ間の通信速度や、外部(メモリ)との通信速度が違う、というだけで。
0122デフォルトの名無しさん2006/01/24(火) 04:37:07
>>109
つまり技術的にはインドに負けることが前提なわけですな。
0123デフォルトの名無しさん2006/01/24(火) 11:46:28
マルチコアのマルチスレッドって、通常のマルチプロセッサに比べて
注意するところあんの？　ハイパースレッドプロセッサだったら
スピンロック問題とか言うのがあった気はするけど。
0124デフォルトの名無しさん2006/01/24(火) 12:57:29
>>86
自作板のあれは、多くの場合、負け惜しみです。
体感速度が云々と言ってる人達は、遅いCPUをdualにしています。

本当にCPU速度が必要な人達は、
マルチスレッドで動くアプリを使っていて、
ユーザの操作のためにCPUが丸々1個アイドルで待機しているのでレスポンスが良い
なんてことにはならないのです。
0125デフォルトの名無しさん2006/01/24(火) 12:59:39
>>102
ゲームはCPUを他のスレッドに譲るという概念がないから。
ビジーウェイトとか平気でやるからな、ゲームプログラマは。
0126デフォルトの名無しさん2006/01/24(火) 13:00:32
>>107
並列演算を行った上で、
さらに、
マルチスレッドですよ。
0127デフォルトの名無しさん2006/01/24(火) 13:58:16
できるやつは新しいのが出てきてもいい物を作る
できないやつは昔からの作り方にこだわり進歩しない

ゲーム製作スレのオブジェクト指向いらねという話と似てる
0128デフォルトの名無しさん2006/01/24(火) 14:03:03
>>125
そんなアホはさすがに居ない。
、、と思いたいが、居る所には居るのか。
0129デフォルトの名無しさん2006/01/24(火) 14:41:26
>>127
君みたいなのをみるとイライラする。

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

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

もうちょっと真剣に技術に対して考えてくれ。
0130デフォルトの名無しさん2006/01/24(火) 15:03:11
>>129
>はっきりいって現状、中身がないって
>いっているつもりなんだけど。

これって「一般人の使うデスクトップに関しては」って事かな。
範囲を限定しないと、議論にならないと思われ。
01311292006/01/24(火) 15:06:14
>>130
最初から使い道がはっきりしているHPCやサーバ用途を除いては、です。
適確なつっこみスンマソン。
0132デフォルトの名無しさん2006/01/24(火) 15:11:56
>>125
ジャンルにもよるが、ゲームってのは譲り合いの最たる分野だよ。
処理落ちと戦うアプリが他にどれほどあると思う。ただ他のプロセス
のことを考えるのはPCやらんとわかりにくいね。
0133デフォルトの名無しさん2006/01/24(火) 15:23:10
あと、ユーザの立場からデュアルコアまではメリットがあるといのも了解事項?

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

その上で、プログラマの立場から、メニー／マルチコアのメリットを最大限に
活かせる様な設計とは何かという事だよね?
01341272006/01/24(火) 15:36:32
>>129
PCがまた売れるようになってきた原因がいわゆるTVつきでキャプチャとか出来るパソコンなわけだが
これらはデュアルコアの恩恵が非常に大きい

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

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

とりあえず4コアまでならコンシューマレベルでもかなり恩恵は出るとおもうけど
8コア以降は俺はしらね
0135デフォルトの名無しさん2006/01/24(火) 16:14:17
>>134
>プログラムがより簡単になるとかあるんだよ

例えば?
ネットワーク回りを別スレッドにするとか、そういうの?
0136デフォルトの名無しさん2006/01/24(火) 16:41:52
>>135
そういうこと

サウンド回りにしてもね
シンプルになるよ
0137デフォルトの名無しさん2006/01/24(火) 16:45:51
>>136
その辺はシングルプロセッサでも別スレッドだべ？
0138デフォルトの名無しさん2006/01/24(火) 16:46:55
サウンドやネットワーク周りをメインスレッドで動かすのはちっと
考えられん。
01391382006/01/24(火) 16:49:06
昔のゲーム機でサウンドをVSyncで処理している事例はあるにはあったけどね
0140デフォルトの名無しさん2006/01/24(火) 17:41:23
>>137
だね

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

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


>>139
つーか割り込み使ってる時点で別スレッドと同じような動きだろう
0141デフォルトの名無しさん2006/01/24(火) 17:43:26
やっぱり、プログラム板的にはマルチコアだからって何ら特別なことは
なく、マルチスレッドでプログラムを書けばよい、でOK？
0142デフォルトの名無しさん2006/01/24(火) 17:53:46
>>140
＞の2スレッド構造にすれば非常にシンプル
分けると同期が逆に面倒な気がする。読み込む部分が
ネットワークからのストリーミングだったらおっしゃるように
二段構えになるけど、それはネットワークのレスポンスが
タイミング違いすぎるから。

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

とはいえ大違いでも、大差ないと言えば大差ないが。
0143デフォルトの名無しさん2006/01/24(火) 17:54:32
>>141
それじゃあ話がおわっちまうが確かにその通りじゃね
0144デフォルトの名無しさん2006/01/24(火) 18:05:43
>>142
だから同期のライブラリが充実している高級言語が有利なんだよ

そもそもスレッドだってループするように作ってなくていいわけで
0145デフォルトの名無しさん2006/01/24(火) 18:26:39
>>144
高級言語という話の流れはどこから？

＞そもそもスレッドだってループするように作ってなくていい
ループしないってことは割り込みみたいに毎度毎度スレッドを
生成するのか？　そんな馬鹿なことしてるとは思えないから
一度生まれたスレッドを殺さずに使い続けるのは何かしら中で
ループしてるってことだろ？
0146デフォルトの名無しさん2006/01/24(火) 18:30:12
>>145
スレッドプールとかあるし、ユーザーは意識させないよ

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

Cとかでシングルスレッドでガリガリにチューニングしたアプリより
マルチスレッド使って適当にのほほんと書くアプリのほうが早いとか
わりと普通だからな
0147デフォルトの名無しさん2006/01/24(火) 18:35:55
んな細かいことはどーでもいいから、
読み書き速くするとか、読み書き中にゲーム続行できるようにしといてくれ。
0148デフォルトの名無しさん2006/01/24(火) 18:43:20
そりゃプロセッサが複数あればそうだろう。依存関係のない部分
は簡単に並列化できるからね。

あと、スレッド内でループしない構造にするメリットってある？
記述は明らかにイベント駆動より簡単なのに。
0149デフォルトの名無しさん2006/01/24(火) 18:46:15
>>147
ごめん、難しいんだ（笑）　まあ、非同期読み込みは
サポートするようにはしてるよ。でもこの辺はマルチ
プロセッサでなくても恩恵受けるところだね。一方が
極端に遅いデバイスを扱う場合は特に。
0150デフォルトの名無しさん2006/01/24(火) 18:47:18
>>148
スレッド数をスレッドプールでコントロールする場合ループさせないほうがいい
0151デフォルトの名無しさん2006/01/24(火) 18:51:41
スレッドプールってサーバなんかのトランザクション処理以外にも使うんだ?
どんな用途で使ってるの?
0152デフォルトの名無しさん2006/01/24(火) 18:56:57
スレッドプールはイベント駆動との中間みたいなもんか。

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

同時に資源の消費しすぎを抑えられるってことね。
0153デフォルトの名無しさん2006/01/24(火) 19:00:38
イベントディスパッチの代わりにプールからスレッドを起動するのか。何か重そうな。
0154デフォルトの名無しさん2006/01/24(火) 19:11:53
例えば、Winsock2系で(非標準だけど)最速といわれているIOCPは
スレッドプールを利用した仕組みだよ。
0155デフォルトの名無しさん2006/01/24(火) 19:17:25
>>151
プールに既にあるから起動しなくて良い。ので高速。
現状のシングルスレッドでのイベントディスパッチャが、
スレッド数１のスレッドプールに相当します。

例えば10,000程度の物をアレコレ処理するとき、
10,000個スレッドを作らずに、論理CPU数x2程度の
スレッドに効率よく処理を分散できるとか。
0156デフォルトの名無しさん2006/01/24(火) 19:23:45
ふぅん、面白そうだね。ちょっと調べて実装してみたいな。
ｻﾝｸｽ。
0157デフォルトの名無しさん2006/01/24(火) 19:45:30
とはいえ話にあったBGMにはスレッドプールは向かないんじゃね？
詰まっていて鳴らせませんじゃすまないし。
0158デフォルトの名無しさん2006/01/24(火) 19:54:09
元々リニアにスケールする処理→スレッドプール
特殊な処理をメインスレッドから外出ししたい→普通にスレッド作る

...なんじゃないの。
0159デフォルトの名無しさん2006/01/24(火) 20:09:39
スレッドプールはシングルスレッドでもいいんだけどマルチプロセッサ
に不可分散させたい時に便利だってことかー？
0160デフォルトの名無しさん2006/01/24(火) 20:14:23
簡単に別スレッド使える構文が欲しい。C++では何度も導入の
意見が出て却下され続けてるそうだが、

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

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

CreateThreadしたりオブジェクト作ったりﾏﾝﾄﾞｸｾ
0161デフォルトの名無しさん2006/01/24(火) 20:18:40
現状のsmpのままだとメモリのボトルネックがもっとひどい事にならない？
コア数が増えるとクロスバースイッチとか導入するＰＣも出るのかな？
0162デフォルトの名無しさん2006/01/24(火) 20:21:31
>>159
シングルコア･シングルプロセッサの場合でも、
とあるスレッドがI/Oで待たされてる間に他のスレッドで
他の処理ができる（かもしれない）、という普通のマルチ
スレッドの利点も提供される。

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

普通は>>155の「論理CPU数x2」とかよりもっと多くのスレッドを使う。
0163デフォルトの名無しさん2006/01/24(火) 20:22:31
>>160
スレッド生成クラスとラムダで事足りるからじゃないの？
make_thread終了の同期とる方法をOSから隠蔽する方が面倒くさそうだし。

0164デフォルトの名無しさん2006/01/24(火) 20:33:48
＞スレッド生成クラスとラムダ
それなあに？
0165デフォルトの名無しさん2006/01/24(火) 20:36:15
どっちかっていうと閉包欲しいよ閉包。
ちょっとスレッドとかにも便利だよ。
0166デフォルトの名無しさん2006/01/24(火) 20:50:57
make_thread foo();

ってやったら別スレッドで関数起動してくれるのが欲しい。
0167デフォルトの名無しさん2006/01/24(火) 20:52:28
http://216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt
0168デフォルトの名無しさん2006/01/24(火) 20:55:31
BGMの補充に関してはいわゆるブロッキングキューでいい
充填する側はキューサイズがいっぱいだとキューがあくまで待つ
そして取り出す側はキューが取り出せる状態になるまで待つ

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

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

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

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

おいしいところは真似しないとな
0169デフォルトの名無しさん2006/01/24(火) 20:59:42
で、まあ、今話題になっているような内容は
マルチコアとは直接関係無く
普通にマルチスレッド、或いはマルチプロセッサに関する話題でして。

↓以下ループ
0170デフォルトの名無しさん2006/01/24(火) 21:33:12
一々、茶々入れんと気が済まんのか。御主は。
0171デフォルトの名無しさん2006/01/24(火) 21:45:26
普通にマルチスレッドの話でいいんでないの？
スレの名前も並列化だけだし。
マルチコアが普及することによって・・・というだけでしょ。
0172デフォルトの名無しさん2006/01/24(火) 21:52:45
あっちよりこっちが賑わってるのはスレタイの勝利ですか
0173デフォルトの名無しさん2006/01/24(火) 21:58:02
>>172
あっちってOpenMPスレ？
0174デフォルトの名無しさん2006/01/24(火) 22:14:53
マルチスレッドって名前付いてるスレ
0175デフォルトの名無しさん2006/01/24(火) 22:25:37
まあ、賑わってるって言ったって、住人の顔ぶれは
ほとんど変わらないと思うけどな。
0176デフォルトの名無しさん2006/01/24(火) 22:31:25
あっちはC＋Win32ベースでしかも基本的なところから先に進んでない
単純な排他制御だけではお話になりませぬ

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

マルチコアを生かすのに簡単なのがマルチスレッドってだけで
マルチスレッド以外で現実的な並列プログラミングの方法があれば・・・というところだろう
0177デフォルトの名無しさん2006/01/24(火) 23:14:45
このスレッドの場合は極端な事を言い出しても、
まだまだ使い古されて無い技術だから叩きづらいんだよ
だから好き勝手に色々な事が言える
0178デフォルトの名無しさん2006/01/24(火) 23:16:55
>>164
多分、どっかの誰かが作ったスクリプト言語だったと思う
0179デフォルトの名無しさん2006/01/24(火) 23:19:21
まあ結局、並列化を効率よくやろうとすると、自前でスクリプト言語を作るか、
現時点で存在するスクリプト言語に頼るかの、二者択一になってくるんだよな
0180デフォルトの名無しさん2006/01/24(火) 23:20:46
あるいは、同期機能を駆使してC++で作るとか・・・
0181デフォルトの名無しさん2006/01/24(火) 23:23:25
でも、自前でスクリプト言語を作ったりすると、
わざわざマルチスレッドにする必然性が、
高速化以外には全く無くなったりする罠。ｗ
0182デフォルトの名無しさん2006/01/24(火) 23:28:21
Javaもまあ、スクリプト言語の一種といえば一種か
0183デフォルトの名無しさん2006/01/24(火) 23:36:41
>>160
一カ所のメモリーに対する多重アクセスを防ぐのが難しくなるからかと
0184デフォルトの名無しさん2006/01/24(火) 23:36:58
>>178
Boost か何かのライブラリの機能でしょ。
0185デフォルトの名無しさん2006/01/24(火) 23:38:03
>>179
スクリプト言語は、GC という並列化と相性が悪い物を抱え込む事になる。
0186デフォルトの名無しさん2006/01/24(火) 23:38:23
何でマルチコアの話で「スクリプト言語」がでてくるんだ？
0187デフォルトの名無しさん2006/01/24(火) 23:40:51
気にしちゃダメ
0188デフォルトの名無しさん2006/01/24(火) 23:44:35
>>186
スレッドの管理が面倒だからかと
面倒な処理は、誰かが勝手にやってくれる方が楽だからな
0189デフォルトの名無しさん2006/01/25(水) 00:15:33
>>160
Javaならすぐかけるのにね
0190デフォルトの名無しさん2006/01/25(水) 00:31:21
そろそろC++も言語にスレッドを組み込んでしまって、何らかの
シンタックスシュガーが欲しいところ。

0191デフォルトの名無しさん2006/01/25(水) 01:46:14
たしかにJavaだと

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

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

とインナークラスでかけるな
スタック変数とのやり取りでは面倒なことになるが
0192デフォルトの名無しさん2006/01/25(水) 02:00:13
スレッドの話はスレ違いだろ。スレッドだけにスレ違いw
0193デフォルトの名無しさん2006/01/25(水) 06:15:51
>>191
へ〜、Javaだと仮想関数をそんな風に作れるんだ・・・
0194デフォルトの名無しさん2006/01/25(水) 09:46:54
マルチコア時代もJavaで決まり！！！
ドントネット死滅ケテーイ（禿藁嘲笑）
0195デフォルトの名無しさん2006/01/25(水) 11:01:49
>>191
記述は楽なんだけど、外側のローカル変数を受け継いで欲しい。
中の処理にパラメータはどうやって渡すのがお行儀いいの？

>>193
仮想関数？
0196デフォルトの名無しさん2006/01/25(水) 12:24:58
>>195
受け継ぐだろ。finalにするだけで。
final必要にしたのは、リークが見つかりにくくなるからとSUN社員のブログか何かに書いてあった。

ぜんぜん並列と関係ないな…。
0197デフォルトの名無しさん2006/01/25(水) 12:54:27
final宣言されたローカル変う右派コンストラクタでコピーされて渡されてる
そもそもfinalは変更が不可能なのでお手軽に変数を渡すわけにはいかないよ
普通にクラス作ればいいだけだけどね
0198デフォルトの名無しさん2006/01/25(水) 12:58:30
>>191
>>160の例はそういうことじゃなくて、i=0からi=99までの初期状態を持つ
100個のスレッドの生成と実行と待ち合わせが簡易な構文でできればなー、
という話なのでは？

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

>>196
ホント？Javaっていつのまにかクロージャが使えるように成ってたんだ。
世の中には信じられないようなことが起きているなあ。
0199デフォルトの名無しさん2006/01/25(水) 13:42:21
Javaのそれをクロージャと呼ぶと、変な人が湧いてくるよ。
0200デフォルトの名無しさん2006/01/25(水) 15:58:45
>>133
お前はスレッドの優先度を設定しないアホプログラマか。
0201デフォルトの名無しさん2006/01/25(水) 16:55:05
Win32限定なら、QueueUserWorkItem()一発かな。
自動的にスレッドプールを作って関数を実行してくれる。
0202デフォルトの名無しさん2006/01/25(水) 19:01:32
>>198
匿名内部クラスでぐぐれ
0203デフォルトの名無しさん2006/01/25(水) 23:28:05
マルチスレッドなんて時代遅れ。
これからはマルチコア。これだね。
0204デフォルトの名無しさん2006/01/26(木) 00:12:15
>>199
コンパイラ・スクリプトエンジン相談室によく出没するあいつらか？
0205デフォルトの名無しさん2006/01/26(木) 00:13:24
Lispこそがすべての起源。
Lispを知らずしてプログラミングを語るべからず。
0206デフォルトの名無しさん2006/01/26(木) 01:06:43
>>200
いや、プライオリティの問題もあるが、それだけじゃない。
0207デフォルトの名無しさん2006/01/26(木) 03:25:18
マルチコアだと重いタスクを裏に回せるのがメリットかね。
シングルコアで重いタスクを裏に回しても、裏のタスクの
進行が遅くなるか表のタスクが足を引っ張られることが
多い。

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

まあ重いったって基本的にはI/Oとメモリを大量に使う
処理ぐらいしかないんだけどな。
0208デフォルトの名無しさん2006/01/26(木) 03:36:50
×マルチコアなら
〇マルチプロセッサ(HTT含)なら
0209デフォルトの名無しさん2006/01/26(木) 08:43:17
で、結局、バス幅とバスクロックの壁はどうにかなりますか？
0210デフォルトの名無しさん2006/01/26(木) 09:03:54
>>206
いくらプライオリティが低くても、
一旦CPUを割り当てられたら、割り込みがかかるまで、一定時間はCPUを占有する、
という問題はあるけれど、ユーザのインタラクティブな操作は割り込みをかけるので問題なし。
0211デフォルトの名無しさん2006/01/26(木) 09:07:08
スループットを犠牲にしてでもレスポンスを良くしたければ、
CPUの割り当て時間を短くしてしまうのも手ですよ。

たとえばWindowsの場合は、HALによっては変更をサポートしてる。
ちなみにデフォルト値がWindows2000の場合、
マルチプロセッサだとシングルプロセッサの1.5倍の時間に設定される。
WindowsXPの場合、シングルプロセッサでも、マルチプロセッサと同じ時間に設定される。
WindowsXPがモッサリな原因の1つが、1.5倍に設定されたことだよ。
0212デフォルトの名無しさん2006/01/26(木) 13:16:58
>>211
アフィニティを下げたら各コアのキャッシュが汚れるから、デュアルコア時のメリット薄いんじゃないかな。
シェアードキャッシュなら良いんだろうけど、普通 L1 はシェアしないでしょ。
0213デフォルトの名無しさん2006/01/26(木) 14:46:16
インテルのデュアルって肩並べて爆熱してるだけのツインプロセッサじゃないのか？
0214デフォルトの名無しさん2006/01/26(木) 15:46:58
IntelCoreしらんのか
0215デフォルトの名無しさん2006/01/26(木) 17:54:54
しらんがな
0216デフォルトの名無しさん2006/01/26(木) 18:13:20
>211から>212へ行く話の流れがわからない。
>212は何に関するaffinityのことを言っているの？
CPUの割り当て時間との関係は？
0217デフォルトの名無しさん2006/01/26(木) 23:50:22
Windows では Thread Affinity って言葉は使わないのかな。

と思ったが、>>211 は CPU Quantum の事を言っていたのか...
ｽﾏｿ。勘違いしてた。
0218デフォルトの名無しさん2006/01/27(金) 22:22:57
Windowsでアフィニティと言えば、
プロセスやスレッドを特定のCPUだけにしか割り当てないようにアプリがOSにお願いすることだよね。
0219デフォルトの名無しさん2006/01/28(土) 05:00:41
それは UNIX で Processor Bind と呼んでる機能かな。
0220デフォルトの名無しさん2006/01/29(日) 18:42:42
名前を前例に倣わんのはMSの悪いところ。とはいえスレッド関連は
NTのほうがUNIXより早いんかね？
0221デフォルトの名無しさん2006/01/29(日) 22:15:40
お前ら並列プログラミングを語る前にLispについて学べ
0222デフォルトの名無しさん2006/01/29(日) 22:23:30
>>221
なんで？いまの並列化言語は論理型のほうがすすんでないか?
0223デフォルトの名無しさん2006/01/29(日) 22:43:33
Lispを知らずしてプログラミング言語を語るべからず

ム板にいながらこんな常識すら知らないとは・・・
0224デフォルトの名無しさん2006/01/29(日) 22:46:33
>>223
各所で Lisp を貶めるのは止めてくれ
0225デフォルトの名無しさん2006/01/29(日) 22:57:15
>>223
おまえみたいなのがいるからLisp使いがバカにされる
0226デフォルトの名無しさん2006/01/29(日) 23:23:26
>>223はこういう念仏を唱えるだけのアホウがいる、という話かと思ったら
アホウ当人だったのか。

こいつ、どうせLispスレじゃ何にもレスしてないよ。
以前もRuby使えないくせにあちこちのスレにRuby万歳突撃やってた基地外がいたが、
同一人物かもしれん。
0227デフォルトの名無しさん2006/02/02(木) 19:13:07
そんなことしてるのがリアルに居るとは信じられんが、ｶﾅｼｽ
0228デフォルトの名無しさん2006/02/02(木) 23:35:39
正直なところ、Lisp知らん奴が語ってるのって、幼稚なんだよね。
本質でない、些細な部分に無駄に労力を費やしてるって感じ。
議論も設計もコーディングもスマートにやれるのがLisp、
これを学ばない手はないね。
0229デフォルトの名無しさん2006/02/02(木) 23:41:51
>>228
>>224
0230デフォルトの名無しさん2006/02/03(金) 03:19:53
Lispって何でもありすぎる。あれならマシン語で
プログラミングしてるのと代わらんような。
適度に制限されたフレームを提供するのが言語の大事な役割
というキガス。
0231デフォルトの名無しさん2006/02/03(金) 04:00:13
>>230
>適度に制限されたフレーム

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

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

あ、それから…、

ここは並列化のスレなんで、言語の善し悪しの話は完璧にスレ違いです。
お引き取りください。
0232デフォルトの名無しさん2006/02/03(金) 04:49:07
俺はlisp知らんけど、
もし本当にlispが並列処理向きだったとして


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

まあ、スレッドプールとか使ってうまくやっているのかも知れないが。
0233デフォルトの名無しさん2006/02/03(金) 04:57:20
>>232
>もし本当にlispが並列処理向きだったとして

Common Lisp の事なら、そもそも ANSI 規格では並列化は考慮されていない。
フリーの実装に限って言えば、マルチスレッドのコンパイラは少ない。
並列／分散処理の研究に Lisp が使われてたりはあったと思う。
0234デフォルトの名無しさん2006/02/03(金) 05:03:49
並列化言語の側も盛り上がってないし、今の並列処理の枠組みは pthread とかに
依存しているんで、今後も C とか Java でどうするかって話が主流なんじゃないかな。
関数型言語にもちっと頑張って欲しい所。
0235デフォルトの名無しさん2006/02/03(金) 09:51:27
どの言語がいいだの悪いだのはモノ作れるようになってから語れ
('A`)
0236デフォルトの名無しさん2006/02/03(金) 09:57:14
自分で言語を作るのは、手間がかかるんだよ。ｗ

続きは「コンパイラ・スクリプトエンジン」のスレッドでやらないか？
0237デフォルトの名無しさん2006/02/03(金) 21:26:44
別に実装の話まで入り込む必要は無いんだけど、並列化を支援する言語のフィーチャーに
どんな物があるのかは興味がある。
0238デフォルトの名無しさん2006/02/04(土) 00:05:15
>>237
そういう話題は、「マルチスレッドプログラミング相談室」で。
0239デフォルトの名無しさん2006/02/04(土) 05:24:48
あっちは実践、こっちは理論や研究レベルってことで、こっちでもいいんじゃない？

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

これなんか実際に、後から何スレッドで動かすか指定するみたい。
http://www.haskell.org/haskellwiki/GHC/Concurrency#Multiprocessor_GHC
0240デフォルトの名無しさん2006/02/04(土) 05:28:19
と思ったら普通にプログラムの方でも指定するみたいだな。
並列に出来るからって勝手に全部並列化したらオーバーヘッドの方が大きくなっちまうか。
0241デフォルトの名無しさん2006/02/04(土) 13:27:34
ウザいLisp厨のせいで折角のふいんきが台無しだな
0242デフォルトの名無しさん2006/02/11(土) 19:50:33
スレ頓挫か？
0243デフォルトの名無しさん2006/02/11(土) 20:06:40
なんかネタがねぇ。だれかネタ提供してくれ。

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

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

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

0244デフォルトの名無しさん2006/02/11(土) 20:12:43
たまにはageとく
0245デフォルトの名無しさん2006/02/11(土) 21:05:00
　　 　 -‐-　　
__ 〃　　 　 　 ヽ
ヽ＼　ノﾉﾉ）ﾍ)､!〉
　(0_)!　(┃┃〈ﾘ　 はわわ〜マルチが245ゲットですぅ〜〜
　 Vﾚﾘ､" lﾌ／ 　　　
　　　　(　￣￣￣《目
　　　　|　 ＝＝＝《目
　　　　|＿＿|　　　 ‖
　　　∠|_|_|_|_ゝ 　　‖ 　　　　　　∧＿_∧
　　　　 |__|_|　　　　 ‖ 　　　　　 ┝・∀・┥ﾄﾗﾗｰも2ｹﾞｯﾄ。
　　 　　|　| |　　　　 ‖ 　　　　　 （　　　　 ）　
　　　　 |__|__|　　　　 ‖ 　　　　 　|〓 | 〓|　 　
　　 　　|　＼＼　　 皿皿 　　 　 （＿_） ＿_）.　
0246デフォルトの名無しさん2006/02/12(日) 10:34:53
トララーがﾜｶﾝﾈ
0247デフォルトの名無しさん2006/02/12(日) 23:55:41
OSがプリエンプティブであればマルチコアかどうかは
さほど問題ではないと思うのだがどうか。
0248デフォルトの名無しさん2006/02/13(月) 00:18:59
>>247
それは必要条件であって十分条件じゃない。

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

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

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

ネタ振りとしてはこれくらいで良いか?
0249デフォルトの名無しさん2006/02/13(月) 10:57:19
シングルスレッド最強
0250デフォルトの名無しさん2006/02/13(月) 20:52:13
シングルスレッドで作って、適当にexecすればいいじゃん。
何を悩んでいるのかわからない。
0251デフォルトの名無しさん2006/02/13(月) 20:58:46
もう面倒くさいよ。
0252デフォルトの名無しさん2006/02/14(火) 15:41:09
おわりか
0253デフォルトの名無しさん2006/02/23(木) 13:09:55
http://japan.cnet.com/news/ent/story/0,2000047623,20097056,00.htm
Cell向けにOctopilerツールが発表されるらしい。
どういう形で支援するか謎だ。そのあたりの情報が外部にも出してもらえると、
今後のマルチコア向けアプリケーションの開発に少しは参考になりそう。

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

仕事でCellとか触れる人はいいね。自分は関係ない職種だから触れません。
0254デフォルトの名無しさん2006/02/23(木) 13:48:56
マルチコアでマルチスレッド処理が平気でできれば、これから食いぶちがありますあ？
0255デフォルトの名無しさん2006/02/23(木) 14:21:45
なにやっても食っていける。重要なのは仕事取る（就職含む）対人スキル。
プログラミングはそれからだ。

とはいえ、金出す側の鼻が利く場合に備えて腕は磨いとけ
0256デフォルトの名無しさん2006/02/23(木) 14:56:45
ドカタ乙
0257デフォルトの名無しさん2006/03/04(土) 22:34:53
特に意味はないが、保守っとく。
ちょっと古いけど、Timed Calculus of Communicating Systems つーのを調査中。
0258デフォルトの名無しさん2006/03/06(月) 22:39:39
保守
0259デフォルトの名無しさん2006/03/06(月) 23:37:03
>>257
googleで検索したけど、TCCSって何ですか？TimedがつかないCCSなら
たくさん説明があるんですが、似たものもしくは同じものなんですかね。
Calculusいうぐらいだからπ計算とかの親戚の計算モデルっぽいのは
わかるんですが。

ここを読んでいる人でプロセス代数とかやってる人っています？
0260デフォルトの名無しさん2006/03/07(火) 08:21:54
そりゃCCSなら説明がたくさんあるだろうな・・・
0261デフォルトの名無しさん2006/03/12(日) 02:13:05
>>253
OpenMPのpragmaを流用するみたい
0262http://www.vector.co.jp/soft/win95/util/se072729.html2006/03/18(土) 22:08:36
TextSS　のWindowsXP(Professional)64bit対応化おながいします

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

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
0263デフォルトの名無しさん2006/03/18(土) 22:23:01
>>261
そうなんですか。できることは限定されているような気がしますが、
普通にCellに最適化されたプログラムを書くより大分楽にはなり
そうですね。
0264デフォルトの名無しさん2006/03/22(水) 23:49:32
http://it.nikkei.co.jp/digital/news/index.aspx?i=20060320ew000ea
やっぱり開発が難しいそうですよ。新しいノウハウが必要らしい。予想通りだ。
マルチコアはいいけどソフトウェアの負担は大きい。
0265デフォルトの名無しさん2006/03/23(木) 00:22:34
86とか汎用の石のマルチコアが難しいというのと
Cellが難しいというのとはたぶん難しい場所が違う

CellはPS2の延長と考えればすっきりするしその程度
0266デフォルトの名無しさん2006/03/23(木) 00:25:24
>>265
それが新しいノウハウだろｗ
PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど
0267デフォルトの名無しさん2006/03/23(木) 01:12:40
８６系ってＣＰＵの思想があれだから、マルチコア化を困難にさせてるんだよな・・・
0268デフォルトの名無しさん2006/03/23(木) 01:20:43
↑
こういう知ったかがわくのはどうにかならないのか？
0269デフォルトの名無しさん2006/03/23(木) 01:22:39
>>267
思想がアレなのはiApx432だろ。
0270デフォルトの名無しさん2006/03/23(木) 01:24:49
レジスタが専業化されてるってやつだろ？
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。
0271デフォルトの名無しさん2006/03/23(木) 10:15:02
uOp fusion のコストが高すぎるといってるのか？
俺には的外れに思えるが。
0272デフォルトの名無しさん2006/03/24(金) 05:57:20
↑
こういう知ったかがわくのはどうにかならないのか？
0273デフォルトの名無しさん2006/03/24(金) 11:57:44
267が論旨を明確にすればいいだけの話。
0274デフォルトの名無しさん2006/03/24(金) 17:50:04
デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない？

という意味だと漏れは思う。
0275デフォルトの名無しさん2006/03/24(金) 22:46:44
つまりメタセコイアは生きた化石だということか。
0276デフォルトの名無しさん2006/05/14(日) 23:36:57
鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。
0277デフォルトの名無しさん2006/05/14(日) 23:54:33
そうでもない
0278デフォルトの名無しさん2006/09/10(日) 14:07:50
ho
0279デフォルトの名無しさん2006/09/10(日) 20:48:00
>>276
2-4 並列くらいでいいんだから余裕じゃ。
大変って言ってる奴が居たら、それは「ﾏﾝﾄﾞｸｾ」って意味か、「もっと金寄越せ」って
意味かのどちらか。
0280デフォルトの名無しさん2006/09/15(金) 00:56:12
Objective-C + Cocoa なソースで OpenMP って使えるの??
0281デフォルトの名無しさん2006/09/30(土) 23:13:10
Cilkってどう？
0282デフォルトの名無しさん2006/09/30(土) 23:34:11
ｲｿﾃﾙが発表した４コアってプログラミング的にはどうなん？
性能を活かせるコンパイラってあるの？
0283デフォルトの名無しさん2006/10/01(日) 00:38:46
80コアか・・・
機械的に最適化できる方法あるのかな？
ttp://techon.nikkeibp.co.jp/article/NEWS/20060927/121563/?ST=edaonline&ref=rss
0284デフォルトの名無しさん2006/10/03(火) 09:41:30
まぁ数年間は OpenMP 使ってチマチマ並列化するのが手っ取り早いだろーね。
でも 80 コアの時代には言語レベルで並列化/分散処理をサポートした
新しい言語が主流になってると思う。
そうじゃないとプログラミングがしんどくなるね。
0285デフォルトの名無しさん2006/10/08(日) 15:44:34
そこまでしてx86である必要がないような。
0286デフォルトの名無しさん2006/10/08(日) 19:56:41
互換性が重要だからね。
x86系は（PC/AT互換機が業界標準になったおかげで）業界標準になったから過去の互換性切れないんだよ。
0287デフォルトの名無しさん2006/10/08(日) 22:54:13
ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。
0288デフォルトの名無しさん2006/10/08(日) 23:29:37
そういうわけに行かない業界と素人と過去の遺産の都合を考えろってこと。
カーネルやドライバ部分なんかはCPU変わったらほぼ完全に書き直しだろうし。
CPUごとに使用するコンパイラ＆ミドルウェアが変わることで開発やサポートのコストは跳ね上がる。
(商用ソフトがほとんどの場合ライセンス上の理由でソースコード公開できないことくらいは分かってると思うけど)
02892882006/10/08(日) 23:32:09
×公開
○開示
だな。まぁ公開も商用である限りまず望めないだろうね。
0290デフォルトの名無しさん2006/10/09(月) 00:12:55
倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw
0291デフォルトの名無しさん2006/10/09(月) 00:29:27
>>290
ユーザーが増えないから売れそうもないので対応しない
バイナリが流通しないから新しいアーキテクチャのユーザが増えない
以下繰り返し

この悪循環が始まるだけなんでそういう事を言われても困る。
0292デフォルトの名無しさん2006/10/10(火) 01:06:52
「対応しないと売れない」の間違いじゃね？
つか、対応せずに済むというのはユーザー側の思考で、本来なら企業のビジネスチャンスのためにも積極的にハードウェアアーキテクチャを変更するべきなんだよ。
儲かるのはマイクロソフトだけ。っていう図式が何を意味しているかしっかりと考えてみろ。
0293デフォルトの名無しさん2006/10/12(木) 15:26:01
OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・
0294デフォルトの名無しさん2006/10/12(木) 21:35:46
>>293
それは使い方間違ってるだけだろ。
俺が反論してやるからURLｷﾎﾞｿ
0295デフォルトの名無しさん2006/11/18(土) 02:08:28
そいつの考え方がおかしいんじゃねーのかどこか知らんが
0296デフォルトの名無しさん2006/11/26(日) 14:08:24
>>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。
0297デフォルトの名無しさん2006/11/26(日) 14:41:15
挙動不審
0298デフォルトの名無しさん2006/11/26(日) 22:38:34
マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
あるいはSETI@homeみたいに部分に分けて処理させるのはどうなの？
あとマルチコアって確率論とか統計学とかいるの？（学問ではなにが関係するの？）

というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
0299デフォルトの名無しさん2006/11/26(日) 22:45:47
volatile最強宣言ｋｔｋｒ
0300デフォルトの名無しさん2006/11/26(日) 22:53:22
> マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
釣りですか？

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

> というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの？
分散処理の研究が進んでいるのと、それ様のプラットフォーム(MPIとか)が
整備されているから。何も考えずに無為にやっているけど大丈夫なわけでない。
0301デフォルトの名無しさん2006/11/26(日) 22:54:32
訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
↓
> プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。
0302デフォルトの名無しさん2006/11/26(日) 23:10:00
ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか
学者さんは嫌いそうだが必要になりそう
0303デフォルトの名無しさん2006/12/20(水) 00:38:23
おお、こんなスレが。
並列プログラム用のライブラリを作成しています。（C++/Unix用）
http://pards.sourceforge.jp/
よろしければ御意見下さい。

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

実用的な例として、bzip2の並列化も行っています。
詳しくは上記URLをご参照下さい。宣伝失礼致しました。
0304デフォルトの名無しさん2006/12/20(水) 00:53:18
sureddo版を作る気はないのかえ？
03053032006/12/20(水) 01:14:41
スレッド版？ >>304
スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
温床になっているという主張なのですよ > このライブラリ
グローバル変数触るだけでMT-unsafeになるので、スレッドを使った
既存のプログラムの並列化は難しいのですが、プロセスはメモリ空間を
分けるので、そんなことは無いと。
もちろんその分オーバヘッドはあるのですが、最近のOSなら我慢できる範囲では
無いかと思います。
# とか言いながらスレッド版作ったりして
0306デフォルトの名無しさん2006/12/20(水) 02:09:16
なるほろ。

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

ぬー、でもあんまり差が出ない気がしてきた。
0307デフォルトの名無しさん2006/12/20(水) 18:23:59
>>303
ネットワーク越しあり？
0308デフォルトの名無しさん2006/12/20(水) 23:21:00
あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。

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

> スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの
> 温床になっているという主張なのですよ > このライブラリ
さすがに含蓄のあるお言葉ですな。
03093032006/12/20(水) 23:28:00
>>307
いや、SMPだけを対象にしてます。
MPC++/SCoreとか、ネットワークで接続されたコンピュータを
SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;
0310デフォルトの名無しさん2006/12/21(木) 19:53:02
JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか？
0311デフォルトの名無しさん2006/12/21(木) 20:09:14
>>310
JAVAはマルチスレッドにしても速度は上がらんよ。
0312デフォルトの名無しさん2006/12/21(木) 22:00:09
>>310
速度を気にするならJAVAは問題外
0313デフォルトの名無しさん2006/12/21(木) 23:29:59
てっきり　>>194　みたいなことが書いてあるから…
.netは対応？済みらしいがマルチコア環境じゃないから試せない。
0314デフォルトの名無しさん2006/12/22(金) 00:01:18
マルチスレッドは速度を向上させるのが目的ではないと思うがなあ
0315デフォルトの名無しさん2006/12/22(金) 00:09:25
サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン？は既にやってるとこもあるみたいだけど。
0316デフォルトの名無しさん2006/12/22(金) 00:10:31
>>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。
マルチノード、マルチインスタンスにはした方が良いけど、
かなりの大規模ノードじゃなければ十分。
0317デフォルトの名無しさん2006/12/22(金) 04:56:33
>>285
x86である必要があってx86なのではなく、
数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。
0318デフォルトの名無しさん2006/12/22(金) 05:05:09
>>314
何が目的なのか、ハッキリ言ってよ。

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

>>315
XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、
パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。
0319デフォルトの名無しさん2006/12/22(金) 12:35:22
>>310
他の言語と同じように恩恵はあるよ。
恩恵がないのは遥か昔の green thread の頃かな。
0320デフォルトの名無しさん2007/02/14(水) 06:21:12
Intel，80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
ttp://www.4gamer.net/news.php?url=/news/history/2007.02/20070213183701detail.html
0321デフォルトの名無しさん2007/03/06(火) 16:26:58
トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。

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

死にたい気持ちになった。
0322デフォルトの名無しさん2007/03/06(火) 16:32:41
へたくそなコピペじゃねーぞ！
あまりにショックなので、こんな過疎スレに書き込んでいる。
今夜は一人で飲みたい。
0323デフォルトの名無しさん2007/03/06(火) 16:38:00
↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる！
0324デフォルトの名無しさん2007/03/06(火) 16:47:30
オッス、オラうんこまん！
地球防衛隊員ってのをやってるんだ。よろしくな！
0325デフォルトの名無しさん2007/03/06(火) 16:57:41
>>324
恥ずかしい自演乙
0326デフォルトの名無しさん2007/03/07(水) 01:42:39
>>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。
0327デフォルトの名無しさん2007/03/13(火) 14:25:23
それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん（結構かわいい）がレジで支払いしてるトコだった。そのレジ台に置いてあったの
がイチジク浣腸の１０個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入
れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。
噂を流したら俺だってわかるし山下さんもかわいそうだから。
0328デフォルトの名無しさん2007/03/20(火) 01:14:45
動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの？
0329デフォルトの名無しさん2007/03/20(火) 22:13:18
linuxでやれ。
0330デフォルトの名無しさん2007/03/21(水) 15:28:42
やってみる価値は非常にありそうだな。
0331デフォルトの名無しさん2007/03/21(水) 16:43:18
つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ？
0332デフォルトの名無しさん2007/03/21(水) 20:02:48
>>331
たぶんそうなんじゃない。
動画は前の画像の圧縮して解凍したものを使うから
ある程度の時間の動画をひとつのスレッドにしたほうが
効果ある上に作るのがとても楽だね。
0333デフォルトの名無しさん2007/03/21(水) 21:17:47
キャッシュ効率が下がるんじゃない？
0334デフォルトの名無しさん2007/03/21(水) 21:47:44
下がるだろうね。

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

CPUのマルチコア化を一般ユーザが使うようになるころは
メモリとかHDDの性能はどうなるのかしら。
0335デフォルトの名無しさん2007/03/21(水) 22:43:12
エンコードに必要なワーキングセットをＮとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね
・・・そこまでやるか？
0336デフォルトの名無しさん2007/03/22(木) 03:49:20
ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい？
0337デフォルトの名無しさん2007/03/22(木) 11:25:18
ダンゴ様の許可があればいい
0338デフォルトの名無しさん2007/03/22(木) 14:28:33
>>336
Xeonは除外?
0339デフォルトの名無しさん2007/03/23(金) 02:25:42
>>336
どんな話がどう濁されているのか具体的に。
そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。
>>338
XeonもCore2ファミリじゃね?
0340デフォルトの名無しさん2007/03/23(金) 02:55:13
初期のXeonもCore2だっけ?
0341デフォルトの名無しさん2007/03/23(金) 03:15:39
ダンゴ的にはどうよ？
0342デフォルトの名無しさん2007/03/29(木) 00:56:14
結局は高クロックのシングルコアが速い？
0343デフォルトの名無しさん2007/03/29(木) 04:29:47
それができないからthe free lunch is overなのでは？
0344デフォルトの名無しさん2007/03/29(木) 20:44:06
Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか
Pen3やNetBurst系とは逆？
0345デフォルトの名無しさん2007/03/30(金) 00:00:33
この質問はダンゴじゃないとマトモに返答できないと見た
0346・∀・）っ-○◎●2007/03/30(金) 01:52:36
.
0347デフォルトの名無しさん2007/03/30(金) 03:33:19
32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら
皆知ってるけどね。
0348デフォルトの名無しさん2007/03/30(金) 22:22:50
人間活動 → スカラ
自然現象 → ベクトル
中途半端 → 今のCMP全般
0349デフォルトの名無しさん2007/04/03(火) 09:13:21
　 　 　　　＿＿＿_
　 　　　／⌒　　⌒＼ ﾎｼﾞﾎｼﾞ
　　　／（ ●） 　（●）＼
　 ／::::::⌒（__人__）⌒::::: ＼ 　＜で？
　 |　　　 ｍj |ー'´　　　　　 |
　 ＼　 〈＿_ﾉ　　　　　 　／
　　　　ノ　　ﾉ
0350デフォルトの名無しさん2007/04/03(火) 19:26:14
おちんぽ
0351デフォルトの名無しさん2007/04/13(金) 21:20:44
結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。
0352デフォルトの名無しさん2007/04/15(日) 03:08:29
既出かもしれんけど
http://cag.csail.mit.edu/ps3/index.shtml
0353デフォルトの名無しさん2007/05/06(日) 00:35:15
JCSPの話はここでいいのか？
0354デフォルトの名無しさん2007/05/06(日) 02:41:23
良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。
0355デフォルトの名無しさん2007/06/03(日) 02:01:31
保守
0356デフォルトの名無しさん2007/06/03(日) 15:31:56
逐次処理を並列処理に分割する手法で代表的なものって何？
0357デフォルトの名無しさん2007/06/03(日) 15:33:02
OpenMP とか関数型言語で書き直すとか？
0358デフォルトの名無しさん2007/06/03(日) 15:41:12
>>356
OpenMP、pthread、MPI 辺りですかね。

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

ちなみに性能的には MPI > pthread > OpenMP、
お手軽さでは OpenMP > pthread > MPI の順でしょうか。
0359デフォルトの名無しさん2007/06/03(日) 16:43:38
>>358
>ちなみに性能的には MPI > pthread > OpenMP、
ええっ!? SMP環境でMPIってpthreadより性能いいの?
0360デフォルトの名無しさん2007/06/03(日) 17:47:44
OpenMP、pthread、MPI ってどこにあるの？
0361デフォルトの名無しさん2007/06/03(日) 18:15:19
一番星を右に進んだ所、虹の彼方に
0362デフォルトの名無しさん2007/06/04(月) 19:05:59
ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう？
データですか？タスクですか？
0363デフォルトの名無しさん2007/06/04(月) 19:20:07
適材適所。
0364デフォルトの名無しさん2007/06/04(月) 19:22:08
栄枯盛衰
0365デフォルトの名無しさん2007/06/06(水) 00:22:34
>>359
MPIは複数の計算ノード（例えばPCとか）を高速な通信回線で接続した
HPCクラスタ用ですね。

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

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

# でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な
# 学生が使える教育機関でしか人気が無いような気がする…。
0366デフォルトの名無しさん2007/06/06(水) 13:37:00
>>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね

>>358
># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。
>
>ちなみに性能的には MPI > pthread > OpenMP、
>お手軽さでは OpenMP > pthread > MPI の順でしょうか。
「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?
0367デフォルトの名無しさん2007/06/07(木) 11:12:37
358じゃないけど、
>>366
>「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか?
SMPだけどNUMAなアーキテクチャとかどうなんだろ。Opteronマシンみたいなの。
pthreadでNUMA考慮して書けばいいけど、間にMPIはさんどくと、誰かが最適化してくれるかもしれない。
もう最適化されてるのかな？

MPIはHPCクラスタ用っていうけど、日立やNECも自社のスパコン用にMPI提供してて、
クラスタならmpich、スパコンならベンダオリジナルのMPIってことで計算コードを使いまわせるんで、
MPIの利用率は高いと思う。10年ぐらい前スパコン使ってたころは高かった。
メモリ共有ノード内と、分散メモリになるノード間の通信の使い分けとか考えたら、
トップスピード出すにはMPIか、その手のライブラリ使うことになると思う。
0368デフォルトの名無しさん2007/06/07(木) 23:03:08
>>367
>SMPだけどNUMAなアーキテクチャ

これは定義矛盾
Opteron は NUMA
NUMA への最適化は最近のカーネルなら大抵入ってるよ
0369デフォルトの名無しさん2007/06/07(木) 23:13:02
>>367
もまいはこれよめ
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40555.pdf
0370デフォルトの名無しさん2007/06/15(金) 00:05:56
これってどう？
http://www.rbbtoday.com/news/20051219/27869.html
0371デフォルトの名無しさん2007/06/15(金) 00:10:53
機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな
0372デフォルトの名無しさん2007/06/15(金) 00:13:22
>>370
ttp://www.nec.co.jp/press/ja/0512/1902.html
これのことか？
0373デフォルトの名無しさん2007/06/15(金) 06:55:05
何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に
なるだろうけど、そんな簡単な用途は極めてまれなわけで。
宣伝の一人歩きだろう。
0374デフォルトの名無しさん2007/06/15(金) 07:46:05
＞極めてまれ
そうでもない。
処理はシンプルでも大量に捌かないといけない場合はままある。
#尤も、そういうケースは並列化の自動化も難しいが。
0375デフォルトの名無しさん2007/06/16(土) 01:44:51
んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな？
0376デフォルトの名無しさん2007/06/16(土) 02:10:48
画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは
並列化してナンボな物が多い。

デスクトップアプリは 4 コアもあれば十分だと思うけど。
0377デフォルトの名無しさん2007/06/16(土) 11:53:25
大規模マルチコアプロセッサの発売に向け準備を進めるインテル
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氏は指摘する。

プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング
技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要
はない。これらのオペレーションは大抵、チップ自体によって処理される
ため表面化しないのである。
0378デフォルトの名無しさん2007/06/16(土) 16:38:55
>>377
素晴らしい！！
テクノロジーの進化ってとんでもねぇなｗ
0379デフォルトの名無しさん2007/06/16(土) 22:47:24
Windows出たばかりの頃の宣伝の様だが
0380デフォルトの名無しさん2007/06/16(土) 22:56:25
まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、

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

って漏れの耳には聞こえてるが気のせい？
0381デフォルトの名無しさん2007/06/16(土) 23:05:49
>>380
そういうのは NetBurst や Itanic で懲りていると思いたい…
0382デフォルトの名無しさん2007/06/16(土) 23:42:46
>380
俺にはIntel以外のコンパイラは淘汰されてしまえ
と聞こえるが
0383デフォルトの名無しさん2007/06/16(土) 23:54:34
ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん

INTELはいっつもAMDいじめて悦に浸ってる変態だし
しねってかんじだ
0384デフォルトの名無しさん2007/06/17(日) 00:13:12
そらそうよ、Intelはパラノイアが社訓だもん
0385デフォルトの名無しさん2007/06/17(日) 01:16:16
いよいよ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
0386デフォルトの名無しさん2007/06/17(日) 01:23:55
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ライブラリを利用しており、実行時に利用可能な
コア数分だけスレッドを生成する。
0387デフォルトの名無しさん2007/06/17(日) 15:02:51
AMDは甘ちゃん
IBMとIntelはプロフェッショナル
0388デフォルトの名無しさん2007/06/18(月) 01:10:40
次世代スパコンはスカラーとベクトルの複合型に，日立/NEC/富士通の「3社連合」で開発へ
http://techon.nikkeibp.co.jp/article/NEWS/20070613/134173/

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

ハードウエアだけでなく，ソフトウエアも同時に開発する。「制御フロントエンド」
のジョブ管理を通して，ユーザーはこれら二つのシステムの違いを意識せずに
最適な演算環境を選べるようにするという。
0389デフォルトの名無しさん2007/06/18(月) 06:50:59
>>384
コンピュータ様って事ですね？市民。
0390デフォルトの名無しさん2007/06/18(月) 23:42:06
もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・

http://pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm
0391デフォルトの名無しさん2007/06/18(月) 23:46:07
いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。
0392デフォルトの名無しさん2007/06/18(月) 23:51:36
シーケンス図廃止からやってみようかな？
で、その代わりに何を使えばいい？？
0393デフォルトの名無しさん2007/06/19(火) 18:18:04
並列システム用のモデリングviewをUMLに策定してくれんかな。
0394・∀・）っ-○◎●2007/06/20(水) 00:23:28
あのさー

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

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

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

それにしても結城先生お茶目だな。
0395デフォルトの名無しさん2007/06/20(水) 00:28:27
さてと、、、
0396デフォルトの名無しさん2007/06/20(水) 16:51:08
Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が
ご迷惑をおかけしております。
0397・∀・）っ-○◎●2007/06/20(水) 22:12:33
ゲハ厨自演乙
0398デフォルトの名無しさん2007/06/21(木) 00:00:47
>>396
バカかお前ｗｗｗ
何も知らないんだなｗｗｗｗｗ
ム板で厨認定された糞団子が帰る場所は














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



0399デフォルトの名無しさん2007/06/21(木) 15:37:25
該当するスレが見付からず、
かといってどこにかけばいいかわからないのでここで質問をします
(どこか適当なスレがあれば誘導していただければ幸いです)

今、FreeBSD 6.2のPCからPVMを起動して
Fedora 7(192.168.1.3)とVine Linux 4.2(192.168.1.4)のPCをクラスタに登録したいのですが
登録の成功をつげているのにもかかわらず
マシンには登録されていないような状況になっています

/tmp/pvml.????(????：グループID)を確認したら以下のようなメッセージが
でてきます
------------------------------
[t80040000] 06/21 15:11:35 host1 (192.168.1.2:60822) FREEBSD 3.4.5
[t80040000] 06/21 15:11:35 ready Thu Jun 21 15:11:35 2007
[t80040000] 06/21 15:14:50 netoutput() timed out sending to ryle after 14, 190.000000
[t80040000] 06/21 15:14:50  hd_dump() ref 1 t 0x80000 n "ryle" a "" ar "LINUX" dsig 0x408841
[t80040000] 06/21 15:14:50            lo "" so "" dx "" ep "" bx "" wd "" sp 1000
[t80040000] 06/21 15:14:50            sa 192.168.0.3:32790 mtu 4080 f 0x0 e 0 txq 1
[t80040000] 06/21 15:14:50            tx 2 rx 1 rtt 1.000000 id ""
[t80040000] 06/21 15:16:40 netinput() bogus pkt from 192.168.1.3:32790
------------------------------
PVMの方で勝手にタイムアウトをしているのですが
このような場合はどのようにすれば回避できるのでしょうか？
0400デフォルトの名無しさん2007/06/21(木) 22:38:31
簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある？
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。
0401デフォルトの名無しさん2007/06/23(土) 18:29:29
UNIXのパイプ
0402デフォルトの名無しさん2007/06/24(日) 23:14:58
フィックスターズが出している
http://www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1462-1
は、役に立つのだろうか？
立ち読みした限りでは内容がちと薄い気がするのだが。
0403デフォルトの名無しさん2007/06/26(火) 16:17:27
>>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。
とりあえずコードを何回も書いて覚えている途中。

変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。
0404デフォルトの名無しさん2007/06/26(火) 20:43:30
そんなレベルの奴が並列化なんかに手を出すのが間違い
0405デフォルトの名無しさん2007/06/26(火) 21:33:51
並列かなんてたいして技術いる事じゃないだろ
0406デフォルトの名無しさん2007/06/26(火) 23:43:46
そういうやつが平気でぼけぼけかますのが並列化
0407デフォルトの名無しさん2007/06/26(火) 23:46:28
科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。
javaERの俺にはﾀﾞｸﾞﾘｰ先生の本のほうが面白かったけど。
0408デフォルトの名無しさん2007/06/26(火) 23:48:17
>>406
一緒にするなよ
0409デフォルトの名無しさん2007/06/27(水) 08:23:06
Amazonでの評価は微妙だね。
http://www.amazon.co.jp/dp/4798014621
0410デフォルトの名無しさん2007/06/27(水) 18:12:05
俺は釣られないぞ
0411デフォルトの名無しさん2007/06/29(金) 01:44:41
なんでOpenMPばっか期待されてんの？
どこにもOpenMPなんて書いてないように見えるが（本のタイトルとかに）
0412デフォルトの名無しさん2007/06/29(金) 01:46:42
デザインパターンの本。
↓
Javaについてはほとんどのってないので期待はずれ。
↓
デザインパターンの本、評価は微妙。

だれもJavaって言ってないじゃん…
0413デフォルトの名無しさん2007/06/29(金) 13:17:14
たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。
俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。

Win32マルチスレッドプログラミング
http://www.amazon.co.jp/dp/4756114040/
0414デフォルトの名無しさん2007/07/06(金) 09:47:57
http://www.ebjapan.com/content/l_news/2007/07/l_news070702_0101.html
これってハードレベルで並列を実現したってこと？
0415デフォルトの名無しさん2007/07/06(金) 12:21:00
>>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。
0416デフォルトの名無しさん2007/07/07(土) 21:55:50
業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね？
0417デフォルトの名無しさん2007/07/07(土) 22:04:37
>>415
FPGAのparallel random access machine/model
じゃねーのそれって？

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

まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が
書きやすいと思われる。価格も現実的だし。
0418デフォルトの名無しさん2007/07/07(土) 22:18:17
http://seisei.s8.xrea.com/thread/
これはどうなんだろうね？
0419デフォルトの名無しさん2007/07/07(土) 22:39:58
>>418
うさんくさすぎねーかw

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

なんか穴があるはずだ。実用上の
0420デフォルトの名無しさん2007/07/07(土) 23:05:23
>>418
すげぇ、胡散臭すぎて読む気にもならないよ。
0421デフォルトの名無しさん2007/07/07(土) 23:29:44
読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。

で？
0422デフォルトの名無しさん2007/07/09(月) 01:01:13
XORをまるちすれっど？

で？
0423デフォルトの名無しさん2007/07/10(火) 10:41:52
オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案？

で？　
　
　
0424デフォルトの名無しさん2007/07/10(火) 11:41:21
順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる！
俺天才！！！

って事？ｗ
URL削るともっと胡散臭いｗ
0425デフォルトの名無しさん2007/07/10(火) 15:18:46
えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、

という感じ？

じゃなくてこれは単なる dish の簡単な使用例か。
ttp://www2.chem.nagoya-u.ac.jp/matto/90/70Proj/dish/index.phtml
0426デフォルトの名無しさん2007/07/11(水) 22:20:15
>>424
やばい、ドキュメントDLで金とるよ的なページもある。
0427デフォルトの名無しさん2007/07/11(水) 23:45:26
419です。
スマン、どうやらスレ汚しをしてしまったようだ。
削除依頼してくるわ。
0428デフォルトの名無しさん2007/07/12(木) 00:01:42
ごめん、↑は418の間違いね
0429デフォルトの名無しさん2007/07/12(木) 02:56:59
そりゃ潔癖すぎる
気楽にやろうぜ
0430デフォルトの名無しさん2007/07/17(火) 07:17:14
クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。
タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。


無理か？
0431デフォルトの名無しさん2007/07/17(火) 09:33:39
200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。
0432デフォルトの名無しさん2007/07/17(火) 11:49:26
メガドラか
0433デフォルトの名無しさん2007/07/17(火) 12:32:41
200メガギガヘンリー
0434デフォルトの名無しさん2007/07/17(火) 12:38:57
200万ギザエッチ
0435デフォルトの名無しさん2007/07/17(火) 12:57:02
200マゾガチハーレム
0436デフォルトの名無しさん2007/07/17(火) 21:41:58
ダンゴさんのレスが望まれるところだ
0437デフォルトの名無しさん2007/07/18(水) 01:21:03
悪趣味だな。
0438・∀・）っ-○◎●2007/07/18(水) 02:51:49
だーんごー
だーんごー

たーっぷりー

だーんごー
0439デフォルトの名無しさん2007/07/18(水) 11:04:21
>>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。
0440デフォルトの名無しさん2007/07/18(水) 21:12:27
>438
それ、たらこだろ？
0441デフォルトの名無しさん2007/07/18(水) 23:45:04
キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ
0442デフォルトの名無しさん2007/07/18(水) 23:50:16
イチローの出番だわな
0443デフォルトの名無しさん2007/07/19(木) 10:24:49
>>430
ヘテロなマルチコアならcellがあるじゃまいか
0444デフォルトの名無しさん2007/07/19(木) 11:45:36
そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ
れば効率よくマルチプロセス・スレッドができると思ったのよ。

>200MGH
200MHと間違えたよorz
0445デフォルトの名無しさん2007/07/19(木) 16:09:31
＞クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして

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

ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな
低速簡単タスクはPICとか使ってやってるシステムもあるよね。
0446デフォルトの名無しさん2007/07/19(木) 16:19:17
どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、
低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。
その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを
考えたほうが建設的だと思う。
0447デフォルトの名無しさん2007/07/19(木) 21:07:21
分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。

人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに
0448デフォルトの名無しさん2007/07/19(木) 22:52:24
>分散すれば仕事が早くなるってアホな幻想

お前がアホなんだろｗ
0449デフォルトの名無しさん2007/07/19(木) 23:32:58
無理なものは無理
0450デフォルトの名無しさん2007/07/20(金) 00:00:15
つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。
0451デフォルトの名無しさん2007/07/20(金) 00:42:36
工場の単純労働者は1000人必要かもしれない
だからといって社長（＋役員）は20人もいらない
0452デフォルトの名無しさん2007/07/20(金) 00:50:41
でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw
0453デフォルトの名無しさん2007/07/20(金) 00:58:53
>>452
それなんていう暖房機具？
0454デフォルトの名無しさん2007/07/20(金) 01:32:05
1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。
0455デフォルトの名無しさん2007/07/20(金) 02:00:49
今なら１U3台で済むよ

QuadXeon 6個＋ﾏﾏﾝ3枚でｵｹ
0456デフォルトの名無しさん2007/07/20(金) 06:53:20
Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか?
おめでたいな。
0457デフォルトの名無しさん2007/07/20(金) 09:27:02
頭が4つもついてる役員は怖いです。
0458デフォルトの名無しさん2007/07/20(金) 11:07:36
バスが飽和しそうです。
0459デフォルトの名無しさん2007/07/20(金) 23:18:00
>>454-456
お前らブレードサーバも知らんのか？

6U で Xeon 20個 コア 80個ぐらいは積めるだろ。
0460デフォルトの名無しさん2007/07/24(火) 21:52:02
http://japan.cnet.com/news/ent/story/0,2000056022,20353310,00.htm
0461デフォルトの名無しさん2007/07/25(水) 00:49:04
GPL？
0462デフォルトの名無しさん2007/07/25(水) 00:55:38
記事読んだ感じだと、例外付き GPL なんじゃないの
0463デフォルトの名無しさん2007/07/26(木) 00:26:11
LGPLだなたしか。

でも実際これら使っても効果出る範囲狭いみたいだぞ。
0464デフォルトの名無しさん2007/08/04(土) 20:15:15
タスク境界を自動で検出するTOOLないかね？
0465デフォルトの名無しさん2007/08/16(木) 15:32:15
foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。
0466デフォルトの名無しさん2007/08/21(火) 09:25:35
http://www.itmedia.co.jp/news/articles/0708/21/news021.html
0467デフォルトの名無しさん2007/08/21(火) 16:40:31
>>465
どういう計算だよｗ
0468デフォルトの名無しさん2007/08/21(火) 22:27:55
http://pc.watch.impress.co.jp/docs/2007/0821/tilera.htm
0469デフォルトの名無しさん2007/08/22(水) 13:13:48
http://www.atmarkit.co.jp/news/200708/21/tile.html
0470デフォルトの名無しさん2007/08/23(木) 22:07:23
http://pc.watch.impress.co.jp/docs/2007/0821/tilera.htm
0471デフォルトの名無しさん2007/08/31(金) 20:12:44
Wikiﾍﾟﾃﾞｨｱより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず

マジか
0472デフォルトの名無しさん2007/08/31(金) 20:16:45
>>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは
ないことは理解してる？
0473デフォルトの名無しさん2007/08/31(金) 20:26:13
一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける
ものの違いだと認識している。


多分
0474デフォルトの名無しさん2007/08/31(金) 20:40:22
XP HOMEもそうだったでしょ。
物理CPUに対応してるのは１個まで。
物理CPU１個ならコアが４個あっても大丈夫（のはず）

物理CPU２個はXP PROFESSIONALから。４個以上は知らない。
0475デフォルトの名無しさん2007/08/31(金) 22:48:30
それは違うぞ。
0476デフォルトの名無しさん2007/08/31(金) 23:02:14
じゃあどうなの
0477デフォルトの名無しさん2007/08/31(金) 23:03:08
いや、自分でもよくわからないんだけどさ
0478デフォルトの名無しさん2007/09/01(土) 00:01:00
>>473
ちがうよ。
マルチプロセッサってのは文字通り
マザボに CPU を複数のっけることだよ。
ハードディスクを 2 個繋げたり
メモリを 4 枚さすのと同じ。
0479デフォルトの名無しさん2007/09/01(土) 00:20:57
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 ソケット

コア数は４個だろうが８個だろうが全て認識するようです
0480デフォルトの名無しさん2007/09/01(土) 08:45:16
コアが32個あるタスクメジャー見たなｗｗｗｗｗｗｗｗ
0481デフォルトの名無しさん2008/01/15(火) 17:42:48
並列化・並列計算のスレってこの板には多分ここくらいしかないので、
ここで質問します。

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

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

並列計算で繰り返し処理を行う場合は
データの送受信の処理はどのようにコーディングすればいいのでしょうか。
(作りかけのプログラムをどっかにうpしたほうがいいんですかね・・・？)
0482デフォルトの名無しさん2008/01/15(火) 17:56:30
>>481
MPIのスレがあるぞ
0483デフォルトの名無しさん2008/01/16(水) 19:20:30
>>482
そうなんですがMPI以外の話になっちゃうので
抵抗がありまして・・・
0484デフォルトの名無しさん2008/01/16(水) 20:30:46
地球時間とか木星時間の一年周期で同期したらいいんじゃね
0485デフォルトの名無しさん2008/03/29(土) 13:31:27
cygwin+gccだとどのような方法がありますか？
0486デフォルトの名無しさん2008/04/06(日) 22:12:28
ない
0487デフォルトの名無しさん2008/04/07(月) 12:52:16
lam-mpiならcygwinにインスコできた。
mpichもたぶんできる。
0488デフォルトの名無しさん2008/04/08(火) 08:42:45
IntelのCt言語っててにはいるのかな？
0489デフォルトの名無しさん2008/04/21(月) 23:13:24
「小飼弾のアルファギークに逢ってきた」っていう本に
Dave ThomasがErlangの本を書いているって書いてあったんだけど
詳細が分かる人いますか？

07年7月に出版予定とか書いてあったけど、どうもAmazonの洋書でそれらしいものがない。
0490デフォルトの名無しさん2008/04/21(月) 23:14:06
すみません。
誤爆しました。
0491デフォルトの名無しさん2008/04/27(日) 21:21:30
128bit レジスタ を 8 コアで SSE 拡張として繋げて、
1024bit のベクトルプロセッサとして使える。

、、、とかだったら面白くなりそうなんだけどな
0492デフォルトの名無しさん2008/04/28(月) 13:11:09
>>491
どれかのプロセスがそれをやっている間他のプロセスが割りを食いそうだからやだ。
0493デフォルトの名無しさん2008/04/28(月) 18:17:35
>>491
逆に並列性が下がりそう
0494デフォルトの名無しさん2008/04/28(月) 21:44:59
素朴な疑問だけど、これからはメニーコアの時代、とかいうが、
コア間で「人月の神話」と同じ問題は発生しないのかえ
0495デフォルトの名無しさん2008/04/29(火) 09:07:34
する。
0496デフォルトの名無しさん2008/04/29(火) 11:53:18
つーか、大昔からのマルチプロセッシングの課題が
いかにリニアにスケールさせるか、です。
0497デフォルトの名無しさん2008/04/29(火) 14:01:25
それじゃ漠然としすぎて無意味だよ
0498デフォルトの名無しさん2008/04/29(火) 14:08:39
大昔からリニアにスケールさせるにはどうしたらいいかって話で
結局は個別対応になるから、一般論として本当に軽い話しかできない

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

ＥｆｆｉｃｉｅｎｔC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。
0499デフォルトの名無しさん2008/04/29(火) 14:28:00
>>497
知りたいことの的を絞ってくれればある程度話ができるよ。
0500デフォルトの名無しさん2008/05/10(土) 13:46:08
mac osx ppc64 で tbb を使って遊んでみようと思ってます（当然シングルコアなので雰囲気だけ）

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

0501デフォルトの名無しさん2008/05/10(土) 14:33:45
おおむね一年研究してみたが、マルチコア化でいちばん厄介なのは

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

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

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

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

CPUの設計原理を変えずに、脳の真似をするのは難しい。
0503デフォルトの名無しさん2008/05/10(土) 18:27:12
>>501
> 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。

業務用ゲーム業界に職人技的に伝えられてきたというあの「タスクシステム」？
0504デフォルトの名無しさん2008/05/10(土) 18:51:40
タスクシステムなんてこのＷＥＢ全盛時代にはもはや化石だなｗ
0505デフォルトの名無しさん2008/05/10(土) 19:31:26
並列化のキーワードは網羅って聞いたことがあるような。
例えばソートだと、順列(全パターン)を作ってそれが並んでいるか調べるだけでいい。

現在の手法は今までのアルゴリズムを並列化しようとしているからロックとかで問題になっているんでしょ？
アルゴリズムを根本から変えれば良いと思うけど。
0506デフォルトの名無しさん2008/05/10(土) 20:18:15
>>503
カプコンのMTフレームワークは使うかどうかはともかく、見ておく価値はあるよ。
http://watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm
十分とは思えないが、役に立たない理屈と違い実戦的な並列化手法の一つだから。
0507デフォルトの名無しさん2008/05/10(土) 20:19:49
>>505
量子コンピュータ時代になれば、役に立つかもなw
0508デフォルトの名無しさん2008/05/10(土) 21:15:20
>>507
ある程度コア数が大きくなったら役立ちそうだと思うけど
別に1パターン1コアに分けなくてもいいし。
0509デフォルトの名無しさん2008/05/10(土) 21:59:00
>>508
> ある程度コア数が大きくなったら役立ちそうだと思うけど

算数からやり直した方がいいと思う。
0510デフォルトの名無しさん2008/05/10(土) 23:18:15
>>508
たとえば1000の組み合わせの数を数えてみたらどうかな？
n qubitに対して、並列度が 2^n である量子コンピュータなら
2^1000程度の並列度を持たせれば、その組み合わせ数にも打ち勝てる可能性はあるが、
10個や20個のコアでなんとかなるかな？
0511デフォルトの名無しさん2008/05/10(土) 23:58:22
あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。
アルゴリズムが分かりやすいし。
0512デフォルトの名無しさん2008/05/12(月) 07:51:09
>>511
極めて単純なものだけに有効でしかないよ
総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。
宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。
そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。
量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、
自分たちが感知できない別の宇宙にコンピュータを配置する、
今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。
これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。
ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。
それにしても一番気になるのは計算機よりも並行宇宙そのものだ。
0513デフォルトの名無しさん2008/05/12(月) 21:09:31
量子コンピュータを神秘視しすぎだろwww
0514デフォルトの名無しさん2008/05/13(火) 09:02:31
>>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ？
どうころんでも、どう解釈してもキモ過ぎだよ
0515デフォルトの名無しさん2008/05/13(火) 09:15:37
量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。

キモいと言えばキモい性質ではある。
0516デフォルトの名無しさん2008/05/14(水) 03:50:53
並行宇宙ﾜﾛﾀ
0517デフォルトの名無しさん2008/05/16(金) 06:37:49
並行宇宙ヤバイ
0518デフォルトの名無しさん2008/05/16(金) 19:49:58
>>512マジキモイ
0519デフォルトの名無しさん2008/05/16(金) 19:51:44
2XXX年のオリコン一位

「並列宇宙」
0520デフォルトの名無しさん2008/05/16(金) 22:01:54
>>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか
量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。
0521デフォルトの名無しさん2008/05/17(土) 01:31:05
Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。
0522デフォルトの名無しさん2008/05/17(土) 03:24:15
宗教の話は他でやってくれないか。
0523デフォルトの名無しさん2008/05/17(土) 04:33:17
ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ
0524デフォルトの名無しさん2008/05/17(土) 05:23:47
>>520
量子コンピュータが量子力学の正しさを証明しても
並行宇宙解釈が主流になる事は無いと思われ
0525デフォルトの名無しさん2008/05/17(土) 05:33:35
ここム板やで。
0526デフォルトの名無しさん2008/05/18(日) 14:45:50
>>1
boinc環境を用意してねらーを煽る。
0527デフォルトの名無しさん2008/05/18(日) 19:38:01
懐かしの宇宙ヤバイを思い出した。
0528デフォルトの名無しさん2008/05/29(木) 23:59:57
ちょっと、細かい質問なんだが、
tbbの本３８ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。

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

この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか（TBBのもいい参考書だとおもいますけど。）。
0529デフォルトの名無しさん2008/05/30(金) 00:11:11
>>528
その本持ってないから意味不明で困る。

処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。
0530デフォルトの名無しさん2008/05/30(金) 00:16:56
>この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁
0531デフォルトの名無しさん2008/05/30(金) 09:09:33
>>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。

>>530
ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎
0532デフォルトの名無しさん2008/05/30(金) 09:31:16
>>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
0533デフォルトの名無しさん2008/05/30(金) 12:28:09
調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってｗ
0534デフォルトの名無しさん2008/05/30(金) 13:41:29
>>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw
例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。
0535デフォルトの名無しさん2008/05/30(金) 14:24:20
>>534
「複数のマルチスレッドライブラリが組み合わさった状態」
になったら「ショボイ開発」って思わなきゃダメだよ
0536デフォルトの名無しさん2008/05/30(金) 15:42:06
10000行で完成する程度のコードしか組んだことないんだなw
0537匿名2008/05/30(金) 15:45:44
並列・分散処理に関しては以下のホームページが参考になります。
主要な言語に対応したツールなどの紹介もあります。

www.cspjapan.org


0538デフォルトの名無しさん2008/05/30(金) 16:46:39
>>537
宣伝でつか？
マルチポストでやるのは、あまりイメージ良くないですよ。
0539デフォルトの名無しさん2008/05/30(金) 16:51:46
>>537
ちらっと見ただけだけど、通信部分が浮いている感じがするな、もっと洗練できると思う。
0540デフォルトの名無しさん2008/05/30(金) 17:00:24
グリッドコンピューティング？には合ってる部分もあるのかもだけど
昨今のマルチコア活用方向とは全く合わんのじゃ…
大体想定環境・状況が古すぎるような…
0541デフォルトの名無しさん2008/05/30(金) 17:06:31
プロセス代数は基本だと思うし、オブジェクト間通信という考えの元でも問題はないと思う。
マルチコア活用を阻害している最大の要因はパフォーマンスではなくて
直感的に記述することや効率よく記述すること、デバッグを容易にすることが重要だという点に気付いているかが気になった。
0542デフォルトの名無しさん2008/05/30(金) 17:11:11
もうひとつあるな、現行残っているシングルスレッドモデルで記述された大量のコードを徐々に移行していくための仕組みがいる。
0543デフォルトの名無しさん2008/05/30(金) 17:42:51
>>534
想定しなくていいように作るもんだろ
それに囚人のジレンマは場違いもいいとこ
0544デフォルトの名無しさん2008/05/30(金) 17:58:10
>>532
> コードがスマートになる粒度にハードウェアを調節しないと駄目だ。

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

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

> 囚人のジレンマ
> 個々の最適な選択が全体として最適な選択とはならない状況の例としてよく挙げられる問題。
0545デフォルトの名無しさん2008/05/30(金) 18:01:14
>>543
すべてのライブラリが自家製とかありえないだろ、ふつう
0546デフォルトの名無しさん2008/05/30(金) 18:12:32
>想定しなくていいように作るもんだろ
想定しなくていいように作る＝毎回開発でスクラップアンドビルド
だが、良いのか？
0547デフォルトの名無しさん2008/05/30(金) 21:10:39
>想定しなくていいように作る＝毎回開発でスクラップアンドビルド

うわっバカだ
0548デフォルトの名無しさん2008/05/30(金) 21:58:47
マルチスレッド並列化で解決すべき深刻な問題の一つだからな、保守性の無さと再利用性の低さは。
0549デフォルトの名無しさん2008/05/30(金) 22:18:08
>>537
今更CSP紹介されてもな…何十年前の話題だよ。
CSPを普通に実装するとプロセス間をデータが流れることになり、
キャッシュを越えるコア間のデータ転送が増えて、途方もなく
効率悪いと思うんだが。
その辺まで言及してくれればこのスレ的な話題になる。
0550デフォルトの名無しさん2008/05/31(土) 08:31:32
>>548
＞ 保守性の無さと再利用性の低さは。

STM はその辺強いのかね
0551デフォルトの名無しさん2008/05/31(土) 13:48:09
>>550
変な用語を使うのはヤメレ、シングルスレッドモデルといいたいのだろうが・・・
ちょっとでも触ればマルチスレッドを使った並列化の現状が論外な状態だと判るはず。
可能ならとっくに流行っている。
0552デフォルトの名無しさん2008/05/31(土) 13:50:49
>>549
現在のプロセッサの最大の弱点はプロセッサ相対で低速なメモリーであって
キャッシュ間の転送は、小さくはないが致命的でもない。
0553デフォルトの名無しさん2008/05/31(土) 14:30:34
>>551
アフォか。Software Transctional Memoryだろが
0554デフォルトの名無しさん2008/05/31(土) 14:56:15
>>552
一般論としてはそうだが例えばfork/joinはスティールされない限り
同じスレッドで実行することでデータ転送を減らすよう考慮されてる
スティールされるのが古いタスクからなのも同じ理由
それに比べてCSPはどうだ？
0555デフォルトの名無しさん2008/05/31(土) 18:16:47
>>554
>fork/joinはスティールされない限り同じスレッドで実行することでデータ転送を減らすよう考慮されてる
SMT(ハイパースレッディング)が登場してから、おかしな対処をしないと性能がでなくなって必ずしもそうなっていないよ、今は。
0556デフォルトの名無しさん2008/05/31(土) 18:24:58
>>555
そうか？tbbやjsr166yのfor/joinは>554で書いたようになってると理解してるが。
ソースｷﾎﾞﾝ
0557デフォルトの名無しさん2008/05/31(土) 18:25:21
しかしまぁ、オペレーションズ・リサーチは情報系出身なら常識だろうと思うが、こういった基本すら知らない奴はどうしてくれるかなぁ
ゲーム理論や囚人のジレンマも知らないというのはどうかと思うんだ・・・
0558デフォルトの名無しさん2008/05/31(土) 18:28:29
>>556
Core 2 Quadマシンと、Windows Vista 買ってきて、ひとつアプリを走らせろ
そして、タスクマネージャーなり、ガジェットからCPUメーターをダウンロードして睨めっこをするんだ
そうすれば、ソースも必要ないし説明するまでもない筈。
0559デフォルトの名無しさん2008/05/31(土) 18:36:48
>>558
まさかProcessor affinityの話をしてるのか？
0560デフォルトの名無しさん2008/05/31(土) 18:37:45
>>559
謎用語出す前に、基本を勉強しとけ
0561デフォルトの名無しさん2008/05/31(土) 18:43:23
>>560
謎用語て…単なる煽りか？それなら消えてくれ
煽りじゃないなら>558とjork/joinのタスクスケジューリングの関係を説明してほしい
0562デフォルトの名無しさん2008/05/31(土) 18:44:11
ソースだせと、なぞ用語で捲し立てるのが趣味なら消えてくれ
0563デフォルトの名無しさん2008/05/31(土) 18:46:20
>>557
常識だと思うけど、大学卒業して10年の俺はさっぱり覚えてないw
0564デフォルトの名無しさん2008/05/31(土) 18:46:37
頭の悪いGKがいる、絶対いるw
0565デフォルトの名無しさん2008/05/31(土) 18:56:40
>>562
Processor affinityはWindowsでもLinuxでも商用UNIXでもAPIになってる
特定のプロセス／スレッドを特定のCPUに割り当てられやすくするもの。

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

さて、>555や>558について説明してもらえないかな
0566デフォルトの名無しさん2008/05/31(土) 18:58:27
>>565
CPUメーターみてみなよ、OSが勝手にスケジュールを調整してこちらの意向を無視している。
0567デフォルトの名無しさん2008/05/31(土) 19:03:08
>>566
そのアプリがSetThreadAffinityMask読んでないなけだろ
0568デフォルトの名無しさん2008/05/31(土) 19:04:05
>>567
単に、特定アプリに依存すると障害が多いからMSが調整しただけかと
0569デフォルトの名無しさん2008/05/31(土) 19:08:58
>>568
意味が分からない
SetThreadAffinityMaskを呼び出していないスレッドをOSが勝手に
スケジュールするのは当然のことだ
お前さんの言ってるアプリはSetThreadAffinityMaskを呼び出してるのか？
呼び出してないアプリでCPUメーター見ても全く意味がないんだが
Processor affinityを知らなかっただけじゃね？
0570デフォルトの名無しさん2008/05/31(土) 19:10:20
そっちの言っている事こそ意味不明だわw
0571デフォルトの名無しさん2008/05/31(土) 19:12:50
じゃあさ、>558で「ひとつアプリを走らせろ」のアプリが
SetThreadAffinityMaskを呼び出してるアプリのことかどうかだけ答えてくれ
yes/noだけでいいからさ
0572デフォルトの名無しさん2008/05/31(土) 19:14:01
こんなの、つまらないコード書いて、パフォーマンス確認目的でパフォーマンスカウンタ見れば一発なんだが・・・
なんでこんなややこしい話が登場するのかと・・・
0573デフォルトの名無しさん2008/05/31(土) 19:14:46
バカ相手にするのは疲れる
0574デフォルトの名無しさん2008/05/31(土) 19:22:31
>>572
ややこしい話はしていない
そのつまらないコードでSetThreadAffinityMaskを呼んだのかどうか、それだけだ。
これもyes/noだけでいいから答えてくれ
0575デフォルトの名無しさん2008/05/31(土) 19:31:59
SetThreadAffinityMaskじゃなくSetProcessAffinityMaskなら
タスクマネージャーから設定できる。
プロセスタブでプロセスを選んで右クリック、関係の設定でCPUを選ぶだけ
0576デフォルトの名無しさん2008/05/31(土) 20:07:00
逃げたようだな。結局Processor affinityすら知らなかっただけだけか
何が「基本を勉強しとけ」だよｗ
きっとfork/joinも何のことかわかってないんだろうな…
0577デフォルトの名無しさん2008/05/31(土) 20:31:28
割り込んでごめんなさい。
windows 2k serverってマルチコアに対応してますか？

windows serverは全部対応してるって記事をネットで見たけど、
記事自体、いまいち信用できないんです。
0578デフォルトの名無しさん2008/05/31(土) 20:57:52
雑誌記事が信用できずに、誰の発言かもわからない
掲示板の話を信用するんですか？
0579デフォルトの名無しさん2008/05/31(土) 21:16:49
>>578
どっちもどっちですが、広告だらけのブログで「対応してる。」って言われるのと比べるなら、
まだ、ここのほうが信用できます。

「ここで公式に書いてるよ！」みたいなレスがあればなぁなどと思った次第です。
0580デフォルトの名無しさん2008/05/31(土) 21:31:15
それプログラミングと関係ないだろスレ違いだしageんな
0581デフォルトの名無しさん2008/05/31(土) 22:21:36
>>578
P4-2.4Cで2個見えてるから、2個までは対応してると思うよ
＃手元に2コアまでしかないからそれ以上は分からんｗ
0582デフォルトの名無しさん2008/05/31(土) 22:25:52
初心者ですまんが
Ｐｇ作るのにマルチコアなんて気にする必要アンの？
いいところスレッド処理とか流せば
しかたねえな　ってかってに動いてくれそうだけど
0583デフォルトの名無しさん2008/05/31(土) 22:35:21
そのいいところってのが難しいんじゃない？
いままでみたいな粗い粒度のスレッドの使い方じゃなくて、もっと積極的に
例えば単なるクイックソートを2〜4スレッドで並列実行して高速化しようとか、
そういうのを考えるんじゃないかなたぶん
0584デフォルトの名無しさん2008/05/31(土) 22:35:59
>>582
ここは君が来るところではないんだよ。
ここはデュアルコアならシングルコアの2倍、クアッドコアなら4倍の
パフォーマンスを目指すスレ。

今のところ有益な議論は一度もないけどな。
0585デフォルトの名無しさん2008/05/31(土) 22:54:45
Processor affinityも知らないSoftware Transactional Memoryも知らない
wait freeやlock freeの話も出ない
有益な議論のしようがないなｗ
0586デフォルトの名無しさん2008/05/31(土) 22:56:05
>>584
キャッシュに入るような小さな処理から頻繁にメモリアクセスが必要な処理をした際
実際のパフォーマンスを比較したものってどっかにないの？
0587デフォルトの名無しさん2008/05/31(土) 23:03:12
マルチスレッドスレと話題かぶるからなぁ
0588デフォルトの名無しさん2008/05/31(土) 23:17:48
>>582
俺も気になった。
winのapiには無いと思う。

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

と、初心者は思うのでした。
0589デフォルトの名無しさん2008/05/31(土) 23:52:50
初心者だと思うなら、「winのapiには無いと思う。」なんてろくろく調べもしないで
レスするなよ。
0590デフォルトの名無しさん2008/06/01(日) 00:07:59
マルチコア対応apiはwinにはないね。未熟なOSなのかも。
0591デフォルトの名無しさん2008/06/01(日) 00:18:47
同一ソケット上のマルチコアに特化したAPIはないわな。未熟だわなｗｗｗ
0592デフォルトの名無しさん2008/06/01(日) 00:19:17
windows上なら、SetXXXAffinityMaskってのを使うみたいだけど、
OSに任せたほうが無難だろうな。
ビットマスクに何指定するのか、俺の古いMSDNだとわかんないし。

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

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

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

以上、>>577の自己回答でした。
0593デフォルトの名無しさん2008/06/01(日) 00:22:55
>>589
嫌味な上級者は、絶対何も言わないんだよな。

さっきからずっと、むかつくレスしてんのこいつだろ？
上司でたまにいるんだよ。
知ったかして、具体的に何も言わないで、誰かが言ったら便乗するやつ。
0594デフォルトの名無しさん2008/06/01(日) 00:27:06
そりゃ、言うべきじゃない時を心得てるのが上級者というものだからなあ
0595デフォルトの名無しさん2008/06/01(日) 00:31:12
>>592
MSDN見たなら「参照」も見るといいよ
0596デフォルトの名無しさん2008/06/01(日) 00:43:55
>>592
あんまり調べる気無い。
何か映像関係の高速処理組むなら別だけど予定もないし。
スレッド、プロセス関連は完全に２、３継承のクラス化しちゃってるし、
いまさらOSの判断以上の速度が出るように直す気はない。
0597デフォルトの名無しさん2008/06/01(日) 00:44:33
時代がマルチコアなのになぜ対応apiがないのか？
これはMSの怠慢ではないだろうか
高いOSライセンス代（１台につき１万〜３万）を定期的（５年程度）に払っているというのに
ひどい話だ
0598デフォルトの名無しさん2008/06/01(日) 00:51:54
>>597
マルチコア対応APIって具体的にどういうものよ？
0599デフォルトの名無しさん2008/06/01(日) 01:06:17
>>597
だからwindowsにもあるって。
プロセッサを直接指定できるapiが。
やっぱNT系のカーネル作った連中は偉いわ。
おれもまだまだ2kで行く。
0600デフォルトの名無しさん2008/06/01(日) 01:10:52
マルチコアねぇ…
TPC風にProcessor/Core/Threadで表すと、Core2Quadの1/4/4はマルチコアだよな。
じゃあシングルコアXeonを4個使った4/4/8とかItaniumを64個使った64/128/256は？
後者もマルチコアならマルチコア対応APIは既にある。
0601デフォルトの名無しさん2008/06/01(日) 01:12:08
マルチダイもマルチコアに含めてるしな、、、思想的には
ていうか、やっぱまだ２ｋって需要あるかなー？
今新規にフリーソフト作ってるが、どこまでサポートするか悩む
0602デフォルトの名無しさん2008/06/01(日) 01:15:22
>>599
Processor affinityはDECのVMSの時代からある。
WindowsNTと作った連中は同じだけどなｗ
0603デフォルトの名無しさん2008/06/01(日) 01:19:14
>>601
俺、フリーソフトは、2kで作って、xpで軽く動かしてテスト終わり。
2kで動いて、xpで動かなくなったことはない。
基本、Direct X関係に気をつけるだけ。
0604デフォルトの名無しさん2008/06/01(日) 01:22:24
CPUが別パッケージかオンダイかを気にするような場面には出くわしたことないなあ
キャッシュの奪い合いとか同期の頻度とかが問題になるのかな？

むしろhyper threadingが特別だったんじゃないかと思う
0605デフォルトの名無しさん2008/06/01(日) 01:24:49
Win32のSetThreadAffinityMaskはaffinity maskがDWORDで32bitしかない
64/128/256のSuperdomeはOSからは256プロセッサに見えるんだがどうするんだ？ｗ
0606デフォルトの名無しさん2008/06/01(日) 01:27:16
hyper threadingは鬼門
0607デフォルトの名無しさん2008/06/01(日) 01:29:44
>>606
Pen4のHyper Threadingだけが鬼門？ SMT全般が鬼門？
ちょっとだけPower使ったときは何もなかったけどな
0608デフォルトの名無しさん2008/06/01(日) 02:01:39
>>605
いずれSEtThreadAffinityMaskExが出来るだけよ
0609デフォルトの名無しさん2008/06/01(日) 02:05:55
>>608
いずれってかSuperdomeにWindowsが乗ってから5年以上経ってないか？
Windows乗ったSuperdome俺は見たことないけどｗ
0610デフォルトの名無しさん2008/06/01(日) 02:08:16
テキトウに仮想化でもしたほうが効率よさそうな気が
0611デフォルトの名無しさん2008/06/01(日) 02:14:38
>>610
それは現実的すぐるｗ
とりあえずタスクマネージャーはこうなる
ttp://www.microsoft.com/japan/sql/images/ssj/ki03_02_l.jpg
これで「関連の設定」は64CPU設定できるのか？
つかItaniumだから64bit Windowsか…
0612デフォルトの名無しさん2008/06/01(日) 02:54:12
Win64ではﾓｰﾏﾝﾀｲだた

BOOL WINAPI GetProcessAffinityMask(
__in HANDLE hProcess,
__out PDWORD_PTR lpProcessAffinityMask,
__out PDWORD_PTR lpSystemAffinityMask
);

DWORD_PTR WINAPI SetThreadAffinityMask(
__in HANDLE hThread,
__in DWORD_PTR dwThreadAffinityMask
);
0613デフォルトの名無しさん2008/06/01(日) 03:25:02
>>607
606じゃないけど、HTは面倒な存在じゃない？
普通のマルチプロセッサなら異なるプロセッサ間で同じキャッシュラインに
アクセスしない方が良いが、HTの場合は逆でしょ？
ベンチ取ってないんで、どのくらい影響があるのかは具体的には分からんが。
0614デフォルトの名無しさん2008/06/01(日) 03:36:55
menndouda
0615デフォルトの名無しさん2008/06/01(日) 03:41:14
>>613
それはPower含めてSMT全般にいえるし、少しレイヤをずらすと
2(3)次キャッシュ共有のマルチコアやNUMAにもいえるんで、
そんなに特殊なことではない。

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

これで距離の近いノード内のプロセッサマスクを取得できる。
NUMAアーキテクチャに限定せず、SMTやキャッシュ共有のコアを
ノードと見なすことができると、細粒度並列実行で効果的なヒントを
与えられるかもしれない。
0616デフォルトの名無しさん2008/06/03(火) 13:35:38
マルチコア対策としてこんなのがあります。

http://www.axon7.com/

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

http://www.cspjapan.org/







0617デフォルトの名無しさん2008/06/03(火) 13:45:14
>>616
>537
0618デフォルトの名無しさん2008/06/03(火) 13:58:55
マルチプロセス、マルチスレッド、マルチコア、マルチプロセッサ、SMT、メモコン共有、キャッシュ共有、演算器共有。
これが複合的に絡んだときの最適化は複雑すぎる。
0619デフォルトの名無しさん2008/06/03(火) 14:44:35
>>617
>549
0620デフォルトの名無しさん2008/06/03(火) 14:47:41
間違えた、>619は>616へ。

>>618
それをコンパイラで成し遂げることが前提のItaniumは不可能に挑んだようなものだな
0621デフォルトの名無しさん2008/06/05(木) 13:51:00
マルチコアは、今までのソフトウェア技術を台無しにしてくれる素晴らしい技術だよね。
これからはソフトウェアとハードウェアの境界が無くなって、
プログラムを作るのは、より一層大変になる。
0622デフォルトの名無しさん2008/06/05(木) 14:08:33
ハードとソフトが緊密に絡む領域はこれまでもあったんだけどな
無停止システムとか
0623デフォルトの名無しさん2008/06/05(木) 14:08:49
今までのマルチプロセッサ向けのソフトウェア技術の延長にあるから
台無しという事は無いよ。もう何十年も研究が続けられている分野だ。
0624デフォルトの名無しさん2008/06/05(木) 15:54:23
何十年も研究とか、無駄の極地だねｗｗｗ
0625デフォルトの名無しさん2008/06/05(木) 16:04:53
ロックフリーのアルゴリズムやトランザクショナルな変数アクセスが
もっと一般化してくれば、そんなに恐れる物でもない気がするけどね
0626デフォルトの名無しさん2008/06/05(木) 17:43:57
>>621
いったい何に怯えているんだろうか
0627デフォルトの名無しさん2008/06/05(木) 18:51:05
まあそりゃ単一スレッドで速くなるほうがありがたいけどな
0628デフォルトの名無しさん2008/06/05(木) 19:06:01
荒い粒度の並列化や、ベクトルの並列処理はとっくに研究され尽くされてるけど、
その中間が非常に厄介。
しかし、これからは単一スレッドでは速くならないわけだから、それをやらないといけない。
0629デフォルトの名無しさん2008/06/05(木) 19:53:53
ループを展開する自動並列化くらいはインフラとして整備して欲しいね
0630デフォルトの名無しさん2008/06/05(木) 23:02:40
>>629
自動じゃなくてもparallel array使えばおk
0631デフォルトの名無しさん2008/06/05(木) 23:56:43
>>628
divide and conquer
work stealing
fork/join
parallel array
0632デフォルトの名無しさん2008/06/07(土) 23:32:29
遅レスだが
ハードウェア・ソフトウェア協調設計等は組み込みでは昔からよく見られるんじゃないか？
まあ、シミュレーター等の開発統合環境が整えられているなら最適化はむずかしくないよ。
ただ工数と時間と労力が膨大に費やされていくだけで
0633デフォルトの名無しさん2008/06/13(金) 19:49:18
組み込みの場合は、環境のプロセッサ数やプロセス数は固定されてるから、難易度は低いんじゃないかな。
PCの場合は、対象のプロセッサ数は予想できないし、同時にどんなプロセスが動くかも分からないから、難易度が高い。
というか、PCの場合は、何らかの動的最適化メカニズムが必要になるんだよね。

http://pc.watch.impress.co.jp/docs/2008/0613/hot554.htm
インテルはCを拡張してJITコンパイラで最適化する研究をしてるようだけど、
実用化はまだまだ先だよな。
0634デフォルトの名無しさん2008/07/06(日) 06:28:11
１．マルチなんたらとか並列化とか、なにも考えずに作る。
２．あとは開発環境とOSがなんとかしてくれる。
３．下手なこと考えるより、そのほうが最終的に効率が良い。

こういうのが理想なんだけどなぁ…。
0635デフォルトの名無しさん2008/07/06(日) 09:34:03
スレ民じゃないけどマルチコアネタがあったのでぺたぺたしていきます。

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

　今後の研究テーマとして笹田氏は、並列処理への対応など
スケーラビリティに取り組みたいと話す。ただ、「Rybyの言語仕様の
枠組みでスケーラビリティを上げるのは難しい」ため、マルチコア、
マルチプロセッサといった密度の高い並列化よりも、クラスターや
グリッドのようにネットワークで接続された複数ホストによる並列化を
実現していくのがいいのではないかという。
0636デフォルトの名無しさん2008/07/06(日) 10:51:06
>>634
それ何て第五世代

>>635
むしろマルチコア関係なくね？
0637デフォルトの名無しさん2008/07/06(日) 10:59:42
マルチコア向けの最適化はしない方向だ、という内容だな。
0638デフォルトの名無しさん2008/07/06(日) 16:27:58
今後もRubyのスレッドはマルチコアを使いこなすようにはしない方針ということだな
0639デフォルトの名無しさん2008/07/06(日) 16:42:50
Rubyなんて並列化のこと何も考えてないじゃん。
書いててわくわくするとか日和ったこと言ってる言語では到底無理。
0640デフォルトの名無しさん2008/07/06(日) 20:49:23
並列化に興味をもったRuby使いはErlangあたりに移行するのだろうか
0641デフォルトの名無しさん2008/07/06(日) 23:42:11
アルファブロガー（笑）あたりに煽ってもらえばイッパツよ
0642デフォルトの名無しさん2008/07/07(月) 14:51:27
jruby
0643デフォルトの名無しさん2008/07/12(土) 12:34:27
Erlangが騒がれてるのは副作用がないのとメッセージングがあるからなの?
ほかの言語でも多少見苦しくなっても同じことはできんの？教えてエロイ人。
0644デフォルトの名無しさん2008/09/06(土) 10:33:33
>クラスターや
>グリッドのようにネットワークで接続された複数ホストによる並列化を
>実現していくのがいいのではないかという。

ハードは明らかにマルチコアに進んでいて、
サーバも集約統合が進んでいるというのに。

Rubyみたいなソフト側が手前の都合だけで
「いいのではないか」とかいって方針だしても何の意味もないわけだが。

誰もそんなハード持ってません。
今のハードにあってません。

ってなるだけ。
0645デフォルトの名無しさん2008/09/06(土) 17:36:31
なに、寝ぼけたレスしてるんだ？
>>644 は、Ryby という新言語について語っているんだぞ。
0646デフォルトの名無しさん2008/09/06(土) 19:45:47
>>645
誰に言ってるの?
0647デフォルトの名無しさん2008/09/06(土) 20:28:00
なに、寝ぼけたレスしてるんだ？
>>644 は、Ruby という言語について語っているんだぞ。
0648デフォルトの名無しさん2008/09/06(土) 20:50:57
なんだ、キ印か。
0649デフォルトの名無しさん2008/09/27(土) 22:48:29
>>644 って、Googleのサーバーとか、AmazonのEC2とか、分散環境が流行ってるのを知らないのか。
サーバーの集約統合が進んでるのは、既存のサーバーや負荷の低いサーバーでしょ。
0650デフォルトの名無しさん2008/09/28(日) 17:23:48
分散環境が流行ってるって…
すごい規模なんだからどっちにしても分散が必要なのは当たり前。
googleなんかは2003年の時点でこれからはマルチコアみたいなこと言ってるぞ。
0651デフォルトの名無しさん2008/09/28(日) 17:40:39
実際流行ってるんだけどなぁ。
クラウドとかいうキーワードでぐぐってみりゃわかると思うよ。
実効性はともかくね。
0652デフォルトの名無しさん2008/09/28(日) 17:44:47
クラウドが流行ってるってのはSOAが流行ってるってのと
どっこいどっこいだな。
ごく一部で当たり前になってるのと広く使われてるのとは
全然違ってて、どっちの話をしてるかがズレてるんだな。
0653デフォルトの名無しさん2008/09/28(日) 17:49:52
P2P→グリッド（言い換え）→クラウド（言い換え２）
0654デフォルトの名無しさん2008/09/28(日) 17:50:04
オフコン時代の鯖だと鯖っていえば特定の対応関係になってたのが
OOのポリモフィズムみたいな多態になっただけだ

C<->Sの関係が1:1だったのが
C<->Sの関係がN:Mになっただけだ
SOAはC<->Sの関係がN:1だったがな

たしたことない。言葉変えて変化を促そうとしている単なる言い換えだ
詐欺の一種だ
0655デフォルトの名無しさん2008/09/28(日) 17:56:49
クラウドとマルチコアって関係ないじゃん
0656デフォルトの名無しさん2008/09/28(日) 18:12:59
まあ関係はないね
ハードの保守性とソフトのスケーラビリティを考えて、
マルチコアのマシンを仮想化してクラウドにするみたいな
話は聴いた事あるけど

>>654
ハイプで成り立ってる所も大きいから、そんなもんかと

http://www.atmarkit.co.jp/aig/04biz/hypecycle.html
0657デフォルトの名無しさん2008/09/28(日) 18:41:15
とりあえずクラウドはスレ違いだろ
並列化の粒度が違う。クラウドは祖粒度、こっちは細粒度
ネタがないから構わんけど
06586512008/09/28(日) 18:45:37
>>652
どっこいどっこいというか、いままでSOAをかついでたところが、クラウドを担ぐようになってる。
SOAのように、クラウドは流行っている。まあそういう意味だ。
この件は、これで。
0659デフォルトの名無しさん2008/09/28(日) 18:52:32
すかしっ屁こいてクライアント騙すのがクラウドなのか？
0660デフォルトの名無しさん2008/09/28(日) 18:59:16
そう思う奴はいつまでも足踏みしてればいいのさ
0661デフォルトの名無しさん2008/09/28(日) 19:07:46
>>657
×祖粒度
○粗粒度
0662デフォルトの名無しさん2008/09/28(日) 21:04:14
クラウドもSOAもわかってないやつ多すぎ。
そんなやつらがマルチコア云々なんてしょーもねー。
せいぜい単純労働者としてコキ使われてなｗ
0663デフォルトの名無しさん2008/09/28(日) 21:08:22
どっちもバズワードなんだから分かっているという方がおかしい
0664デフォルトの名無しさん2008/09/28(日) 21:36:35
バズワード自体がバズワードというパラノイア
0665デフォルトの名無しさん2008/09/28(日) 21:46:40
バズワードを使ってる人間はバズワードかどうかなんて気にしていないから、
一回りして結局おk
0666デフォルトの名無しさん2008/09/29(月) 17:24:22
>>658
SOAと普及でぐぐると
・普及が進まない
・普及促進
・普及狙う
・普及を目指す
・普及を後押しする
こんなんばっかですけど？
流行ってるけど普及しない。笛吹けど踊らずw
0667デフォルトの名無しさん2008/09/30(火) 01:37:12
クラウドはどうかと思うが、分散は物理的な話でもあるし必要なところには普及するんじゃないかな。
CPUでの並列だと限界が低いし拡張も難しいから、>>656の言うようなマルチコアマシンの仮想化で分散ってのが現実的ではないだろうか
0668デフォルトの名無しさん2008/09/30(火) 07:01:26
つまり金融工学みたいな
もんですね
0669デフォルトの名無しさん2008/10/01(水) 18:54:26
「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
http://www.computerworld.jp/topics/cloud/123069.html
06706442008/10/01(水) 20:30:34
644ですが普段アーキスレとかに書いている身からすると、
このスレの住人はレベルが低すぎます。
キミらが並列化について語るのはまず無理。
チップあたりの性能をあげられなくなったら、
分散処理でも同一コストで性能あげられないの。
Rubyの件はいかにもソフトしかしらない人向けの
苦しいいいわけだなあと。
0671デフォルトの名無しさん2008/10/01(水) 20:51:50
自分以外みんなバカ症候群
0672デフォルトの名無しさん2008/10/01(水) 23:06:07
ひんと: 賢い奴はこんなスレの住人なんて相手にしない
0673デフォルトの名無しさん2008/10/02(木) 00:04:30
レベルが低過ぎてどこを縦読みすれば良いのか分からないや
0674デフォルトの名無しさん2008/10/02(木) 00:21:48
アーキスレってどこ？
殴りこみかけてくる
0675デフォルトの名無しさん2008/10/02(木) 00:59:37
残念だけど、現状ではマルチコアってサーバサイドや一部の
embarrassingly parallel な処理以外では絵に描いた餅だよね。
デスクトップ機でクアッドコア以上のプロセッサが必要な
場面は思い付かない。それこそハード寄りの知識を持っていない、
スレッド周りの実装の知識も無い様なプログラマが、難しい事を
考えずに処理性能を出せる仕組みが欲しい物だね。fork/join でも
ヘテロなマルチコアでも何でも良いけど。
0676デフォルトの名無しさん2008/10/02(木) 01:16:48
後はトランザクショナルメモリと投機的実行も期待してるけど
なかなかこういうのは普及しないねえ…
0677デフォルトの名無しさん2008/10/02(木) 01:20:49
ゲーム機でやってるじゃん
0678デフォルトの名無しさん2008/10/02(木) 02:33:49
>>676
投機的実行ってRockのスカウトスレッド？
命令レベルの投機的実行と紛らわしいから用語は分けたいな
同時投機スレッド(Simultaneous Speculative Threading)とかな

トランザクショナルメモリはどうかねー
RockのHTMじゃアプリケーションレベルのトランザクション
扱うのは無理だしSTM組み合わせるとオーバーヘッドが大きすぎて
性能出ないと予想してる
つRockの出荷来年の後半とか遅れすぎだろjk
0679デフォルトの名無しさん2008/10/02(木) 20:15:08
今普及しているデュアルコアマシンみたいな感じで
6 core のマシンが一番売れ筋のマシンになったら
プログラマはどうすればいい?
0680デフォルトの名無しさん2008/10/02(木) 21:08:30
Vistaをお勧めする
あとセキュリティソフトを３つぐらい重ねがけ
これで万全
0681デフォルトの名無しさん2008/10/02(木) 21:30:33
>>674
CPUアーキテクチャについて語れ Part.12
http://pc11.2ch.net/test/read.cgi/jisaku/1219884494/

最近は常駐コテの意地の張り合いばかりでつまらないくなってきてるけど
アーキテクチャスレは↑
普段は名無しだが、MACオタ(翻訳)などは漏れ。
がんばって殴り込みに言ってくれや。
0682デフォルトの名無しさん2008/10/02(木) 21:43:42
>>681
なんでこのスレ来てるの？
0683デフォルトの名無しさん2008/10/02(木) 22:18:05
>>681
2chらしいスレだなw

40 名前：Socket774[sage] 投稿日：2008/08/29(金) 02:47:03 ID:Yk6PbdtE
ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします

とか書かれててﾜﾛﾀ
お前そんなに態度悪いのかよw
0684デフォルトの名無しさん2008/10/02(木) 22:36:01
ダンゴさんそこでがんばってたのか

お似合いだなｗ
0685デフォルトの名無しさん2008/10/02(木) 22:43:59
せっかく収まるところに収まってるのに煽らないでくれ。頼むから。
0686デフォルトの名無しさん2008/10/03(金) 00:45:17
644みたいな状態って、自分の専門は知ってるんだけど他のことは知らなくて、自分の知らないことはたいしたことないって思ってるだけなんだよね。
というか、自分が他のことを知らないことを知らない。
だから、「このスレの住人はレベルが低すぎ」とか言っちゃう。
0687デフォルトの名無しさん2008/10/03(金) 00:48:56
でもまぁ、このスレのレベルが低いのは事実だろう。
レベル高い議論って一つでもあったか？ないよな。そういうことだ
0688デフォルトの名無しさん2008/10/03(金) 00:53:53
マルチコア用のテンプレートライブラリを活用しているという話を聞かないね
良さげなのにググっても実際に使っている例が殆ど出て来ない
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/
0689デフォルトの名無しさん2008/10/03(金) 01:26:23
ライブラリの話はマルチスレッドスレがあるからなあ
このスレいらない子なんじゃ…
0690デフォルトの名無しさん2008/10/03(金) 01:39:29
>>687
「住人はレベルが低すぎ」などと書いて無用に荒らすのが一番レベル低いがな。
0691デフォルトの名無しさん2008/10/03(金) 02:36:30
>>689
要らなかったらスレが亡くなるだけだから気にしなくておk
0692デフォルトの名無しさん2008/10/03(金) 03:39:27
>>689
マルチスレッドとマルチコアでの並列化は違う。
0693デフォルトの名無しさん2008/10/03(金) 04:03:36
>>692
どう違うか語ってもらおうか
0694デフォルトの名無しさん2008/10/03(金) 04:06:23
マルチスレッドは、タイムスライスで同時に動かなくてもおけ
0695デフォルトの名無しさん2008/10/03(金) 04:31:02
マルチスレッドが並列に動かなくていいわけないだろ
マルチコア以前からマルチプロセッサは当たり前にあるんだしよぉ
本気でレベル低いなここ…
0696デフォルトの名無しさん2008/10/03(金) 05:34:37
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできなくてもマルチスレッドは可能ってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。
0697デフォルトの名無しさん2008/10/03(金) 07:28:21
windowsもクラウドが標準になるんだな
http://japanese.engadget.com/2008/10/01/os-windows-cloud/
0698デフォルトの名無しさん2008/10/03(金) 10:41:52
>>696
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできない時のマルチスレッドとマルチコア/マルチプロセサでのマルチスレッドじゃ状況が違うってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。

>>692
そもそも、マルチコアとマルチスレッドを比較するなよ。
0699デフォルトの名無しさん2008/10/03(金) 10:53:10
>>698
おいおい、状況は違うのは分かるが、プログラムは同じにしとかないと
まずいだろ。

どこかのエンコソフトみたいにCPUのコア数によって使うルーチンを切り替える
ようにするなら話は別だが。
0700デフォルトの名無しさん2008/10/03(金) 11:50:27
誰もプログラムを別にするとかなんて言ってないけど？

状況が違うと言うのはシングルコア and シングルプロセサで問題ないプログラムでも
マルチコア or マルチプロセサで問題が発生するケースがあるってだけ。

種々の要件によって、その状況によってプログラムを切り替える実装はあると思うが、
それはもっと条件を限定しないと議論できない。
0701デフォルトの名無しさん2008/10/03(金) 12:03:57
デッドロックとかレース状態とかそういう次元の事かな。
確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
マルチコアにした途端に顕在化する場合はあるね。
0702デフォルトの名無しさん2008/10/03(金) 12:37:48
>>701
マルチスレッドプログラミングとしては単なるバグじゃん
0703デフォルトの名無しさん2008/10/03(金) 12:38:00
> 確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
> マルチコアにした途端に顕在化する場合はあるね。

そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
プロセサではあり得ない問題」のことだよ。
0704デフォルトの名無しさん2008/10/03(金) 12:39:40
>>703
それはクリティカルセクションを入れるのが当たり前だろ
0705デフォルトの名無しさん2008/10/03(金) 12:40:56
>そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
>ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
>プロセサではあり得ない問題」のことだよ。
アトミック操作でないのにロックせずに破壊した場合プログラマの責任だと思うが。

0706デフォルトの名無しさん2008/10/03(金) 12:42:23
>>703
そんなバグ埋め込んでマルチスレッドとか恥ずかしいぞ
0707デフォルトの名無しさん2008/10/03(金) 12:43:53
>>703
もうちょっとOS関連の本を読んでマルチプロセス/マルチスレッドに
ついて勉強してから書いた方がいいよ。恥かくだけだぞ今のままじゃ。
0708デフォルトの名無しさん2008/10/03(金) 13:08:13
>>698
そもそもというなら、マルチスレッドとマルチコアの話は、 >>689に言ってくださいな

「マルチスレッドが並列に動かなくていいわけないだろ」とか言っておいて逆切れせずに。
07096892008/10/03(金) 13:38:17
>>708
比較なんかしてないぞ
マルチスレッドがマルチコア環境で正しく並行動作するのは当然
だからライブラリの話はマルチスレッドスレの方がそれなりに議論してて
適切だろうってことだ
マルチスレッドスレを並行動作しなくていい話題に限定したら
糞スレ確定で速攻落ちるぞw
0710デフォルトの名無しさん2008/10/03(金) 13:44:20
同じ変数を複数スレッドで更新する可能性があるなら、UP/MPに限らずバリア入れる。
更新するのが一人だけだったら、ちょっと考えてから決める。
0711デフォルトの名無しさん2008/10/03(金) 13:44:22
そういう話は、その時点でやってくださいな。
あと出しで切れるのカコワルイ
07127112008/10/03(金) 13:44:54
>> 709 ね。
0713デフォルトの名無しさん2008/10/03(金) 13:49:36
>>711
どこが後出し？w
0714デフォルトの名無しさん2008/10/03(金) 17:59:44
>>704
そもそもクリティカルセクションをどう構成するかと言うレベルの話だから、
君には用はないので当分 ROM っててくれ。

>>705-706
シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。

マルチコア/マルチプロセサではちゃんと動かないから良くないコーディングと
言うならまだわかるが。

>>707
どこがどうおかしいかちゃんと指摘してくれ。
まさか、>>705-706 の的外れの指摘のこと言ってるのか？ (w
0715デフォルトの名無しさん2008/10/03(金) 20:19:54
>>714
アホですか
RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
物があるのでアトミックではない場合がある
0716デフォルトの名無しさん2008/10/03(金) 20:20:58
つーか明らかな自分のミスを認められないグラマって
必要ないな。

こういう奴がいると絶対にプログラムにバグを入れてくれる。
0717デフォルトの名無しさん2008/10/03(金) 20:28:36
そろそろダンゴさんがピシっと〆めてくれそうだ
0718デフォルトの名無しさん2008/10/03(金) 20:32:18
つかシングルコアでも他デバイスがDMAしてきたらアトミックにならんやろ

メモリにアクセスするプロセッサがひとつだけっていつの話？
0719デフォルトの名無しさん2008/10/03(金) 20:33:29
Java のでも GCC 組み込みのでも、OS ネイティブのでも良いけど、
アトミック命令ってみんな使ってるの?
0720デフォルトの名無しさん2008/10/03(金) 20:53:25
排他やると暗黙的に使われるんじゃね
0721デフォルトの名無しさん2008/10/03(金) 20:56:23
無意味な連番つけるときに AtomicInteger を使ったことはある
0722デフォルトの名無しさん2008/10/03(金) 21:03:47
AtomicReferenceFieldUpdaterは友達
0723デフォルトの名無しさん2008/10/03(金) 21:41:05
レベルの低いスレ/話題は伸びるのが速い。
0724デフォルトの名無しさん2008/10/03(金) 21:49:12
レベルの低い話題に詳しそうだな
0725デフォルトの名無しさん2008/10/03(金) 22:04:26
>>715
> RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
> 物があるのでアトミックではない場合がある

そんなプロセサにメモリに対する inc 命令なんかあるのか？
あるんならそのプロセサの型名書いてくれ。

>>716
「明らかな自分のミス」ってどれのこと？
ちゃんと指摘してくれって書いてあるのに指摘できないの？

>>718
ああ、DMA はあるな。
ただ、通常の DMAC はレジスタで制御するから、メモリ上で排他なんかしないでしょ？

> メモリにアクセスするプロセッサがひとつだけっていつの話？

今でも普通にあるよ。PC しか眼中にないの？
0726デフォルトの名無しさん2008/10/03(金) 22:07:57
また前提が増えたな。

DMA無しだとさ。
0727デフォルトの名無しさん2008/10/03(金) 22:19:48
>>718見て、Windows 98で386のときのInterlockedIncrementは、
デバイスドライバ内で割り込み禁止してincを実行するって話を思い出した。
http://blogs.msdn.com/oldnewthing/archive/2004/05/06/127141.aspx
0728デフォルトの名無しさん2008/10/03(金) 22:22:31
>>726
また？
DMA 以外で増えた前提って何のことだ、ちゃんと書いてくれよ。
0729デフォルトの名無しさん2008/10/03(金) 22:37:24
>>725
> そんなプロセサにメモリに対する inc 命令なんかあるのか？
> あるんならそのプロセサの型名書いてくれ。
無いからバグなんだろ。

>714 の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
に対する返信だろう。
0730デフォルトの名無しさん2008/10/03(金) 23:00:16
>>728
きっと>714の「シングルプロセサ/シングルコアなら」のことだろうね
0731デフォルトの名無しさん2008/10/03(金) 23:01:26
>>725
> 今でも普通にあるよ。PC しか眼中にないの？

SPARC/Power/Itaniumサーバも眼中に入ってるよ
0732デフォルトの名無しさん2008/10/03(金) 23:05:07
>>725
> 「明らかな自分のミス」ってどれのこと？
> ちゃんと指摘してくれって書いてあるのに指摘できないの？

>714の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
のことだろうね
0733デフォルトの名無しさん2008/10/03(金) 23:23:14
Itaniumなんてもうフェードアウトだろｗ
0734デフォルトの名無しさん2008/10/03(金) 23:27:20
>>733
FNHではバリバリですよ
FはSPARCに注力した方がいいと思うけど東証決まってるからなあ
0735デフォルトの名無しさん2008/10/03(金) 23:31:27
なんか、自分のミスはスルー、この反応みると本当に気づいてないようだ。だから自分はノーミスだと思っている。
前提をあとからつけて、人の意見を間違っているという。
まわりが全員レベル低いんじゃなくて、君ひとりがまわりの会話についていけてないんだってば。
0736デフォルトの名無しさん2008/10/03(金) 23:42:48
>>729, >>732
> 無いからバグなんだろ。

「メモリに対する inc 命令持たないプロセサだとメモリのインクリメントは必然的に
複数命令になるからアトミックじゃないだろ？」って言ってるの？

ならすまん、inc 命令の話してる時にその命令持たないプロセサまで考慮して話せと
言う奴がいることまでは想定できなかったよ。

世の中には自力ではメモリのインクリメント自体ができないプロセサもあったりする
からそこから前提におけということかな？ (w

>>730
>>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

>>731
> SPARC/Power/Itaniumサーバも眼中に入ってるよ

で、それしか知らないと思ってていいのか？
なら、もう少し見聞広めた方がいいんじゃね？ としか言えないけど。

>>735
「ミス」とか「間違っている」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。
0737デフォルトの名無しさん2008/10/03(金) 23:43:57
指摘されてもスルーなのが笑える
0738デフォルトの名無しさん2008/10/03(金) 23:44:39
これはひどい。
いくらなんでも釣りだろ？
0739デフォルトの名無しさん2008/10/03(金) 23:52:04
itaniumはもう終わりだろｗｗｗ




と5年間言われ続けて、無事生存中
0740デフォルトの名無しさん2008/10/03(金) 23:58:00
>>725
incはアトミックじゃない。
でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。
おまえさんはコンパイラがincに落とすのを当然と考えた上でincがバス制御しない事を忘れてる。
0741デフォルトの名無しさん2008/10/04(土) 00:03:13
>>736
> >>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。

その前提を持ち出してるのが大間違いの元なんだよ。
マルチスレッドプログラミング全般としてはそんな前提はないわけ。
君にとってはシングルプロセッサかつシングルコアがデフォで
マルチプロセッサ／マルチコアが特殊なのかもしれないが、
マルチスレッドプログラミング全般としてはシングルプロセッサかつ
シングルコアはマルチプロセッサ／マルチコアの特殊ケースでしかない。
マルチプロセッサ／マルチコアでちゃんと動かないようなのはただのバグ。
0742デフォルトの名無しさん2008/10/04(土) 00:07:03
というか、このスレ全体がひどい。
まず、議論になってない。
そして、議論以前に半分以上の書き込みが用語を並べてみているだけで技術的に意味の通る文章になっていない。
コンピュータ用語に語彙の偏った人口無脳がはき出したような文面の書き込みばかりで流れがない。
今時マルチスレッド、マルチコア、分散処理の区別もつけられない人がこんなにいるなんて信じられない。
日本のプログラマってこんなレベル低いんだ…こりゃ将来が危ぶまれるわ。
0743デフォルトの名無しさん2008/10/04(土) 00:10:15
>>742
だってここ2chだし
0744デフォルトの名無しさん2008/10/04(土) 00:14:50
>>742
たしかに、この発言とかひどいよね
「マルチスレッドが並列に動かなくていいわけないだろ」
0745デフォルトの名無しさん2008/10/04(土) 00:18:26
>>744
どうひどいか語ってもらおうか
0746デフォルトの名無しさん2008/10/04(土) 00:20:49
>>742
「このスレ全体がひどい。」とか「議論になってない。」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。
0747デフォルトの名無しさん2008/10/04(土) 00:21:03
今このPC、 AthlonXP 1500+ で 53プロセス 562スレッド 動いてるぜー
0748デフォルトの名無しさん2008/10/04(土) 00:21:33
>>745
マルチスレッドは並列に動かなくてもいい。
0749デフォルトの名無しさん2008/10/04(土) 00:23:52
マルチスレットは、タイムスライスでもいいから、並列に同時に動く必要はない。
0750デフォルトの名無しさん2008/10/04(土) 00:30:07
GreenThread
0751デフォルトの名無しさん2008/10/04(土) 00:38:13
>>748-749
並列に「動かさなくてもいい」ならそうだが
「動かない」ってのはダメだろ
つか確かに議論になってないな
コンテキスト整理するからちょっと待ってろ

07527422008/10/04(土) 00:38:53
そもそも「同時に動く」ってのはどういう意味でいってるつもりなんだ?
意味わからん。
たとえば
・レジスタやメモリに結果を書くのを同時といってる?
・実行ユニットで演算されるのを同時といってる?
・前後を入れ替えても意味が変わらない処理を同時だといってる?
もう少し頭の中で整理してかいてよ。
タイムスライスってどういう意味でいってるの?
コンテキスト情報をスワップすることがよくいわれる時分割の本質的な意味でしょ?
コンテキスト情報が複数ハード上にあるのがマルチプロセッサだったりマルチコアだったり
ハードウエアマルチスレッディングがスレッドレベルで並列であることの本質なわけだけど。
CPUが実行ユニットで同時に計算しているとか同時にメモリに結果を書くとか関係ないよね?
このスレで議論している連中は用語をならべているだけで、その中身についてはよくわかってない気がする。
回路設計が本業の漏れからみてもまず基礎がひどいと思いました。
0753デフォルトの名無しさん2008/10/04(土) 00:39:04
>>737
どこがスルー？
具体的に指摘しなよ。

>>740
> incはアトミックじゃない。

DMA の話？ それ以外にシングルコア/シングルプロセサを前提としてあるなら、具体的に
書いてくれ。

> でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。

そう言う命令がないプロセサもあるから、ちゃんと前提つけないとクレームつけられるよ。(w

> おまえさんはコンパイラがincに落とすのを当然と考えた

人の心まで読めるの？ 上級エスパーさんにはかなわないな。

>>741
前提つけたら、そんな前提が間違ってると来たか...。
そこまでしてレスしたいの？
まあ、どっちにしろそう言う文句は >>696 辺りにつけてくれ。
0754デフォルトの名無しさん2008/10/04(土) 00:41:31
>>752
> このスレで議論している連中は用語をならべているだけで、その中身については
> よくわかってない気がする。

自己紹介乙。
0755デフォルトの名無しさん2008/10/04(土) 00:42:44
結局、そこで議論にならなくなってるわけでね。
0756デフォルトの名無しさん2008/10/04(土) 00:47:57
そろそろ753はコテハンつけて欲しい
0757デフォルトの名無しさん2008/10/04(土) 00:50:19
>753は>703なんだよな？
だが>753は>696じゃないのか？
俺流れが見えてねぇw
0758デフォルトの名無しさん2008/10/04(土) 01:04:29
元々このスレはハードウェア主体でマルチコア化が進んでいるせいで、
ソフトウェアを並列化しないといけなくなったのに不満を持った
アンチマルチコア派ｗがたてたスレだからね。本当はソフト屋さんの
ためのスレッドなんだけど、有意義な話がなかなかでない。

回路屋が何かとソフト屋を馬鹿にしているようだけど、せっかく
マルチコアの石があっても、ソフトウェア側の理論がないと意味がなく、
またソフト屋はソフト屋の理屈があるのでそこら辺勘違いしないように
お願いします。

並列化といっても必ずしもバスアービタがどうとかそういう回路よりの
話だけでなく、並列型言語とかプロセス代数とか形式手法とかそういう話を
期待ているんだけど、やっぱり並列化に対するソフトウェア技術者の
意識は弱く、そういう話をができる人はあまりいないみたいだね。
(俺も話ができない一人だが、そういう人の出現を待ってこのスレ読んでます)
0759,,・´∀｀・,,）っ-○◎●2008/10/04(土) 01:12:53
だんごやさんだよ。
色んな意味でマルチスレッドだよ。
0760デフォルトの名無しさん2008/10/04(土) 01:16:34
> 並列型言語とかプロセス代数とか形式手法とか

ここ強調すると住人総入れ替えじゃないか？w
もし次スレ立てるならスレタイに【Π計算】って入れようぜ
0761,,・´∀｀・,,）っ-○◎●2008/10/04(土) 01:20:36
Π革命
0762デフォルトの名無しさん2008/10/04(土) 01:21:23
>>757
> >753は>703なんだよな？

あたり。

> だが>753は>696じゃないのか？

>>696 じゃなくて、>>698

> 俺流れが見えてねぇw

簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
マルチプロセサ」で、状況が違う例としてメモリに対する inc 命令を取り上げ
たら、inc 命令ないプロセサでは状況が違うとか (当たり前だ)、そもそも
「シングルコアでシングルプロセサ」なんて前提がおかしいとか言う奴が出て
きて騒いでるだけ。

# 正直 DMA のこと忘れてたのは事実。
# DMAC とメモリーを排他制御したことないので、すっかり忘れてた。

まあ、流れを追う価値はないから、安心してくれ。(w
0763デフォルトの名無しさん2008/10/04(土) 01:24:51
△ やっぱり並列化に対するソフトウェア技術者の意識は弱く
○ ソフトウェアベンダの合理的経営判断に基づいた技術者・コード屋に対する適切な仕事配分の結果
0764デフォルトの名無しさん2008/10/04(土) 01:28:36
Cilk とか UPC とか?
0765デフォルトの名無しさん2008/10/04(土) 01:33:11
>>762
> 簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
> マルチプロセサ」で、状況が違う例

その状況の違いは本来不要だったんだよ
どっちもマルチスレッドスレの対象になってるんだから
発端は

>>689
> ライブラリの話はマルチスレッドスレがあるからなあ
> このスレいらない子なんじゃ…

>>692
> マルチスレッドとマルチコアでの並列化は違う。

なんだから、マルチスレッドスレでは扱わないがこのスレ(マルチコアスレ)
の対象になる違いが話題になるべきだったんだ
マルチスレッドスレが「シングルコアでシングルプロセサ」の話題限定なら
外れてないがそんなこたーないわけ
0766レトリック君2008/10/04(土) 01:35:48
以前からあった並列計算機以上のことはできない罠
0767デフォルトの名無しさん2008/10/04(土) 01:36:41
>>764
C++なら>688、Javaならjsr166yのfork/joinやParallelArray、C#ならTPLとか？
0768デフォルトの名無しさん2008/10/04(土) 01:41:26
OpenMP, MPI
07697422008/10/04(土) 01:43:47
>>758
まあ、回路屋といっても計算機のアーキテクチャとかあんまり関係ないんだけど。

それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
このスレを読み返すと前提から大分抜け落ちているように見える。

ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
ことはできない。個人的にはマルチコアは好きではないが、
ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
0770デフォルトの名無しさん2008/10/04(土) 01:49:43
一方グーグルはマルチプロセスを使った（クロームで）
0771デフォルトの名無しさん2008/10/04(土) 01:57:42
> それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
> シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
仕方ないのはいいけど、マルチコアにした後にどうやって使うか回路屋
まったくノーアイデアでしょ。ソフト屋としてはめちゃくちゃケツ
ふかされている感がたっぷりなんですが...。

> CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
> このスレを読み返すと前提から大分抜け落ちているように見える。
こういう風に好意的(というか同情的？)に思うソフト屋は少ないんじゃないの？
だって勝手に回路屋がこれからはマルチコアの時代だよねっ！て勝手に言っているんだもん。
仕方なくやっているんだったら、もうちょっとネガティブな感じでアピールして欲しい。

> ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
> ことはできない。個人的にはマルチコアは好きではないが、
> ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
これは結局お互いさまという当たり前の話になるので、まあ言い分としては
理解できます。
0772デフォルトの名無しさん2008/10/04(土) 02:06:23
今までの時代がソフトウェア屋さんに優し過ぎたって事なんじゃないの
0773デフォルトの名無しさん2008/10/04(土) 02:12:01
優しかった時代なんてない
0774デフォルトの名無しさん2008/10/04(土) 02:16:27
布団で寝てても数ヶ月したらクロックが高いプロセッサが出てくるなんて
夢の様な時代だったじゃない。
0775デフォルトの名無しさん2008/10/04(土) 02:17:46
相対的にはこの15年くらいはそれ以前より優しかったと言える
でなけりゃJavaがメインストリームになることはなかったはず
0776デフォルトの名無しさん2008/10/04(土) 02:41:50
>>771
>回路屋
>まったくノーアイデアでしょ。

ノーアイディアっつー事も無いんじゃない?

あまり詳しくないけど、、、
Intel >> TBB
Sun >> JSR166y, Fortress
IBM >> X10

サーバサイドなら仮想化とか Map/Reduce とかもあるし、
マルチプロセッサの歴史が長いから、そもそもスケールする
アプリも多いよ。
0777デフォルトの名無しさん2008/10/04(土) 03:47:55
PCIバスもバスマスタになるからメモリ書き込むよ
0778,,・´∀｀・,,）っ-○◎●2008/10/04(土) 03:57:30
Pentium 4で3GHz到達したくらいまでが天国だったろ？
0779デフォルトの名無しさん2008/10/04(土) 05:11:09
MapReduceはサーバーサイドじゃないけどね。
0780デフォルトの名無しさん2008/10/04(土) 07:42:59
>>765
> その状況の違いは本来不要だったんだよ

え゛っ、今更そんな言い訳ですか...。

だったら、RISC がどうのこうのとか言ってた奴はまんまバカじゃん。
まあ、実際バカだと思うけど。(w

て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
グルコアとの違いを書いただけで、常識的なことだから普通に流され
ると思っていたんだが...。
0781デフォルトの名無しさん2008/10/04(土) 11:49:44
>>780
今更って…>709でも同じように書いてるんだけど
言い訳とか後出し(>711)とか意味わかんないし
話が>689から始まったのを分かってないのか？

> て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
> グルコアとの違いを書いただけで

繰り返しになるが、マルチスレッドスレがシングルコアスレなら
それが違いになるが、そんなこたーないわけ
この話続けてもかみ合いそうもないから俺はもう逃げるよ
0782デフォルトの名無しさん2008/10/04(土) 15:34:42
この板の連中もたいしたことねーな
0783デフォルトの名無しさん2008/10/04(土) 15:39:07
>>779
わざわざ説明しなくても良いと思ったんだけど、必要だった?
0784デフォルトの名無しさん2008/10/04(土) 16:18:04
なんか不思議だよね。CPUのクロックは別にまだ上げられるだろ。
消費電力考えたら、マルチコアにいくのがいいよね〜っていうだけで。

で、マルチコアのプログラム支援が言語レベルであれば理想的だが、
なくてもそこそこやれる（やれてる）でしょ？コア数が100とか
1000とかになってくると、言語レベルの支援がないと厳しく
なってくるかもしれんが。

何がいいたいか、自分でもわからｎ
0785デフォルトの名無しさん2008/10/04(土) 16:53:06
あげられないからマルチコアになったんだよ。
0786デフォルトの名無しさん2008/10/04(土) 17:39:15
クロックは上げられるけど、投資対効果が期待出来るスピードで
クロックを上げ続けるのは無理。それより余ったトランジスタで
コアを増やした方が取り敢えず嬉しい。
0787デフォルトの名無しさん2008/10/04(土) 17:49:33
マルチコアの方が使っててスカスカに軽く感じるじゃん？
当面はそれでいいんじゃないかと思う。

で、ユーザーがマルチコアの潜在能力を活かしてプログラム
全体の速度を上げられないかと言い出したらそういうプログラム
を作ればいいが、そうするとシングルコアと同じく多数のプログラム
は同時に動かしにくくなる。
0788デフォルトの名無しさん2008/10/04(土) 18:35:45
どうせみんな8つくらい同時にプログラム動かすよね。
じゃあ、クライアントアプリなら、なんも考えなくてもいいんじゃないか
0789デフォルトの名無しさん2008/10/04(土) 18:42:25
8つくらい立ち上げてても、ほとんどのプログラムは待機状態だと思う
0790>>7802008/10/04(土) 18:46:34
>>781
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>692 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>709 比較なんかしてないぞ

「違う」と書きながら、指摘されたら「比較してない」って言い張るわけですね。
比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

まあ、「逃げる」とか書いてるぐらいだから、流石にもうでてこないだろう。
普通に考えても、恥ずかしくて出てこれないと思うけど。(w
0791デフォルトの名無しさん2008/10/04(土) 19:18:44
>>790
>692と>709は別人ね。
0792デフォルトの名無しさん2008/10/04(土) 19:54:15
マルチコアに対応と言っても並列化したいのはほんの一部分だし、
スレッドプールとタスクキューを作れば何とかなりそうな気が…
0793デフォルトの名無しさん2008/10/04(土) 20:00:29
つまり「ミニOS」みたいな構造にしてCPUにさせる仕事を細かく分解し
やらせる仕事は片っ端からキューに叩き込んで行き仕事を終えたコア
が次の仕事を取りに来る、とか
0794デフォルトの名無しさん2008/10/04(土) 20:13:07
並列化したい部分なんてのは単純に並列化すればいいだけで何の問題もなく、
特に並列化したいわけでもない普通の部分をいかに並列化してパフォーマンスアップに繋げようかってのが難しいんじゃない？
0795デフォルトの名無しさん2008/10/04(土) 20:40:47
>>790
>>692の中のアンカー読めるか？>>692は>>689へのレスだぞ
そして>>709の名前欄読めるか？>>709は>>689だぞ
>>692と>>689=709は別人、流れはこうだろう

>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

比較して違うと言ったのは>>692
比較してないと言ったのは>>689

> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。

謎なのはお前の読解力だw
0796デフォルトの名無しさん2008/10/04(土) 20:50:19
長文ウゼ(´Α｀)
0797デフォルトの名無しさん2008/10/04(土) 20:50:26
よくしらんがコンカレントCとかadaとかか？
0798>>7802008/10/04(土) 21:11:32
>>795
まあレス番素直に読めばそうだな。

そうすると、>>708 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w
0799>>7802008/10/04(土) 21:13:34
すまん、レス番間違えた。

そうすると、>>709 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w
0800,,・´∀｀・,,）っ-○◎●2008/10/04(土) 21:34:04
>>784
パイプラインを細分化してもレイテンシが大きくなりすぎて効率が上がらないし
配線間隔が狭くなりすぎてリーク電流を抑えるのに神経使う時代が到来した今
シングルコアでクロックをひたすら上げるアプローチなんてどこもやらないよ。
強いて言えばPOWER6くらいか。

5年で5〜10倍なんてペースで進化する時代はもう終わった。

コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
一番有効な手段だったりする。
0801デフォルトの名無しさん2008/10/04(土) 21:37:24
>>799
> そうすると、>>709 は話の流れに関係なく唐突に

もう一回書くぞw

>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ

AがBに「比較するな」と言い、BがそれはCに言えと言い、
それでCが「比較してない」ってのは「話の流れに関係なく」でも
「唐突に」でもないだろ

>>709=689 (俺は)比較なんかしてないぞ

の方がよかったかもしれんけどな
突っ込むなら比較して違うと書いたくせにCに振ったB(>>708=692)だろ
0802>>7802008/10/04(土) 22:23:09
だったら、おまえら二人で相談でも何でもして解決してくれよ。

俺は、>>692 に「比較するのはおかしい」と指摘しただけで、
お前ら二人が別人かどうかなんてわからんのだし。
0803デフォルトの名無しさん2008/10/04(土) 22:48:07
>>802
> お前ら二人が別人かどうかなんてわからんのだし。

誤読しといて開き直るなよw
0804デフォルトの名無しさん2008/10/05(日) 00:01:55
ここ住人は行った人結構いそうだな
ttp://d.hatena.ne.jp/potasiumch/20080827#1219824560
0805デフォルトの名無しさん2008/10/05(日) 00:59:13
＞一般企業での並列化は遅々として進んでいない。某 Ad○be 社に
＞並列化コンサルティングに行ったところ、「○○処理の部分はプログラマが
＞だいぶ前に死んだのでそれ以降誰も触っていない・触れない」「え、リコンパイル？　
＞そんなことしたらもう動かなくなったりしないかなあ」などと言われた。

＞（だからあの会社の製品はあんなに重いのだろうか？）

ワロタと同時にゾッとした
0806デフォルトの名無しさん2008/10/05(日) 01:03:11
シングルコアとクロック数の話で　「周波数と消費電力が2乗の関係」
ということが論じられていない件について
0807デフォルトの名無しさん2008/10/05(日) 01:05:48
ああ、CPUなんて1Hzでいいよ
0808デフォルトの名無しさん2008/10/05(日) 01:07:59
>>806
fは1乗

CMOSデジタル回路の消費電力

P = Na×C×V^2×f + Nt×Il×V

P:消費電力
Na:動作ノード数
Nt:全ノード数
C:ノード容量
V:電源電圧
f:周波数
Il:ノード当たりのリーク電流
0809,,・´∀｀・,,）っ-○◎●2008/10/05(日) 01:33:10
>>806
同じアーキテクチャで同一電圧での話なら2乗だけど
ある程度以上はクロックを上げるのに電圧盛らないといけないので3乗になるんじゃなかったっけ
0810デフォルトの名無しさん2008/10/05(日) 01:57:03
>>806
ここはソフトウェアの板だから、そっち方面の話題の需要は無いと思われ
0811デフォルトの名無しさん2008/10/05(日) 02:22:54
ソフトオンリーの人がハードを含む話をすると悲惨たからな。
>>50->>57あたりにソフトウエアの板のマルチコアCPUに対する理解度があらわれているよ。
0812デフォルトの名無しさん2008/10/05(日) 02:24:48
ソフトウエア板住人の
0813デフォルトの名無しさん2008/10/05(日) 03:28:52
生活に直結していないから不要な知識なんじゃないの。
多分 >>803 みたいな話がむしろ当然な世界でしょ。
食い扶持に影響する様になったらガッと動くけど、
手を抜ける所は手を抜くのも仕事では重要だし、
コア数が一桁のうちは今のままでも困らないかと。
秘伝のソースを書き換えたりアーキテクチャを一から
変更したりするとテストだ互換性だと色々面倒だし。
0814デフォルトの名無しさん2008/10/05(日) 03:30:01
ｽﾏｿ。レス番間違えた。

×　>>803
◎　>>805
0815デフォルトの名無しさん2008/10/05(日) 04:24:03
レンダラーとかゲームの思考エンジンとか、並列処理に向いてるソフトウェアでも
売り物じゃないオープンソースのは並列化されていない事が殆どだね。やっぱり
一手間加えるのがマンドクサイのかな。
0816デフォルトの名無しさん2008/10/05(日) 04:44:56
>>800

> コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
> 一番有効な手段だったりする。

いやだから、そんなことは当たり前であって。2個とか4個とかなら、その
CPUをフルに活用するようなプログラム作れるかもしれないが。

100個とか1000個とかになったときには言語レベルで支援がないと
きつくなるのじゃないかな？っていう話。まぁ100個とかになる前に、
バスネックになると思うが。
0817デフォルトの名無しさん2008/10/05(日) 05:05:58
100 CPU 越えのマシンは既にあるよ。
1 socket で 64 並列の CPU もあるし。
0818>>7802008/10/05(日) 10:06:49
>>803
おまえらが別人かどうかもわからんのに誤読とか言われても知らんがな。
にちゃん初心者か？
0819デフォルトの名無しさん2008/10/05(日) 11:26:23
>>816
なるほろ
確かに、これから先コア数がガンガン増えていったとして
デクストップアプリケーション、例えばExcelなんかが
その性能に比例して進化していけるのか
今までのアプローチでそれが可能なのか
不安が残るな
0820デフォルトの名無しさん2008/10/05(日) 16:06:29
今のスペックでそこそこ動いているものを挙げたって仕方ないだろ。
コア数が増えるならそれに適応したシステムになるのは当然。
コア数が増えて初めて恩恵を得るようなものを作っていかないといけない。
0821デフォルトの名無しさん2008/10/05(日) 17:31:58
マシンがすでにあることなど関係ない
0822デフォルトの名無しさん2008/10/05(日) 17:33:14
>>811
どうみてもまじめにつっこむとことちゃうだろ
0823デフォルトの名無しさん2008/10/05(日) 18:08:55
>>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
0824デフォルトの名無しさん2008/10/05(日) 18:17:26
オマイ等そろそろ他所でやれよな。
2ch だからって何書いても良いという訳じゃないんだぜ。
0825デフォルトの名無しさん2008/10/05(日) 18:50:17
ああそろそろ規制議論板に報告して芋掘りしてもらう頃合いだな
0826>>7802008/10/05(日) 21:00:25
>>823
> 別人ってわかるだろうが

そもそもお前が誰かもわからんのに、何を言ってるんだろうこの人。(w
0827デフォルトの名無しさん2008/10/05(日) 21:47:07
>>826
そうだね、君の読解力じゃ無理だよねw
笑えるよなぁ、コテハン付けて勝利宣言(>790)のつもりが墓穴だもんなwww
そのコテハンそろそろ捨てた方がいいんじゃないの？他の人に迷惑だしさ
普通に考えても、恥ずかしくて出てこれないと思うけど。(w
0828デフォルトの名無しさん2008/10/05(日) 22:09:02
私のために争うのはやめて！
てのはさておき、いい加減にしたらどうなんだ。

元の話でいえば、シングルコアのCPU上のマルチスレッドプログラム
が、マルチコアのCPU上で動作しなくなることなんて、バグじゃなく
ても当然ありうる。タイムスライス限定とかいうなよ？自分の
知ってる範囲だけがマルチスレッドじゃないのだから。

優先度に基づいたマルチスレッドもあるし、そういう環境で無駄な
排他を排除することは当然ありうる。マルチスレッドじゃないが、
割り込み禁止で排他する場合も、マルチコアじゃぁ別のCPUで
割り込みハンドラが動くこともある。
0829デフォルトの名無しさん2008/10/05(日) 22:13:16
最初からシングルコアっていうかその環境専用に作ってるならバグじゃないし
マルチコアは想定外と最初から言ってないなら普通はバグと判断される
それだけのこと
0830デフォルトの名無しさん2008/10/05(日) 22:19:23
>>829
何をいいたいのかわからんが。そのプログラムがどんな
システム向けに作られたかしだいでしょ。最初から
「マルチコアを想定して作ることを求められたプログラム」
ならバグであるし、そうでないならバグではない。

30年前のシングルコアしかなかった時代のプログラム
は全部バグっているというのかい？
0831デフォルトの名無しさん2008/10/05(日) 22:19:45
折角の週末を無駄にして、君たちは一体何と戦っているんだい？
0832デフォルトの名無しさん2008/10/05(日) 22:33:00
>>830
俺は>829に同意。
デフォでマルチプロセッサをサポートしてるのが当然な環境が今は多い。
PCでもWindowsNTWSは最初から2プロセッサをサポートしてたよな。
動作環境にNTが含まれていたら、対象外と明示していない限り、
マルチプロセッサ／マルチコアで動かなければそれはバグ。
前提の環境がマルチプロセッサを含まないことが明白な場合は別。
0833デフォルトの名無しさん2008/10/05(日) 22:39:15
>>832
だから、なんのプログラムに対してバグっているといっているのだ？
仮にあなたが発注元で要求仕様に「マルチコアでも動作すること」
という条件を含めていなかったら、それはバグではなくて仕様。

その変のフリーでころがってるプログラムがマルチコアで動作しな
いとしたら、それは＊あなたが＊バグであるかどうかを判断する
立場にはないよ。作者がマルチコアに対応するつもりでプログラム
作っているなら＊作者＊はバグであるというかもしれないし、
シングルコアのみに対応するつもりなら、＊作者＊は仕様だと
いうだろう。

前提が不明なのだよ。
0834デフォルトの名無しさん2008/10/05(日) 22:52:05
それはない。逆。
このソフトはマルチコア環境では動作しません。
とうたっていない限り、バグ。
0835デフォルトの名無しさん2008/10/05(日) 22:55:17
>>833
仮に動作環境がWindows2000やXPだったら、「マルチコアで動作しない」
と書いてない限り、動かなかったらバグだよ。
OSがサポートしている環境ではマルチコアもその範囲内だから。
それは明白だよ。不明じゃない。
はっきり書いてない場合にマルチコアで動いて当然の環境があるんだよ。
作者がマルチコアを想定してなくて動かなかったなら、コードを直すか
ドキュメントの動作環境を直すかのどちらかは必要だろう。
つまりコードのバグか、ドキュメントのバグかのどちらかになる。
0836デフォルトの名無しさん2008/10/05(日) 22:58:00
極端な話、3GHz以上のCPUでは動きませんと明記していないかぎり、
3.2GHzだろうが5GHzだろうが暗黙の了解でソフトは動いて当然。
動かなかったらバグだろ。それと同じだよ。
0837デフォルトの名無しさん2008/10/06(月) 01:31:30
特殊なソフトじゃない限り、「シングルコアのCPUじゃないと動きません」なんて、許されんな。
0838デフォルトの名無しさん2008/10/06(月) 02:40:38
『動く』と書いてあるのに動かないのはバグ。
書いてなくて動かないなら、動かなくてもおｋ
0839デフォルトの名無しさん2008/10/06(月) 02:51:16
『動かない』と書いてないのに動かないのはバグ。
書いてあって動かないなら、動かなくてもおｋ
0840デフォルトの名無しさん2008/10/06(月) 03:01:12
>>835
Windozeとか、べつにタイムスライスしかないのだから、ドライバで
ないかぎりマルチスレッドプログラムは、普通にマルチコアでも動く
だろ。何をいってるんだ？
0841デフォルトの名無しさん2008/10/06(月) 03:07:14
>>840
上のほう読んでよ。アトミック操作を適切に行っていないプログラムは、
マルチコアで動かないけどシングルコアでマルチスレッドなら動くって眉唾なこと言っている奴がいたんだ。
0842デフォルトの名無しさん2008/10/06(月) 03:56:07
>>838
そう思ってるのは開発側だけだな。
0843デフォルトの名無しさん2008/10/06(月) 04:13:35
そういや昔、マルチスレッドのプログラムがちゃんと動くかどうかテストするのに
マルチプロセッサのPC組み立てたっけ。
90MHzのPentiumでDaytonaだった。
0844は@携帯 ◆cplnFO9T0I 2008/10/06(月) 09:53:26
高速なCPUで動かないｿﾌﾄといったらWindows95だろ
たかだかK6-2の350MHzでｺｹるってどんだけだよと
0845デフォルトの名無しさん2008/10/06(月) 10:29:44
コア数が増えてoccam復権しねぇかなぁ
0846デフォルトの名無しさん2008/10/06(月) 11:09:06
>>843
マヌケだなｗ
0847デフォルトの名無しさん2008/10/06(月) 15:08:16
>>840-841
二人とも0点
0848デフォルトの名無しさん2008/10/06(月) 16:37:47
一般的なソフトウェア開発の観点では、プロセッサもしくはランタイム環境の、主にメモリモデルに起因する問題が多い
0849デフォルトの名無しさん2008/10/06(月) 21:15:49
>>864
理解できない時は素直に認めた方がいいぞ。
0850デフォルトの名無しさん2008/10/06(月) 21:22:16
スルーパス出ました
0851>>7802008/10/06(月) 22:02:03
>>827
>>826
0852デフォルトの名無しさん2008/10/19(日) 13:24:40
このスレ絶望的にレベルが低いですね。
0853デフォルトの名無しさん2008/10/19(日) 13:33:32
今日はそうみたいだな。
0854デフォルトの名無しさん2008/10/19(日) 13:36:45
ダンゴさんが最近発言していないからな
0855デフォルトの名無しさん2009/05/04(月) 01:48:25
ここ的にはMSのCCRは問題外ですか?
0856デフォルトの名無しさん2009/07/08(水) 00:46:28
LeopardでLAMMPIをコンパイルしたのですが正常に動きません。
なんでなん
0857デフォルトの名無しさん2009/07/11(土) 18:24:04
お前がバグだからだ
0858,,・´∀｀・,,）っ-○○○2009/07/29(水) 21:29:18
俺がバグだ
目標を駆逐する
0859デフォルトの名無しさん2009/08/08(土) 05:05:15
超初心者なんですけど、
quad coreで単純に４つのexeファイルを起動したとき
それぞれのプロセスが各CPUに割り振られて
シングルコアの４倍の速度になると考えて良いでしょうか？
08608592009/08/08(土) 05:11:28
exeファイルはシングルコアで動かすときのプログラムと全く同じで
何も変えずに4つ実行するということで。
要は、quadで動かすときに何か特別なプログラミングをしないといけないの？
ということなんですけど。
0861デフォルトの名無しさん2009/08/08(土) 05:32:36
cpuしか使わんプログラムなら4倍になる。
08628592009/08/08(土) 06:50:38
>>861
４倍にできない場合ってどういう場合なんでしょう？
0863デフォルトの名無しさん2009/08/08(土) 06:58:04
ディスクアクセスなど入出力が多い場合とか
0864デフォルトの名無しさん2009/08/08(土) 10:47:23
メモリアクセスとかにもよるだろ。
CPUのアーキテクチャにもよるだろが。
0865デフォルトの名無しさん2009/08/08(土) 11:08:40
演算性能上げるのに並列処理を抽出してプログラミングするには、
書く内容がかなり変わる。

シングル用に書かれたプログラムは、そのまま実行できる。

シングル用のプログラムの性能は、ほとんど同じ性能で走ることもあるが、
メモリバス性能など、ネックがある箇所によっては各々が1/4がそれ以下の性能しか
出ないこともある。
0866デフォルトの名無しさん2009/08/08(土) 12:35:56
例えば大量にメモリアクセスするようなら、メモリアクセスがボトルネックになって性能出なかったりするわな
0867デフォルトの名無しさん2009/08/08(土) 14:41:33
NUMAにしてローカルなメモリ意外触らない
0868デフォルトの名無しさん2009/08/08(土) 14:50:04
特別なプログラミングしてるじゃねーか
0869デフォルトの名無しさん2009/08/08(土) 15:21:07
だから4つコアで4つプログラム動かしたときって言ってるだろ。日本語が読めないのか？
0870デフォルトの名無しさん2009/08/08(土) 17:24:01
誰に言ってんの？
どれに言ってんの？
0871,,・´∀｀・,,）っ-○○○2009/08/11(火) 21:30:41
IKE NUMA
0872デフォルトの名無しさん2009/08/18(火) 02:37:09
メモリでボトルネックに成ってたらほとんどの処理は絶望的だな。
ディスクもネットももっと遅い。
0873デフォルトの名無しさん2009/08/28(金) 03:26:23
OpenMPとOpenCLとboost::threadとpthreadとWindows API threadの良し悪しを教えてくださいませんか？
0874デフォルトの名無しさん2009/08/28(金) 07:25:43
ほらyo
OpenMP×
OpenCL ×
boost::thread ○
Windows API thread ×
0875デフォルトの名無しさん2009/08/28(金) 08:35:57
CCRはネ申..._φ(ﾟ∀ﾟ )ｱﾋｬ
0876デフォルトの名無しさん2009/08/28(金) 14:19:14
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円
0877デフォルトの名無しさん2009/09/26(土) 17:47:17
シングルコアのPC上で動作させるwindowsのタイマーを複数使ったプログラミングを
マルチコアのPCで動作させても並列処理にはなりませんか？
何か特別なやり方とかしないといけないでしょうか？
0878デフォルトの名無しさん2009/09/26(土) 17:57:30
なるわけがなかろう
08798772009/09/26(土) 18:37:07
>>878
やっぱりそうですか。
もう根本的に無理ですか？
0880デフォルトの名無しさん2009/09/26(土) 18:37:25
シングルコアのPC上で動作させるwindowsのタイマーを使ったプログラム複数を
だったら。
0881デフォルトの名無しさん2009/09/26(土) 18:43:01
そもそも、そのタイマーの処理は、並列実行しても安全なようにコードを書いてあるのか？
08828772009/09/26(土) 18:51:50
>>880
やっぱり複数のアプリを立ち上げないとダメなんですね。
>>881
普通にタイマーを複数作っているだけで、
どう作れば並列実行に安全かもよく分かりません。
0883デフォルトの名無しさん2009/09/26(土) 19:13:07
まず、そもそも並列する意味があるかどうかをだな
08848772009/09/26(土) 19:15:26
>>883
意味ははあります。
とりあえず複数プログラム間でのプロセス通信はしてますが、
通信だといろいろ設定やらやり取りがややこしいので、
一つのアプリで並列動作させたいのです。
0885デフォルトの名無しさん2009/09/26(土) 19:40:26
「タイマとか関係なく、1プロセス内で平行処理させたければ、スレッド起こせ」という結論でFA
まあCreateWaitableTimer + RegisterWaitForSingleObjectのように勝手にそこまでやってくれるような組み合わせもあるけど。
0886デフォルトの名無しさん2009/09/26(土) 21:27:20
>>884
それってマルチスレッドにすれば解決するか、
マルチコアで並列にしても解決しないか、どっちかだろ。
0887デフォルトの名無しさん2009/09/26(土) 22:50:17
OpenMPを使えるか調べてみたら？
複雑な同期がいらない並列プログラムなら手軽でいいよ
0888デフォルトの名無しさん2009/09/27(日) 09:11:52
Interlocked周りを使ったパターンってあるもの？
いままであまり使ったこと無かった。
RWLockとかにもつかえそうなんだが。
0889デフォルトの名無しさん2009/09/27(日) 13:22:17
そりゃいくらでもある。
全ての同期の基本に近い。
0890デフォルトの名無しさん2009/09/27(日) 14:00:38
たとえば？
0891デフォルトの名無しさん2009/09/27(日) 17:47:01
ミューテックス・クリティカルセッションなどと呼ばれるもののの実装とか、
あとは、Lock-freeでググれば、キューとかリストの実装も見つかるだろう。
0892デフォルトの名無しさん2009/09/27(日) 23:46:17
その話題はマルチスレッドスレでやってる。
0893デフォルトの名無しさん2009/10/01(木) 01:35:47
マルチスレッドで書けば、マルチコア対応にも成るからなあ。
結局の所、マルチコアを使いこなすならマルチスレッドで書いとけもひとつの解だし。
0894デフォルトの名無しさん2009/10/01(木) 09:01:56
つーかマルチスレッドとマルチコアってわけんの？
おなじCPU上で動かす云々とかもあるけれどあまりそこまで意識しようとしてないわ-
0895デフォルトの名無しさん2009/10/01(木) 09:12:12
キャッシュのコヒーレンシの問題あるからなあ
共有メモリで互いのメモリ監視が多い場合、マルチコアのシステムだとかなりパフォーマンスが落ちるはず

互いにほとんどメモリ参照しないで走っている感じだとマルチコアのほうがHTTよりもパフォーマンスがいい可能性もある
0896デフォルトの名無しさん2009/10/01(木) 09:33:28
プログラムの種類にもよるだろうけどそこら辺を考慮した実装と市内ものでどれだけパフォーマンスに違いあるかみてみたい。
たいてい1割も違わないんじゃ？
0897デフォルトの名無しさん2009/10/01(木) 10:01:59
いやいや、並列化が本当に必用な領域では、キャッシュ
コヒーレンシ維持のためのオーバーヘッドや各スレッドの
連続する処理でアクセスするメモリのサイズについて真剣に
考慮しないと下手すると何倍もの差が出るのが通常だよ。
少なくとも俺の経験では。
0898デフォルトの名無しさん2009/10/01(木) 10:36:48
そもそも複数のスレッドでメモリ空間が重複してる時点で
並列化失敗してるんじゃないの？
0899デフォルトの名無しさん2009/10/01(木) 11:17:59
逆だ。キャッシュの効率を考えて、同じCPUで近いメモリ空間を使うように設計するんだ。
例えば行列演算の場合、2core*2cpuならCPU間では空間を離し、core間は近くする。
巧くすれば、対策前の2倍は充分有り得るね。
0900デフォルトの名無しさん2009/10/01(木) 17:15:23
>>899
fortran あたりは、よきに図らってくれたりしないのかな？
0901デフォルトの名無しさん2009/10/01(木) 17:38:57
そんなコンパイラスイッチ見た事無いな。
インテルのCPUが出る旅にバージョンアップが必要とか？
0902デフォルトの名無しさん2009/10/01(木) 17:52:09
>>901
すまん、スパコンとかそっち方面を考えてた
インテルの fortran って、自動並列化は結構賢いって聞いたことがあるが…
0903デフォルトの名無しさん2009/10/01(木) 18:00:28
>>899
core毎に隔離した方が良い
0904デフォルトの名無しさん2009/10/01(木) 18:12:06
>>903 CPU によっては L2 がコア間共用だったりすることもある
0905デフォルトの名無しさん2009/10/02(金) 01:00:47
まぁそこら辺はプログルマがごちゃごちゃやるよりコンパイラの中のエロイ人にやって欲しいものだ( ﾟДﾟ)y─┛~~
0906デフォルトの名無しさん2009/10/02(金) 05:22:47
するとプログラマの人件費が減らされて、メーカ謹製のコンパイラ代に変わる訳だが。

共用キャッシュでもいろいろ有るしなあ。プリフェッチ深いのとか。
クラウドコンピューティングとかごった煮環境じゃ最適化厳しいでしょ。
スレッドプログラミングで最大公約数的な所で落ち着くと思うけど。

今時のスパコンってたったの2コアだったりするの？
ALUとか実行ユニット積みまくれば速度は稼げるのかもしれないが。
0907デフォルトの名無しさん2009/10/02(金) 09:20:34
>906
いやその分プログルマは他の所に時間が割けるようになるでしょ？
自分で考えられる人工知能が出来ない限り要素の調停を行う場所がシフトするだけでプログラマの仕事は変わらないよ。
0908デフォルトの名無しさん2009/10/02(金) 10:45:19
>>906
> 今時のスパコンってたったの2コアだったりするの？
パッケージ内のコアって意味ならたいして多くない。数使ってなんぼの世界

NEC SX-9: スカラユニット x 1 + ベクトルパイプ x 8 で 1 CPU
シングルノードで4〜16CPU

つか、今時、専用プロセッサ使ってるの NEC 位じゃね
cray は opteron だし
IBM は Power6 とか CELL だし
日立は IBM 製品使うみたいだし
富士通は命令拡張したマルチコア sparc に行くみたいだし
0909デフォルトの名無しさん2009/10/02(金) 10:48:15
>>908
NECが専用使ってるのは国策？
0910デフォルトの名無しさん2009/10/02(金) 10:58:40
>>909
10 ペタマシンからおりちゃったし、違うんじゃないかな？
0911デフォルトの名無しさん2009/10/02(金) 16:10:04
Power5/6はデュアルコアだけどL2が共有だからHPCに使う場合は片方のコアつぶして
シングルコアとして使う
0912デフォルトの名無しさん2009/10/02(金) 16:39:55
>>911
Power6 は L2 分離だったはず。
調べようと思ったらいつの間にか有料にorz
http://www.research.ibm.com/journal/
0913デフォルトの名無しさん2009/10/02(金) 16:58:50
>>912
ｽﾏﾝｶｯﾀ
0914dJBfVQRhY2009/10/23(金) 00:29:36
Allowable Card Account Number Lengths Visa Card 16 digits. ,
0915デフォルトの名無しさん2009/11/15(日) 21:07:59
メニーコアとSMT対応ってどう違うんだ？
4コアCPUと2コア4スレッドCPUのパフォーマンスは同じにならんの？
0916デフォルトの名無しさん2009/11/15(日) 21:30:20
>>915
普通のアプリだとそこまで気にすることはないと思う。

OSのスケジューラなんかだと、今実行できるスレッドが2つのとき、
2コア4スレッドの環境なら、片方1つのコアで2スレッド実行させるより
2つのコアで1スレッドずつ実行させるほうが効率がよい、なんてことも気に掛けるみたいだけど。
0917デフォルトの名無しさん2009/11/15(日) 21:30:28
4コアは演算器の完全なセットが4つある
2コアは演算器が2セットぶんしかないが、もし空いてればそのぶんは別のスレッドも動かせる
例えば整数演算メインのスレッドと浮動小数点演算メインのスレッドがあれば、
お互いメインに使う演算器が違うから同時に動かせる率が高いけど、
整数演算のスレッドばっかりだと同時に動かせる率が低い
って感じじゃね
0918デフォルトの名無しさん2009/11/16(月) 14:49:52
HTはたまたま空いてるCPUの演算機を使って仮想的にもうひとつスレッドを動かす。
だから、仮想スレッドはせいぜい20〜30%までの性能が限度。
普通10〜20%とか、もっと低いくらい。
マルチコアとは全く違うよ。
0919デフォルトの名無しさん2009/11/17(火) 00:24:14
コンパイラの吐き出すコードの効率が高いほど
HTの効能下がるな。
0920デフォルトの名無しさん2009/11/17(火) 17:51:21
どういうオプション指定かにもよるので。
シングル用かデュアル用ならHTも悪くない。HT用が最良だけど。
0921デフォルトの名無しさん2009/11/17(火) 23:02:54
新しいサーバ買ってもらった。16コア。何に使おう
0922デフォルトの名無しさん2009/11/18(水) 10:02:47
梱包して発想の準備をしてから待っていてくれたまえ。
0923デフォルトの名無しさん2009/11/18(水) 10:53:44
窓からぶん投げる日を教えてくれ。
0924デフォルトの名無しさん2009/12/08(火) 10:37:35
パイプラインの長いコアだとHTは効率改善には効果的みたいだな。
１コア辺り８スレッドなんてのもある。
しかし、効率はいいんだろうが、スレッド視点で見たとき
期待通りにうまく動くんだろうか…
0925デフォルトの名無しさん2010/03/10(水) 12:53:29
(´・ω・｀)
0926デフォルトの名無しさん2010/03/11(木) 16:13:33
コンピュータサイエンス史上最大の課題「並列処理による性能向上」
〜情報処理学会創立50周年記念全国大会の招待講演
http://www.publickey.jp/blog/10/50.html
0927デフォルトの名無しさん2010/03/11(木) 19:19:37
>>926
その人の顔入りマグカップが送られてきた気がするが、即捨てたな。
0928デフォルトの名無しさん2010/03/12(金) 06:14:52
なんともったいない。どんな絵柄であろうとも、マグカップとしての機能には
何の問題もないというのに。
0929デフォルトの名無しさん2010/03/12(金) 06:25:51
>>926
高水準で問題領域を絞ったDSLが開発される方向を想定してるのか
つまり処理系にできるだけ多くの情報を与えて、最適化をがんばらせると

実用上は、処理系がうまくやってくれないケースもあり得る以上は
抽象を破って低水準をプログラマが直接操作できるメカニズムが必要だと思うんだけどな
かといって、低水準から高水準まで幅広くサポートしようとすると
C++みたいな化け物になりかねない……
0930デフォルトの名無しさん2010/03/12(金) 16:40:51
飲もうとする時に、その人の顔を見てしまう事で味が変化するとしたら損失だろう。
便所とかに置かれてるとかペット用になってるとかだとアレかもなw

プログラマが最適化出来るとも限らない訳で。
0931デフォルトの名無しさん2010/03/12(金) 19:11:03
>>930
カップの絵柄で中身の味は変化しない。
貴方の主張は非論理的すぎます。
0932デフォルトの名無しさん2010/03/12(金) 20:54:31
中身は変化しないが
味覚というのは脳が眼耳鼻舌身(触覚)意識を総動員して感じるものだから
見た目が変われば味が変わるということは非論理的なことでは決してない
0933デフォルトの名無しさん2010/03/12(金) 21:47:21
うんこ食ってるときにカレーの話なんかするなよ
0934デフォルトの名無しさん2010/03/13(土) 03:42:34
むしろ化学的な組成という客観量から味という主観的な概念が
一意に決まるという考えの方が非論理的

>>926
汎用言語を捨てるならいっそ汎用プロセッサも
諦めてしまえば…と思ったが、先祖帰りな気がするなあ
0935デフォルトの名無しさん2010/03/13(土) 04:30:13
そういやjavaプロセッサってもう無いのかな？
ibmの汎用機とかはjava処理用のプロセッサ積めるらしいが。

専用言語が実行速度的には有利だろうけど、習得に時間がかかるので、既存の汎用言語で最適化したほうが、まだ有効だろうね。
全世界を専用言語の英語に統一したほうがコンピューティング処理が向上するから、日本語処理を諦めようというのを日本語で公演する矛盾を感じる。
0936デフォルトの名無しさん2010/03/13(土) 06:26:58
Jazelleが使われているシーンを見たことが無い
いやどっかでは使われてたんだろうけど・・・
0937デフォルトの名無しさん2010/03/13(土) 06:31:22
C言語の呪縛
http://techon.nikkeibp.co.jp/article/TOPCOL/20091209/178442/

この記事を思い出した。
理想はともかく現実的にはこういうアプローチも必要なんだろうね。
0938デフォルトの名無しさん2010/03/13(土) 14:27:45
これからはErlangやScala、CCRのようなメッセージ伝達並列性が主流になる.
0939デフォルトの名無しさん2010/05/26(水) 17:20:01
WindowsおよびはUnixでC++を使ってプログラミングしています。
4コアのCPUを使っていて、1スレッドのプログラムを実行したとき、
タスクマネージャで見ると使うコアが次々と変わっていくのですが
これを抑止する方法はありませんか？
0940デフォルトの名無しさん2010/05/26(水) 17:53:41
Windows(Win32)ならsetThreadAffinityMask()
0941デフォルトの名無しさん2010/05/26(水) 17:55:29
便乗で質問させて下さい。
スケジューリングから外して、このコアはこのプロセス(スレッド)専用だからねっ！！ってできますか？
0942デフォルトの名無しさん2010/05/26(水) 19:20:17
そりゃ、無理だ。
DeviceDriverの挙動までは手が出せないからねぇ
0943デフォルトの名無しさん2010/05/26(水) 19:41:55
>>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
0944デフォルトの名無しさん2010/05/26(水) 22:17:14
>>943
うわーーー、知らなかった。
ありがとうございます。
Solarisなんて随分触ってなかったけど、ちょっとOpenSolarisでもいじってみます。
0945デフォルトの名無しさん2010/05/27(木) 15:18:38
OpenMPで各スレッドをそれぞれのコアに貼り付けるにはどうしたらいいのでしょうか？
Linux、g++です。
0946デフォルトの名無しさん2010/06/05(土) 06:47:40
http://pc12.2ch.net/test/read.cgi/tech/1102483474/
OpenMPプログラミング
0947デフォルトの名無しさん2010/11/21(日) 08:47:05
あげ
0948デフォルトの名無しさん2010/11/21(日) 10:52:53
Corei3なんですけどどうすればSSE2命令を並列に実行できますか？
0949デフォルトの名無しさん2010/11/21(日) 10:56:46
GPUに汎用計算させたほうが行列演算は高速になりますか？
0950デフォルトの名無しさん2010/11/26(金) 23:03:02
要はどうしたらいいんですか？
0951デフォルトの名無しさん2010/11/27(土) 02:17:48
何をしたい訳？
0952デフォルトの名無しさん2010/11/27(土) 02:35:33
それが判らないから聞いているんです。
0953デフォルトの名無しさん2010/11/27(土) 02:43:01
ヲレには心当たりが無い。残念だったな。
0954デフォルトの名無しさん2010/11/27(土) 15:58:50
まずは、パンツを脱ぐんだ
0955デフォルトの名無しさん2010/11/27(土) 16:24:34
既にノーパンで全部剃ってるけどな。舐めても安全。
0956デフォルトの名無しさん2010/12/19(日) 03:41:25
>>955
おいらの義妹はそんな下品なことは言わない。
0957デフォルトの名無しさん2011/01/24(月) 16:01:47
マルチコアってマルチスレッドで効果があるみたいだけど
マルチプロセスだとどうなの？
windowsとかのバックグラウンドプロセスにも効果でてる？
0958デフォルトの名無しさん2011/01/24(月) 18:19:30
>>957
M$のOSはしらんが、make -j<N> とかやるとちゃんと効いてるわな <Unix系OS
0959デフォルトの名無しさん2011/01/24(月) 22:40:02
>>957
Windows のマルチプロセスは組みにくい。fork() にあたるものがない。
逆に、p-thread って誰得？と時々思う。
09609572011/01/27(木) 03:21:14
つまりですよ、マルチコアを意識して
マルチスレッドプログラミングをわざわざ書かなくても

常に他のプロセスにコアが割り当てられているから
アプリ側はふつうにシングルスレッドプログラムで
作れば十分なんじゃないかなーと思って聞いてみたわけです
0961デフォルトの名無しさん2011/01/27(木) 03:59:01
十分かどうかは処理の内容によるでしょ。
スレッドの切り替えよりプロセスの切り替えの方がコストが掛かるし、
データの受け渡しも大掛かりになる。

ピクセル単位の画像処理なんかはスレッドを使うのが普通だろうし、
ウェブサーバとかなら I/O 待ちの時間が多いからマルチプロセスでも
良いんじゃねとか、そんな感じ。
0962デフォルトの名無しさん2011/01/27(木) 06:35:58
不足すればHWを買い換えるなりすればいいから、好きな方で実装すればいい
0963デフォルトの名無しさん2011/02/04(金) 02:10:38
マルチコアになったら関数型言語が主流になりますか？
でも、マルチコアにしてまで計算能力を向上させる意味ってあるんですか？
マルチコアになることのメリットが良く分かりません。
例えば、携帯電話とか、マルチコアになって何か凄いことができるようになったり
しますか？
0964デフォルトの名無しさん2011/02/04(金) 02:42:36
>>963
>マルチコアになったら関数型言語が主流になりますか？

ならない。副作用が無いと並列度を抽出し易いとかは、絵に描いた餅。

>でも、マルチコアにしてまで計算能力を向上させる意味ってあるんですか？

あるよ。計算能力が上がれば今まで無かった様なプログラムが作れる様になったり、
プログラマが楽出来たりする。

>マルチコアになることのメリットが良く分かりません。

クロックを上げる方向の性能向上が頭打ちになったからマルチコアになったのであって、
シングルコアで性能が出せるならシングルコアの方が良かった。

>例えば、携帯電話とか、マルチコアになって何か凄いことができるようになったり
>しますか？

デュアルコアになると、レスポンスが向上したり、バックグラウンドでプロセスを動かし
続けたり出来て、分かり易い恩恵があるよ。マルチコアと言っても、携帯ならデュアルで
十分で、クアッドとかは要らないだろうね。
0965デフォルトの名無しさん2011/02/04(金) 09:46:23
>>964
なるほど。
マルチコアの時代でもC++やJavaが主流のままなのでしょうか？
0966デフォルトの名無しさん2011/02/04(金) 10:40:14
HPCの世界はもう既にマルチコアの時代だけど、C/C++ばかりだねぇ。
0967デフォルトの名無しさん2011/02/04(金) 10:54:24
>>966
速さを重視する分野でC/C++を使うのは分かるんですが、生産性と両立させなければ
ならないような分野ではどうなんでしょうか？スレッド管理を手動で行う言語では、
大規模開発ではバグを誘発するような気がします
0968デフォルトの名無しさん2011/02/04(金) 10:56:56
問題は、C/C++以外の言語をHPC用にチューンするコストを誰が掛けるかだな。
0969デフォルトの名無しさん2011/02/05(土) 00:02:49
一応 Intel の TBB とかもあるけど、広範に受け入れられているかというとどうなんだろうね。
0970デフォルトの名無しさん2011/02/05(土) 00:14:14
あ、C/C++ 以外の言語か。HPC は特殊な世界だから、カリカリにチューニング出来る
C や C++ が当分はのして行くと思うけどな。CPU 使用時間単位で課金されたら、
誰でもそうすると思われ。
0971デフォルトの名無しさん2011/02/19(土) 17:07:21
行列の計算ですが高速化する方法ありますか？
for(j=0;j<16;j++){
o=FG[a[j]]^FG[u1.m[j]];
p=FG[b[j]]^FG[u.m[j]];

for(i=0;i<16;i++){
d1[j]^=t[o][h1[p][i]];
d2[j]^=t[o][h2[p][i]];
}
buf[j]=d1[j];
buf[j+16]=d2[j];
}
0972デフォルトの名無しさん2011/02/19(土) 17:08:40
なるほど。まずは質問を投機的にマルチスレッド化したわけですね。
0973デフォルトの名無しさん2011/02/19(土) 17:34:16
ワロタw
0974デフォルトの名無しさん2011/02/19(土) 17:38:29
ダメだこりゃ。
0975デフォルトの名無しさん2011/02/19(土) 19:38:09
>>971
フォートランで書くといいと思うよ
0976デフォルトの名無しさん2011/02/19(土) 19:43:08.14
根拠は？
0977デフォルトの名無しさん2011/02/19(土) 20:04:11.60
並列構文使えば勝手に並列化してくれる
0978デフォルトの名無しさん2011/02/19(土) 22:04:24.31
それが最適化されてるか検証が面倒。

hpc用にcで最適化するってのもなんだかなあと思う。
そこまでして性能出さないと予算取りにくいほど不景気なんだろうけど。
電気自動車の性能を上げる為にマイコン積まずにフルマニュアル化しましたみたいなもので。
0979デフォルトの名無しさん2011/02/20(日) 01:06:10.88
違うな。要求性能が決まっているとしたら、pc100台要るところを1%高速化すれば1台減らせるんだよ。
1台じゃ高が知れているけど、それが10%で10台となればそれを達成するための人件費を設備費が上回ってくる。
0980デフォルトの名無しさん2011/02/20(日) 10:18:56.57
でもその為に本来の研究者の利用者がc覚えたり最適化手法を覚えたりって、研究が停滞するだけだと思うけど。
まあ実際は助手とかに丸投げして助手がhpc使いこなすのに膨大な労力と時間を浪費してるだけだとは思うが。
0981デフォルトの名無しさん2011/02/20(日) 10:37:52.88
んなもん、研究者が書いたものをSIerに高速化させるんだよ。
研究者が直接最終版までコーディングするなんてどんな低予算研究なんだ?
0982デフォルトの名無しさん2011/02/21(月) 07:48:34.87
>>981
論文読むなりして、研究者が書いたものを高速化できるほど、頭のいい人間を
抱えているSIerは稀にしかない
0983デフォルトの名無しさん2011/02/21(月) 10:52:41.29
SIerって土方の集まりだろ
0984デフォルトの名無しさん2011/02/21(月) 19:55:31.10
歳三?
0985デフォルトの名無しさん2011/02/21(月) 20:47:49.72
SIerは土方を丸投げするだけだから、知識はさらにない。
逆に今日びコードの書けない研究者はいらない子。
0986デフォルトの名無しさん2011/02/21(月) 21:00:12.24
歳三?
0987デフォルトの名無しさん2011/02/21(月) 21:04:16.14
肘肩腰。神速三段腹
レス数が950を超えています。1000を超えると書き込みができなくなります。