- 1 名前:デフォルトの名無しさん [2006/01/18(水) 08:31:11 ]
- 最近のCPUはマルチコアが技術トレンドになっています。
それに伴い、ソフトウェアは並列化というパラダイムシフトが 求められています。効率のよく並列化を実現するためにはアル ゴリズムやデータ構造といった部分を根本から見直す必要が あります。しかし、トレンドができてからあまり時間が経って ないため、そいういったノウハウが蓄積されていません。 そこで、マルチコアを生かすためのソフトウェア設計というのは どういうものか?という議論をするためのスレッドを立てました。 ソフトウェアの並列化に対して考えのある人や、インターネット 上のリソース、論文等があればどんどん書き込んだりリンクを 貼ってください。 【関連スレ】 OpenMPプログラミング pc8.2ch.net/test/read.cgi/tech/1102483474/l50
- 85 名前:デフォルトの名無しさん mailto:sage [2006/01/22(日) 23:31:53 ]
- >>84
> 2コアぐらいなら、OSとアプリケーションでおおまか > にひとつづつ使い切るような感じで、 流石にお馬鹿の Windows でも、そんなにOSのオーバー ヘッドはでかくない。シングルスレッドプログラムではマル チコア/マルチプロセサの恩恵はほぼないので、 > 負荷がかかってるのにも関わらずアイドル状態のコアが > 出てきちゃいそう。 と言うのは、2コアでも十分ある。
- 86 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 00:49:24 ]
- >>85
自作板を見てると、DualはWindowsの体感速度が上がるからっていう理由で 買ってる人が多いみたいなんだよね。IEやエクスプローラを含めたOS全般と 自分の使ってるアプリケーションの両方が同時にスムーズに動くと。 だけど、そういう人たちでもさすがに4個や8個もの多コアは買わないだろうな という気がした。
- 87 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 00:52:06 ]
- >>83
そういうやつが周りに一杯いるけどそういう奴は蹴落としていくしかないと思う。 なんとなく小泉総理が親友を作らず孤独な少年であったというのが分かる気がする
- 88 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 01:15:57 ]
- 淘汰されるなら淘汰されるで歓迎
- 89 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 02:47:28 ]
- >>85
常に一個位アイドルなCPUが居るのって結構重要だったりする。 エンコやら異常事態やらで地獄の様に重い時でもUIの応答が軽いのはストレスを生まない。
- 90 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 06:14:19 ]
- それはnice値変えるだけでもいいような
- 91 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 07:30:41 ]
- それはniceなアイディアだ
- 92 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 08:55:09 ]
- アンチってなんなの?
マルチスレッドプログラムがかけない人なの? シングルコアの性能をもっとあげる方法を発明できる人なの? アンチとして存在してる意味がワカラネ
- 93 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 09:40:16 ]
- >>92
今まで普通にプログラムを作ってきたプログラマー達だね。 彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。 おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち >>63の言うとおりにガベージコレクションの性能が上がったとしたらそれだけで彼らは失職の危機にさらされる。 まあ、主にゲームプログラマーだけどね。 実際ゲームはシングルスレッド信仰がすごい強い分野だと思う。 ただ、滑稽なのはゲームなんてクリエイティブな分野でそんなに技術屋さんがでしゃばっていること。 本当はマルチコアでどんな新しいゲームが作れるかを考えるべきなのにそれを邪魔するだけの典型的な既得権益者なので 外野としてはそんな害虫どもにはさっさと消えてもらうことを祈るだけだね
- 94 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 12:54:33 ]
- >彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
>おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち それで困るのは半端な連中だけだ きっちっとした技術を積み上げてきたヤシなら、それほど恐怖でもない むしろ他の連中と差をつけるチャンスだ罠
- 95 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 13:25:29 ]
- >>93
ガベコレの性能とゲームプログラマの失職に何の関係がある? あと、ゲームのどの変の処理にマルチスレッドを導入するべきだと思う?
- 96 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 14:51:31 ]
- >>95
GCの性能が上がったら高級言語でもそこそこゲームが作れるようになるじゃないか。 ベンチマークではC++と関数型なんてほとんど変わらないしな。 そうなるとある程度ライブラリとかフレームワーク作ったり業務系と同じようになってくるんじゃないかな? 単純にシングルコアの性能だけでも相当向上してるのだからそうやってやり方が変わって脱落者が出るのでは?。 どんなゲームがいいかは例えばRTSのようなゲームで個々のユニットを複雑なアルゴリズムで動かすとかはどうだ?
- 97 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 15:35:46 ]
- D言語の時代クルー?
- 98 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 15:56:06 ]
- DってGC性能が低いんだったっけ?
それ以前に仕様がまだ固定化されてないのが気になるが それとDはスレッドの機能が初期のJavaベースで非常に少ない気がするんだが 今後マルチスレッドプログラミングが増えればこのへんとかネックになってくるかもね ま、必要になってくれば標準APIとして実装されるとは思うけど 今後スレッドが言語に組み込まれてない環境は厳しくなるよね
- 99 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 16:43:54 ]
- >>96
処理速度の向上によって今までC/C++でしかできない・C/C++が望ましかったような ゲームが、Javaや関数型言語でも実装できるようになるだろう、という予測? それともイチから実装する難易度が超絶的に上がり、結果必然的に高レベルなライブラリが 整備されるので、高級言語だけでもなんでもできるようになるだろうという話? 後者は理解できるけど、前者は疑問なような気がする。 生産性の向上によって確保した知的資源は、更なる難問の解決に使われるのが普通だから。 (そうじゃないと低賃金労働でしか生き残れない)
- 100 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 19:08:23 ]
- 豪華なマシンになってPGが楽になる・・・なんてことはなく、
実際は性能を限界まで出しきることを期待されてひどい目に遭うだけ。
- 101 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 19:23:38 ]
- >>100
ゲーム業界だとSFC,PS,PS2の時に聞かされた、PS2はまぁ期待にそえんでもなかったが。
- 102 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:29:20 ]
- ゲームってシングルスレッド信仰というより、わざわざマルチスレッドで
コンテキストスイッチするメリットがあまりないだけじゃないだろうか。 負荷もでかいし同期が必要なものは余計やりにくい。
- 103 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:34:00 ]
- むしろ並列演算言語が欲しい所だな
つ〜か、マルチスレッドである必要は全く無いんだよ 並列演算が可能なら、シングルスレッドでもかまわない その意味では、昔はMMXに期待したわけだが・・・
- 104 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:39:09 ]
- >>99
どっちかというと前者かな?Javaや関数型がそのまま使われるかは知らないけどPS3でオープンソースな人たちが勝手に実験始めるでしょ 低賃金労働から逃れるためにはライブラリ屋になるのが自然。ライブラリ屋が儲かるか知らんけど。 後者は手動での最適化するのが本当にできるのか疑問視していて、並列化言語を実用化させたほうが早いと思ってる。
- 105 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:40:22 ]
- マルチスレッドによる並列性の引き合いにMMXによる並列性
を出すのはどうかと思う。
- 106 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:40:59 ]
- >>103
バス幅とバスクロックの壁は厚かった
- 107 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:46:54 ]
- >>105
下手にマルチスレッドを使うよりは、並列演算を行った方が処理が早くなると思わないか?
- 108 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:49:21 ]
- 10個のコアがあるのなら、10個別々に処理するよりも、
同時に同一処理を行わせるのもアリだと思うんだよな。
- 109 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:50:41 ]
- >>104
するってえと高賃金乙な国内の業者さんたちは結局ライブラリだの物理モデルだの 並列処理向き言語+プラットフォーム開発だの、GCがどうとかいうレベルではなく難しい ことをやらざるを得なくなって、「余った知的リソース⇒難しい仕事」という流れになるような・・・ 成功しないのでそういう流れにはならない、という可能性も高いけど。 数学はインド人の方が得意そうだし。
- 110 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:51:37 ]
- >>107
いやだから用途が違うと思うんだけど。MMXつかって速くなるところに マルチスレッド使っても速くなるようなケースは限られると思うが。 (逆もまた然り)
- 111 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:56:48 ]
- >>110
コアがたくさんあったとしても、一つのスレッドの扱えるコアは一つ?
- 112 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:00:41 ]
- >>111
話の流れがわからん
- 113 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:01:05 ]
- >>103
NeoMagic の MiMagic6 なんかがその路線で、16x16ピクセルの画像を 対象とした演算なんかを1命令でできる演算ユニットを積んでます。 中〜大規模SIMDってのも、応用範囲は限られるものの確かに面白い。 けれどもクロック上げて水で冷やしてガンガンパワー使えるなら不要な 手法なのかなという気もしないでもない・・・ 小さいモノの中ではダイナミック・リコンフィギュアラブルLSIとかが そういう思想のもののような気がするけど違うかもしれない。
- 114 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:06:50 ]
- >>112
つまり、10個のコアがある場合に10個演算する場合は、10個スレッドを立ち上げて、 10個同時に演算して、演算が終われば元のスレッドに戻せば、10倍の速度で演算できるのでは? って事。
- 115 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:14:20 ]
- >>114
しかしバス幅とバスクロックの壁は、非情なまでにも分厚かった
- 116 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:15:56 ]
- >>114
それふつうにマルチコアの利点 今後はどの点が並列処理できるかという設計レベルの重要性がますわけだ 今まではそのCPUにあわせてどうすれば少ない時間で処理できるかの最適化をする という点だったからね JavaのコンカレントAPIみたいなのが普及せんときついかもね
- 117 名前:デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:19:09 ]
- >>114
俺が言いたいのは、SIMDは局所的な並列で、マルチスレッドはもっと大域的ってこと。 MMXは隣接ピクセル間の並列性、マルチスレッドはブロックごとに区切るような (マルチレンダリング)用途でしょう。俺なら同時に使うけどね。どっちかが 肩代わりするもんじゃない。
- 118 名前:デフォルトの名無しさん [2006/01/23(月) 22:54:48 ]
- 関連スレ追加
pc8.2ch.net/test/read.cgi/tech/1099819556/
- 119 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 01:34:42 ]
- >>117
スレッドのというか処理の粒度の問題って解くべき問題との関係が深すぎるからこのスレのタイトルだと混乱するかもしれない。
- 120 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 02:24:55 ]
- スレッドとマルチコアは何の関係もないだろ。
- 121 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 03:39:30 ]
- マルチプロセッサ(SMT含)を想定してのマルチスレッドプログラミングと全く同じだもんな。
プロセッサ間の通信速度や、外部(メモリ)との通信速度が違う、というだけで。
- 122 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 04:37:07 ]
- >>109
つまり技術的にはインドに負けることが前提なわけですな。
- 123 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 11:46:28 ]
- マルチコアのマルチスレッドって、通常のマルチプロセッサに比べて
注意するところあんの? ハイパースレッドプロセッサだったら スピンロック問題とか言うのがあった気はするけど。
- 124 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 12:57:29 ]
- >>86
自作板のあれは、多くの場合、負け惜しみです。 体感速度が云々と言ってる人達は、遅いCPUをdualにしています。 本当にCPU速度が必要な人達は、 マルチスレッドで動くアプリを使っていて、 ユーザの操作のためにCPUが丸々1個アイドルで待機しているのでレスポンスが良い なんてことにはならないのです。
- 125 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 12:59:39 ]
- >>102
ゲームはCPUを他のスレッドに譲るという概念がないから。 ビジーウェイトとか平気でやるからな、ゲームプログラマは。
- 126 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:00:32 ]
- >>107
並列演算を行った上で、 さらに、 マルチスレッドですよ。
- 127 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:58:16 ]
- できるやつは新しいのが出てきてもいい物を作る
できないやつは昔からの作り方にこだわり進歩しない ゲーム製作スレのオブジェクト指向いらねという話と似てる
- 128 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 14:03:03 ]
- >>125
そんなアホはさすがに居ない。 、、と思いたいが、居る所には居るのか。
- 129 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 14:41:26 ]
- >>127
君みたいなのをみるとイライラする。 みんなマルチコア、マルチコアいっているけど、はっきりいって現状、中身がないって いっているつもりなんだけど。マルチコアの性能を生かした設計というのは難しいし、 まだそれは誰も解決していない。それを簡単だというならそれをちゃんとわかるように それをどうやって解決したか書いてくれ。ここはそれを解決するためにみんなで考えま しょうっていうスレだ。 マルチコアをマンセーするのとその技術をマスターするのは、天と地ほど差があるよ。 マンセーするだけでマスターした気になっているのは中身が無い。 もうちょっと真剣に技術に対して考えてくれ。
- 130 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 15:03:11 ]
- >>129
>はっきりいって現状、中身がないって >いっているつもりなんだけど。 これって「一般人の使うデスクトップに関しては」って事かな。 範囲を限定しないと、議論にならないと思われ。
- 131 名前:129 mailto:sage [2006/01/24(火) 15:06:14 ]
- >>130
最初から使い道がはっきりしているHPCやサーバ用途を除いては、です。 適確なつっこみスンマソン。
- 132 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 15:11:56 ]
- >>125
ジャンルにもよるが、ゲームってのは譲り合いの最たる分野だよ。 処理落ちと戦うアプリが他にどれほどあると思う。ただ他のプロセス のことを考えるのはPCやらんとわかりにくいね。
- 133 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 15:23:10 ]
- あと、ユーザの立場からデュアルコアまではメリットがあるといのも了解事項?
デュアルコアのメリットはスループットとレスポンスタイムを両立出来る事。 裏で重い処理を走らせていても(要スループット)、表の処理のレイテンシを 少なく出来る(要レスポンスタイム)。裏の処理の例としては、ダウンロード、 スパムフィルタリング、エンコード、ウィルススキャン等。表の処理の例としては GUI 描画等。今時のウェブブラウザとかは既にマルチスレッド化されているし。 その上で、プログラマの立場から、メニー/マルチコアのメリットを最大限に 活かせる様な設計とは何かという事だよね?
- 134 名前:127 mailto:sage [2006/01/24(火) 15:36:32 ]
- >>129
PCがまた売れるようになってきた原因がいわゆるTVつきでキャプチャとか出来るパソコンなわけだが これらはデュアルコアの恩恵が非常に大きい コンシューマレベルでも十分恩恵受けてると思う それにゲームでもマルチスレッドを使うことによって、プログラムがより簡単になるとかあるんだよ とりあえず4コアまでならコンシューマレベルでもかなり恩恵は出るとおもうけど 8コア以降は俺はしらね
- 135 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 16:14:17 ]
- >>134
>プログラムがより簡単になるとかあるんだよ 例えば? ネットワーク回りを別スレッドにするとか、そういうの?
- 136 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 16:41:52 ]
- >>135
そういうこと サウンド回りにしてもね シンプルになるよ
- 137 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 16:45:51 ]
- >>136
その辺はシングルプロセッサでも別スレッドだべ?
- 138 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 16:46:55 ]
- サウンドやネットワーク周りをメインスレッドで動かすのはちっと
考えられん。
- 139 名前:138 mailto:sage [2006/01/24(火) 16:49:06 ]
- 昔のゲーム機でサウンドをVSyncで処理している事例はあるにはあったけどね
- 140 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 17:41:23 ]
- >>137
だね BGMにしろ通常圧縮フォーマットからそれをPCMデータへ展開、キューに突っ込む キューから取り出してデバイスへ転送 の2スレッド構造にすれば非常にシンプル 効果音にしても別スレッドでキューからのコマンドを下に転送支持とか まぁマルチコアになって楽できるべ >>139 つーか割り込み使ってる時点で別スレッドと同じような動きだろう
- 141 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 17:43:26 ]
- やっぱり、プログラム板的にはマルチコアだからって何ら特別なことは
なく、マルチスレッドでプログラムを書けばよい、でOK?
- 142 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 17:53:46 ]
- >>140
>の2スレッド構造にすれば非常にシンプル 分けると同期が逆に面倒な気がする。読み込む部分が ネットワークからのストリーミングだったらおっしゃるように 二段構えになるけど、それはネットワークのレスポンスが タイミング違いすぎるから。 >つーか割り込み使ってる時点で別スレッドと同じ ぜんぜん違う。サウンドプログラムは中でループ回す 構造にできない。サウンドプログラムもイベント駆動型 にする必要ある。 とはいえ大違いでも、大差ないと言えば大差ないが。
- 143 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 17:54:32 ]
- >>141
それじゃあ話がおわっちまうが確かにその通りじゃね
- 144 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:05:43 ]
- >>142
だから同期のライブラリが充実している高級言語が有利なんだよ そもそもスレッドだってループするように作ってなくていいわけで
- 145 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:26:39 ]
- >>144
高級言語という話の流れはどこから? >そもそもスレッドだってループするように作ってなくていい ループしないってことは割り込みみたいに毎度毎度スレッドを 生成するのか? そんな馬鹿なことしてるとは思えないから 一度生まれたスレッドを殺さずに使い続けるのは何かしら中で ループしてるってことだろ?
- 146 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:30:12 ]
- >>145
スレッドプールとかあるし、ユーザーは意識させないよ 高級言語ってのは上のほうででてたJavaとか.NETとかそういうレベルの話 GCの大幅な速度上昇とふくめて有利に働くことが多い Cとかでシングルスレッドでガリガリにチューニングしたアプリより マルチスレッド使って適当にのほほんと書くアプリのほうが早いとか わりと普通だからな
- 147 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:35:55 ]
- んな細かいことはどーでもいいから、
読み書き速くするとか、読み書き中にゲーム続行できるようにしといてくれ。
- 148 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:43:20 ]
- そりゃプロセッサが複数あればそうだろう。依存関係のない部分
は簡単に並列化できるからね。 あと、スレッド内でループしない構造にするメリットってある? 記述は明らかにイベント駆動より簡単なのに。
- 149 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:46:15 ]
- >>147
ごめん、難しいんだ(笑) まあ、非同期読み込みは サポートするようにはしてるよ。でもこの辺はマルチ プロセッサでなくても恩恵受けるところだね。一方が 極端に遅いデバイスを扱う場合は特に。
- 150 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:47:18 ]
- >>148
スレッド数をスレッドプールでコントロールする場合ループさせないほうがいい
- 151 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:51:41 ]
- スレッドプールってサーバなんかのトランザクション処理以外にも使うんだ?
どんな用途で使ってるの?
- 152 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 18:56:57 ]
- スレッドプールはイベント駆動との中間みたいなもんか。
中で滞るものがあってもある程度緩衝材になるってのが シングルスレッドの純なイベント駆動に対するメリット? 同時に資源の消費しすぎを抑えられるってことね。
- 153 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 19:00:38 ]
- イベントディスパッチの代わりにプールからスレッドを起動するのか。何か重そうな。
- 154 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 19:11:53 ]
- 例えば、Winsock2系で(非標準だけど)最速といわれているIOCPは
スレッドプールを利用した仕組みだよ。
- 155 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 19:17:25 ]
- >>151
プールに既にあるから起動しなくて良い。ので高速。 現状のシングルスレッドでのイベントディスパッチャが、 スレッド数1のスレッドプールに相当します。 例えば10,000程度の物をアレコレ処理するとき、 10,000個スレッドを作らずに、論理CPU数x2程度の スレッドに効率よく処理を分散できるとか。
- 156 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 19:23:45 ]
- ふぅん、面白そうだね。ちょっと調べて実装してみたいな。
サンクス。
- 157 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 19:45:30 ]
- とはいえ話にあったBGMにはスレッドプールは向かないんじゃね?
詰まっていて鳴らせませんじゃすまないし。
- 158 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 19:54:09 ]
- 元々リニアにスケールする処理→スレッドプール
特殊な処理をメインスレッドから外出ししたい→普通にスレッド作る ...なんじゃないの。
- 159 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:09:39 ]
- スレッドプールはシングルスレッドでもいいんだけどマルチプロセッサ
に不可分散させたい時に便利だってことかー?
- 160 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:14:23 ]
- 簡単に別スレッド使える構文が欲しい。C++では何度も導入の
意見が出て却下され続けてるそうだが、 make_thread for(i=0; i<100; i++){ hogrhoge....; } って書いたら勝手にスレッド作ってメインは続行、for内は 独立したスレッドで動き出すみなたいな。 CreateThreadしたりオブジェクト作ったりマンドクセ
- 161 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:18:40 ]
- 現状のsmpのままだとメモリのボトルネックがもっとひどい事にならない?
コア数が増えるとクロスバースイッチとか導入するPCも出るのかな?
- 162 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:21:31 ]
- >>159
シングルコア・シングルプロセッサの場合でも、 とあるスレッドがI/Oで待たされてる間に他のスレッドで 他の処理ができる(かもしれない)、という普通のマルチ スレッドの利点も提供される。 イベントやトランザクションを処理するのに用いる。 スレッドは、1粒度の処理を行ったらプールに戻って 次に利用されるまでイベント待ちなどで待機する。 ずーっと続くセッションみたいなものの処理には無意味。 普通は>>155の「論理CPU数x2」とかよりもっと多くのスレッドを使う。
- 163 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:22:31 ]
- >>160
スレッド生成クラスとラムダで事足りるからじゃないの? make_thread終了の同期とる方法をOSから隠蔽する方が面倒くさそうだし。
- 164 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:33:48 ]
- >スレッド生成クラスとラムダ
それなあに?
- 165 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:36:15 ]
- どっちかっていうと閉包欲しいよ閉包。
ちょっとスレッドとかにも便利だよ。
- 166 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:50:57 ]
- make_thread foo();
ってやったら別スレッドで関数起動してくれるのが欲しい。
- 167 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:52:28 ]
- 216.55.183.63/pdc2005/slides/TLN309_Sutter.ppt
- 168 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:55:31 ]
- BGMの補充に関してはいわゆるブロッキングキューでいい
充填する側はキューサイズがいっぱいだとキューがあくまで待つ そして取り出す側はキューが取り出せる状態になるまで待つ 取り出す側が待つようだと音が途切れてるので意味はないけど、 充填する側をキューサイズでコントロールできるとバッファのサイズを コントロールしたり自前でリングバッファ持ったり待機させたりとか 面倒なことはしないですむ ロジックだけに集中できるってことだーね こういうのをJavaとかは用意してる ほかにもカウントダウンラッチとかサイケリックバリアとか優先度つきキューとかもある もうロック処理も優先順位つけたり細かく動けるようになったし 使い方は難しいがロックフリーでスレッドセーフのアトミックもある ソフトに限らずハードも異なるクロックでキュー使うの普通だし そういう考え方は必要だと思う おいしいところは真似しないとな
- 169 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 20:59:42 ]
- で、まあ、今話題になっているような内容は
マルチコアとは直接関係無く 普通にマルチスレッド、或いはマルチプロセッサに関する話題でして。 ↓以下ループ
- 170 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:33:12 ]
- 一々、茶々入れんと気が済まんのか。御主は。
- 171 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:45:26 ]
- 普通にマルチスレッドの話でいいんでないの?
スレの名前も並列化だけだし。 マルチコアが普及することによって・・・というだけでしょ。
- 172 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:52:45 ]
- あっちよりこっちが賑わってるのはスレタイの勝利ですか
- 173 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 21:58:02 ]
- >>172
あっちってOpenMPスレ?
- 174 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 22:14:53 ]
- マルチスレッドって名前付いてるスレ
- 175 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 22:25:37 ]
- まあ、賑わってるって言ったって、住人の顔ぶれは
ほとんど変わらないと思うけどな。
- 176 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 22:31:25 ]
- あっちはC+Win32ベースでしかも基本的なところから先に進んでない
単純な排他制御だけではお話になりませぬ ロジックとしてどういうのがいいかという話のレベルまでいってないんだよな >>1とかみてもこっちのほうが広い目というかもっと上位の話題にみえる マルチコアを生かすのに簡単なのがマルチスレッドってだけで マルチスレッド以外で現実的な並列プログラミングの方法があれば・・・というところだろう
- 177 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:14:45 ]
- このスレッドの場合は極端な事を言い出しても、
まだまだ使い古されて無い技術だから叩きづらいんだよ だから好き勝手に色々な事が言える
- 178 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:16:55 ]
- >>164
多分、どっかの誰かが作ったスクリプト言語だったと思う
- 179 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:19:21 ]
- まあ結局、並列化を効率よくやろうとすると、自前でスクリプト言語を作るか、
現時点で存在するスクリプト言語に頼るかの、二者択一になってくるんだよな
- 180 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:20:46 ]
- あるいは、同期機能を駆使してC++で作るとか・・・
- 181 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:23:25 ]
- でも、自前でスクリプト言語を作ったりすると、
わざわざマルチスレッドにする必然性が、 高速化以外には全く無くなったりする罠。w
- 182 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:28:21 ]
- Javaもまあ、スクリプト言語の一種といえば一種か
- 183 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:36:41 ]
- >>160
一カ所のメモリーに対する多重アクセスを防ぐのが難しくなるからかと
- 184 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:36:58 ]
- >>178
Boost か何かのライブラリの機能でしょ。
- 185 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:38:03 ]
- >>179
スクリプト言語は、GC という並列化と相性が悪い物を抱え込む事になる。
- 186 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:38:23 ]
- 何でマルチコアの話で「スクリプト言語」がでてくるんだ?
- 187 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:40:51 ]
- 気にしちゃダメ
- 188 名前:デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:44:35 ]
- >>186
スレッドの管理が面倒だからかと 面倒な処理は、誰かが勝手にやってくれる方が楽だからな
- 189 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 00:15:33 ]
- >>160
Javaならすぐかけるのにね
- 190 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 00:31:21 ]
- そろそろC++も言語にスレッドを組み込んでしまって、何らかの
シンタックスシュガーが欲しいところ。
- 191 名前:デフォルトの名無しさん mailto:sage [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();//おわるまでまつ とインナークラスでかけるな スタック変数とのやり取りでは面倒なことになるが
- 192 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 02:00:13 ]
- スレッドの話はスレ違いだろ。スレッドだけにスレ違いw
- 193 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 06:15:51 ]
- >>191
へ〜、Javaだと仮想関数をそんな風に作れるんだ・・・
- 194 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 09:46:54 ]
- マルチコア時代もJavaで決まり!!!
ドントネット死滅ケテーイ(禿藁嘲笑)
- 195 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 11:01:49 ]
- >>191
記述は楽なんだけど、外側のローカル変数を受け継いで欲しい。 中の処理にパラメータはどうやって渡すのがお行儀いいの? >>193 仮想関数?
- 196 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:24:58 ]
- >>195
受け継ぐだろ。finalにするだけで。 final必要にしたのは、リークが見つかりにくくなるからとSUN社員のブログか何かに書いてあった。 ぜんぜん並列と関係ないな…。
- 197 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:54:27 ]
- final宣言されたローカル変う右派コンストラクタでコピーされて渡されてる
そもそもfinalは変更が不可能なのでお手軽に変数を渡すわけにはいかないよ 普通にクラス作ればいいだけだけどね
- 198 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:58:30 ]
- >>191
>>160の例はそういうことじゃなくて、i=0からi=99までの初期状態を持つ 100個のスレッドの生成と実行と待ち合わせが簡易な構文でできればなー、 という話なのでは? そうじゃないならCでも関数一個定義するだけだからそう面倒じゃないし、 このスレ的に迫力ないし。 >>196 ホント?Javaっていつのまにかクロージャが使えるように成ってたんだ。 世の中には信じられないようなことが起きているなあ。
- 199 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 13:42:21 ]
- Javaのそれをクロージャと呼ぶと、変な人が湧いてくるよ。
- 200 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 15:58:45 ]
- >>133
お前はスレッドの優先度を設定しないアホプログラマか。
- 201 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 16:55:05 ]
- Win32限定なら、QueueUserWorkItem()一発かな。
自動的にスレッドプールを作って関数を実行してくれる。
- 202 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 19:01:32 ]
- >>198
匿名内部クラスでぐぐれ
- 203 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 23:28:05 ]
- マルチスレッドなんて時代遅れ。
これからはマルチコア。これだね。
- 204 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 00:12:15 ]
- >>199
コンパイラ・スクリプトエンジン相談室によく出没するあいつらか?
- 205 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 00:13:24 ]
- Lispこそがすべての起源。
Lispを知らずしてプログラミングを語るべからず。
- 206 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 01:06:43 ]
- >>200
いや、プライオリティの問題もあるが、それだけじゃない。
- 207 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 03:25:18 ]
- マルチコアだと重いタスクを裏に回せるのがメリットかね。
シングルコアで重いタスクを裏に回しても、裏のタスクの 進行が遅くなるか表のタスクが足を引っ張られることが 多い。 マルチコアなら重いタスク専門に1コア割り振れるから 表はノーペナルティ(に近い速度)で動ける。 まあ重いったって基本的にはI/Oとメモリを大量に使う 処理ぐらいしかないんだけどな。
- 208 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 03:36:50 ]
- ×マルチコアなら
〇マルチプロセッサ(HTT含)なら
- 209 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 08:43:17 ]
- で、結局、バス幅とバスクロックの壁はどうにかなりますか?
- 210 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 09:03:54 ]
- >>206
いくらプライオリティが低くても、 一旦CPUを割り当てられたら、割り込みがかかるまで、一定時間はCPUを占有する、 という問題はあるけれど、ユーザのインタラクティブな操作は割り込みをかけるので問題なし。
- 211 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 09:07:08 ]
- スループットを犠牲にしてでもレスポンスを良くしたければ、
CPUの割り当て時間を短くしてしまうのも手ですよ。 たとえばWindowsの場合は、HALによっては変更をサポートしてる。 ちなみにデフォルト値がWindows2000の場合、 マルチプロセッサだとシングルプロセッサの1.5倍の時間に設定される。 WindowsXPの場合、シングルプロセッサでも、マルチプロセッサと同じ時間に設定される。 WindowsXPがモッサリな原因の1つが、1.5倍に設定されたことだよ。
- 212 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 13:16:58 ]
- >>211
アフィニティを下げたら各コアのキャッシュが汚れるから、デュアルコア時のメリット薄いんじゃないかな。 シェアードキャッシュなら良いんだろうけど、普通 L1 はシェアしないでしょ。
- 213 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 14:46:16 ]
- インテルのデュアルって肩並べて爆熱してるだけのツインプロセッサじゃないのか?
- 214 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 15:46:58 ]
- IntelCoreしらんのか
- 215 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 17:54:54 ]
- しらんがな
- 216 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 18:13:20 ]
- >211から>212へ行く話の流れがわからない。
>212は何に関するaffinityのことを言っているの? CPUの割り当て時間との関係は?
- 217 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 23:50:22 ]
- Windows では Thread Affinity って言葉は使わないのかな。
と思ったが、>>211 は CPU Quantum の事を言っていたのか... スマソ。勘違いしてた。
- 218 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 22:22:57 ]
- Windowsでアフィニティと言えば、
プロセスやスレッドを特定のCPUだけにしか割り当てないようにアプリがOSにお願いすることだよね。
- 219 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 05:00:41 ]
- それは UNIX で Processor Bind と呼んでる機能かな。
- 220 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 18:42:42 ]
- 名前を前例に倣わんのはMSの悪いところ。とはいえスレッド関連は
NTのほうがUNIXより早いんかね?
- 221 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:15:40 ]
- お前ら並列プログラミングを語る前にLispについて学べ
- 222 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:23:30 ]
- >>221
なんで?いまの並列化言語は論理型のほうがすすんでないか?
- 223 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:43:33 ]
- Lispを知らずしてプログラミング言語を語るべからず
ム板にいながらこんな常識すら知らないとは・・・
- 224 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:46:33 ]
- >>223
各所で Lisp を貶めるのは止めてくれ
- 225 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 22:57:15 ]
- >>223
おまえみたいなのがいるからLisp使いがバカにされる
- 226 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 23:23:26 ]
- >>223はこういう念仏を唱えるだけのアホウがいる、という話かと思ったら
アホウ当人だったのか。 こいつ、どうせLispスレじゃ何にもレスしてないよ。 以前もRuby使えないくせにあちこちのスレにRuby万歳突撃やってた基地外がいたが、 同一人物かもしれん。
- 227 名前:デフォルトの名無しさん mailto:sage [2006/02/02(木) 19:13:07 ]
- そんなことしてるのがリアルに居るとは信じられんが、カナシス
- 228 名前:デフォルトの名無しさん mailto:sage [2006/02/02(木) 23:35:39 ]
- 正直なところ、Lisp知らん奴が語ってるのって、幼稚なんだよね。
本質でない、些細な部分に無駄に労力を費やしてるって感じ。 議論も設計もコーディングもスマートにやれるのがLisp、 これを学ばない手はないね。
- 229 名前:デフォルトの名無しさん mailto:sage [2006/02/02(木) 23:41:51 ]
- >>228
>>224
- 230 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 03:19:53 ]
- Lispって何でもありすぎる。あれならマシン語で
プログラミングしてるのと代わらんような。 適度に制限されたフレームを提供するのが言語の大事な役割 というキガス。
- 231 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 04:00:13 ]
- >>230
>適度に制限されたフレーム こういうのは時間とともに綻びが生じて来るから、新しいパラダイムが来たら 無理矢理建て増しするハメになるよ。既定のフレームに沿わなくてはいけない 環境では、未知の問題への適応能力も自ずと低下してしまうから、Lisp の 出自を考えると受け入れられないだろうね。 とは言っても、Lisp は元祖超高級言語なわけで、マシン語と比較する物では 無いでしょう。適度な強制が好きなあなたには Python をお勧めします。 あ、それから…、 ここは並列化のスレなんで、言語の善し悪しの話は完璧にスレ違いです。 お引き取りください。
- 232 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 04:49:07 ]
- 俺はlisp知らんけど、
もし本当にlispが並列処理向きだったとして 現状のlispインタプリタは、マルチスレッドで並列処理してるのか? 仮にマルチスレッド動作しているとしても 並列可能な処理数はかなり大幅に増減すると思うのだが(for_eachとかあったよな?) 全部並列にやろうとするのか?スレッド数も増減させて。 まあ、スレッドプールとか使ってうまくやっているのかも知れないが。
- 233 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 04:57:20 ]
- >>232
>もし本当にlispが並列処理向きだったとして Common Lisp の事なら、そもそも ANSI 規格では並列化は考慮されていない。 フリーの実装に限って言えば、マルチスレッドのコンパイラは少ない。 並列/分散処理の研究に Lisp が使われてたりはあったと思う。
- 234 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 05:03:49 ]
- 並列化言語の側も盛り上がってないし、今の並列処理の枠組みは pthread とかに
依存しているんで、今後も C とか Java でどうするかって話が主流なんじゃないかな。 関数型言語にもちっと頑張って欲しい所。
- 235 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 09:51:27 ]
- どの言語がいいだの悪いだのはモノ作れるようになってから語れ
('A`)
- 236 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 09:57:14 ]
- 自分で言語を作るのは、手間がかかるんだよ。w
続きは「コンパイラ・スクリプトエンジン」のスレッドでやらないか?
- 237 名前:デフォルトの名無しさん mailto:sage [2006/02/03(金) 21:26:44 ]
- 別に実装の話まで入り込む必要は無いんだけど、並列化を支援する言語のフィーチャーに
どんな物があるのかは興味がある。
- 238 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 00:05:15 ]
- >>237
そういう話題は、「マルチスレッドプログラミング相談室」で。
- 239 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 05:24:48 ]
- あっちは実践、こっちは理論や研究レベルってことで、こっちでもいいんじゃない?
並列化の支援というか、上にもあったと思うけど、 関数型言語なんかはプログラマが並列化なんか気にせずに並列化できたりする、理屈の上では。 これなんか実際に、後から何スレッドで動かすか指定するみたい。 www.haskell.org/haskellwiki/GHC/Concurrency#Multiprocessor_GHC
- 240 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 05:28:19 ]
- と思ったら普通にプログラムの方でも指定するみたいだな。
並列に出来るからって勝手に全部並列化したらオーバーヘッドの方が大きくなっちまうか。
- 241 名前:デフォルトの名無しさん mailto:sage [2006/02/04(土) 13:27:34 ]
- ウザいLisp厨のせいで折角のふいんきが台無しだな
- 242 名前:デフォルトの名無しさん mailto:sage [2006/02/11(土) 19:50:33 ]
- スレ頓挫か?
- 243 名前:デフォルトの名無しさん mailto:sage [2006/02/11(土) 20:06:40 ]
- なんかネタがねぇ。だれかネタ提供してくれ。
www.coins-project.org/ そうそう、こういうのを最近みつけた。 日本のコンパイラ界の重鎮、中田育男先生とか、その他にも Javassistの千葉滋先生とかオールスターメンバーっぽい。 SIMDによる自動並列化や、自動的に普通のコードをOpenMPに 変換してくれたりするらしい。関連した論文もたくさんでて いるみたい。 個人的には大学で研究やっている先生方が、どの程度の実用的な コンパイラがつくれるか注目している。マイクロソフトやインテル なんかとも張り合えると思っているんでだけど、期待しすぎ?
- 244 名前:デフォルトの名無しさん [2006/02/11(土) 20:12:43 ]
- たまにはageとく
- 245 名前:デフォルトの名無しさん mailto:sage [2006/02/11(土) 21:05:00 ]
- -‐-
__ 〃 ヽ ヽ\ ノノノ)ヘ)、!〉 (0_)! (┃┃〈リ はわわ〜マルチが245ゲットですぅ〜〜 Vレリ、" lフ/ (  ̄ ̄ ̄《目 | ===《目 |__| ‖ ∠|_|_|_|_ゝ ‖ ∧__∧ |__|_| ‖ ┝・∀・┥トララーも2ゲット。 | | | ‖ ( ) |__|__| ‖ |〓 | 〓| | \\ 皿皿 (__) __).
- 246 名前:デフォルトの名無しさん mailto:sage [2006/02/12(日) 10:34:53 ]
- トララーがワカンネ
- 247 名前:デフォルトの名無しさん mailto:sage [2006/02/12(日) 23:55:41 ]
- OSがプリエンプティブであればマルチコアかどうかは
さほど問題ではないと思うのだがどうか。
- 248 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 00:18:59 ]
- >>247
それは必要条件であって十分条件じゃない。 そもそも何に対して問題無いって言ってる訳さ? スケジューラがプリエンプティブに出来ていたら、カーネルが ジャイアントロックしても問題無い? 大体、マルチコアつっても色々ある訳だが、どのマルチコアを 指して問題無いって言ってるんだ? 非対称コアなのか対称なのか、キャッシュは共有されている のかいないのか、スレッディングはあるのか無いのか、それは SMT なのか CGMT なのか FGMT なのか?? NUMA なマルチプロセッサとマルチコアじゃ最適化ポイントが 全然違うんだぜ。 それに、マルチコアは OS だけの問題じゃ無い。コンパイラは CPU の実装を理解して最適化を掛けているのか、アプリは MT でスケールするように作られているのか??? ネタ振りとしてはこれくらいで良いか?
- 249 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 10:57:19 ]
- シングルスレッド最強
- 250 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 20:52:13 ]
- シングルスレッドで作って、適当にexecすればいいじゃん。
何を悩んでいるのかわからない。
- 251 名前:デフォルトの名無しさん mailto:sage [2006/02/13(月) 20:58:46 ]
- もう面倒くさいよ。
- 252 名前:デフォルトの名無しさん mailto:sage [2006/02/14(火) 15:41:09 ]
- おわりか
- 253 名前:デフォルトの名無しさん [2006/02/23(木) 13:09:55 ]
- japan.cnet.com/news/ent/story/0,2000047623,20097056,00.htm
Cell向けにOctopilerツールが発表されるらしい。 どういう形で支援するか謎だ。そのあたりの情報が外部にも出してもらえると、 今後のマルチコア向けアプリケーションの開発に少しは参考になりそう。 聞きかじりなんだけど、Cellってバス予約という機能があって、コアごとに あらかじめ必要なバス帯域をキープできて、一度に複数のバスアクセスが 集中しないようにできているみたいだね。バス帯域の問題はどうにかして 欲しいけど、PCでは同様の解決方法は難しいかな? 仕事でCellとか触れる人はいいね。自分は関係ない職種だから触れません。
- 254 名前:デフォルトの名無しさん [2006/02/23(木) 13:48:56 ]
- マルチコアでマルチスレッド処理が平気でできれば、これから食いぶちがありますあ?
- 255 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 14:21:45 ]
- なにやっても食っていける。重要なのは仕事取る(就職含む)対人スキル。
プログラミングはそれからだ。 とはいえ、金出す側の鼻が利く場合に備えて腕は磨いとけ
- 256 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 14:56:45 ]
- ドカタ乙
- 257 名前:デフォルトの名無しさん mailto:sage [2006/03/04(土) 22:34:53 ]
- 特に意味はないが、保守っとく。
ちょっと古いけど、Timed Calculus of Communicating Systems つーのを調査中。
- 258 名前:デフォルトの名無しさん [2006/03/06(月) 22:39:39 ]
- 保守
- 259 名前:デフォルトの名無しさん [2006/03/06(月) 23:37:03 ]
- >>257
googleで検索したけど、TCCSって何ですか?TimedがつかないCCSなら たくさん説明があるんですが、似たものもしくは同じものなんですかね。 Calculusいうぐらいだからπ計算とかの親戚の計算モデルっぽいのは わかるんですが。 ここを読んでいる人でプロセス代数とかやってる人っています?
- 260 名前:デフォルトの名無しさん mailto:sage [2006/03/07(火) 08:21:54 ]
- そりゃCCSなら説明がたくさんあるだろうな・・・
- 261 名前:デフォルトの名無しさん mailto:sage [2006/03/12(日) 02:13:05 ]
- >>253
OpenMPのpragmaを流用するみたい
- 262 名前:http://www.vector.co.jp/soft/win95/util/se072729.html mailto:http://msdn2.microsoft.com/ja-jp/library/h2k70f3s.aspx [2006/03/18(土) 22:08:36 ]
- TextSS のWindowsXP(Professional)64bit対応化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか? そういや64bitにネイティブ対応している2chブラウザてありましたっけ?
- 263 名前:デフォルトの名無しさん [2006/03/18(土) 22:23:01 ]
- >>261
そうなんですか。できることは限定されているような気がしますが、 普通にCellに最適化されたプログラムを書くより大分楽にはなり そうですね。
- 264 名前:デフォルトの名無しさん [2006/03/22(水) 23:49:32 ]
- it.nikkei.co.jp/digital/news/index.aspx?i=20060320ew000ea
やっぱり開発が難しいそうですよ。新しいノウハウが必要らしい。予想通りだ。 マルチコアはいいけどソフトウェアの負担は大きい。
- 265 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 00:22:34 ]
- 86とか汎用の石のマルチコアが難しいというのと
Cellが難しいというのとはたぶん難しい場所が違う CellはPS2の延長と考えればすっきりするしその程度
- 266 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 00:25:24 ]
- >>265
それが新しいノウハウだろw PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど
- 267 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:12:40 ]
- 86系ってCPUの思想があれだから、マルチコア化を困難にさせてるんだよな・・・
- 268 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:20:43 ]
- ↑
こういう知ったかがわくのはどうにかならないのか?
- 269 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:22:39 ]
- >>267
思想がアレなのはiApx432だろ。
- 270 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 01:24:49 ]
- レジスタが専業化されてるってやつだろ?
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。
- 271 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 10:15:02 ]
- uOp fusion のコストが高すぎるといってるのか?
俺には的外れに思えるが。
- 272 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 05:57:20 ]
- ↑
こういう知ったかがわくのはどうにかならないのか?
- 273 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 11:57:44 ]
- 267が論旨を明確にすればいいだけの話。
- 274 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 17:50:04 ]
- デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない? という意味だと漏れは思う。
- 275 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 22:46:44 ]
- つまりメタセコイアは生きた化石だということか。
- 276 名前:デフォルトの名無しさん [2006/05/14(日) 23:36:57 ]
- 鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。
- 277 名前:デフォルトの名無しさん mailto:sage [2006/05/14(日) 23:54:33 ]
- そうでもない
- 278 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 14:07:50 ]
- ho
- 279 名前:デフォルトの名無しさん mailto:sage [2006/09/10(日) 20:48:00 ]
- >>276
2-4 並列くらいでいいんだから余裕じゃ。 大変って言ってる奴が居たら、それは「マンドクセ」って意味か、「もっと金寄越せ」って 意味かのどちらか。
- 280 名前:デフォルトの名無しさん mailto:sage [2006/09/15(金) 00:56:12 ]
- Objective-C + Cocoa なソースで OpenMP って使えるの??
- 281 名前:デフォルトの名無しさん mailto:sage [2006/09/30(土) 23:13:10 ]
- Cilkってどう?
- 282 名前:デフォルトの名無しさん mailto:sage [2006/09/30(土) 23:34:11 ]
- イソテルが発表した4コアってプログラミング的にはどうなん?
性能を活かせるコンパイラってあるの?
- 283 名前:デフォルトの名無しさん mailto:sage [2006/10/01(日) 00:38:46 ]
- 80コアか・・・
機械的に最適化できる方法あるのかな? ttp://techon.nikkeibp.co.jp/article/NEWS/20060927/121563/?ST=edaonline&ref=rss
- 284 名前:デフォルトの名無しさん mailto:sage [2006/10/03(火) 09:41:30 ]
- まぁ数年間は OpenMP 使ってチマチマ並列化するのが手っ取り早いだろーね。
でも 80 コアの時代には言語レベルで並列化/分散処理をサポートした 新しい言語が主流になってると思う。 そうじゃないとプログラミングがしんどくなるね。
- 285 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 15:44:34 ]
- そこまでしてx86である必要がないような。
- 286 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 19:56:41 ]
- 互換性が重要だからね。
x86系は(PC/AT互換機が業界標準になったおかげで)業界標準になったから過去の互換性切れないんだよ。
- 287 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 22:54:13 ]
- ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。
- 288 名前:デフォルトの名無しさん mailto:sage [2006/10/08(日) 23:29:37 ]
- そういうわけに行かない業界と素人と過去の遺産の都合を考えろってこと。
カーネルやドライバ部分なんかはCPU変わったらほぼ完全に書き直しだろうし。 CPUごとに使用するコンパイラ&ミドルウェアが変わることで開発やサポートのコストは跳ね上がる。 (商用ソフトがほとんどの場合ライセンス上の理由でソースコード公開できないことくらいは分かってると思うけど)
- 289 名前:288 mailto:sage [2006/10/08(日) 23:32:09 ]
- ×公開
○開示 だな。まぁ公開も商用である限りまず望めないだろうね。
- 290 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 00:12:55 ]
- 倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw
- 291 名前:デフォルトの名無しさん mailto:sage [2006/10/09(月) 00:29:27 ]
- >>290
ユーザーが増えないから売れそうもないので対応しない バイナリが流通しないから新しいアーキテクチャのユーザが増えない 以下繰り返し この悪循環が始まるだけなんでそういう事を言われても困る。
- 292 名前:デフォルトの名無しさん mailto:sage [2006/10/10(火) 01:06:52 ]
- 「対応しないと売れない」の間違いじゃね?
つか、対応せずに済むというのはユーザー側の思考で、本来なら企業のビジネスチャンスのためにも積極的にハードウェアアーキテクチャを変更するべきなんだよ。 儲かるのはマイクロソフトだけ。っていう図式が何を意味しているかしっかりと考えてみろ。
- 293 名前:デフォルトの名無しさん mailto:sage [2006/10/12(木) 15:26:01 ]
- OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・
- 294 名前:デフォルトの名無しさん mailto:sage [2006/10/12(木) 21:35:46 ]
- >>293
それは使い方間違ってるだけだろ。 俺が反論してやるからURLキボソ
- 295 名前:デフォルトの名無しさん mailto:sage [2006/11/18(土) 02:08:28 ]
- そいつの考え方がおかしいんじゃねーのかどこか知らんが
- 296 名前:デフォルトの名無しさん mailto:sage [2006/11/26(日) 14:08:24 ]
- >>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。
- 297 名前:デフォルトの名無しさん mailto:sage [2006/11/26(日) 14:41:15 ]
- 挙動不審
- 298 名前:デフォルトの名無しさん [2006/11/26(日) 22:38:34 ]
- マルチコアって何で難しいの?同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの?
あるいはSETI@homeみたいに部分に分けて処理させるのはどうなの? あとマルチコアって確率論とか統計学とかいるの?(学問ではなにが関係するの?) というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの?
- 299 名前:デフォルトの名無しさん [2006/11/26(日) 22:45:47 ]
- volatile最強宣言ktkr
- 300 名前:デフォルトの名無しさん [2006/11/26(日) 22:53:22 ]
- > マルチコアって何で難しいの?同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの?
釣りですか? > あとマルチコアって確率論とか統計学とかいるの?(学問ではなにが関係するの?) プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。 > というか今までもスパコンはほとんどマルチコアだと思うけどあれはなんで問題なく高速化できてるの? 分散処理の研究が進んでいるのと、それ様のプラットフォーム(MPIとか)が 整備されているから。何も考えずに無為にやっているけど大丈夫なわけでない。
- 301 名前:デフォルトの名無しさん [2006/11/26(日) 22:54:32 ]
- 訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。 ↓ > プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。
- 302 名前:デフォルトの名無しさん mailto:sage [2006/11/26(日) 23:10:00 ]
- ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか 学者さんは嫌いそうだが必要になりそう
- 303 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 00:38:23 ]
- おお、こんなスレが。
並列プログラム用のライブラリを作成しています。(C++/Unix用) pards.sourceforge.jp/ よろしければ御意見下さい。 >>166 の人のお望みの通り、SPAWN(foo());とすると関数fooを並列に実行します。 スレッドじゃなくてプロセスだけど。 プロセス間の通信、同期はSync<int> a;のように宣言した変数に対して、 a.write(1), a.read() のようにすることで行います。readはwriteが終わるまで ブロックします。 実用的な例として、bzip2の並列化も行っています。 詳しくは上記URLをご参照下さい。宣伝失礼致しました。
- 304 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 00:53:18 ]
- sureddo版を作る気はないのかえ?
- 305 名前:303 mailto:sage [2006/12/20(水) 01:14:41 ]
- スレッド版? >>304
スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの 温床になっているという主張なのですよ > このライブラリ グローバル変数触るだけでMT-unsafeになるので、スレッドを使った 既存のプログラムの並列化は難しいのですが、プロセスはメモリ空間を 分けるので、そんなことは無いと。 もちろんその分オーバヘッドはあるのですが、最近のOSなら我慢できる範囲では 無いかと思います。 # とか言いながらスレッド版作ったりして
- 306 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 02:09:16 ]
- なるほろ。
コードはそのままで、 デバッグ中は別プロセス、リリース時はスレッドで実行できるとかだと 超カッコEかもしれませんな。 ぬー、でもあんまり差が出ない気がしてきた。
- 307 名前:デフォルトの名無しさん mailto:sage [2006/12/20(水) 18:23:59 ]
- >>303
ネットワーク越しあり?
- 308 名前:デフォルトの名無しさん [2006/12/20(水) 23:21:00 ]
- あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。
実際にどれだけパフォーマンスに差がでるかわからないけど、 スレッド版を用意してくれると実際に使う人がベンチマークが取れて プロセス版かスレッド版かどちらかを選択するか判断できていいですな。 > スレッドはデフォルトで全メモリ領域をシェアするので、デバッグ困難なバグの > 温床になっているという主張なのですよ > このライブラリ さすがに含蓄のあるお言葉ですな。
- 309 名前:303 mailto:sage [2006/12/20(水) 23:28:00 ]
- >>307
いや、SMPだけを対象にしてます。 MPC++/SCoreとか、ネットワークで接続されたコンピュータを SMPに見せるのもあるけど、あそこまで作るのは大変っすよ(^^;
- 310 名前:デフォルトの名無しさん mailto:sage [2006/12/21(木) 19:53:02 ]
- JAVAってマルチCPUやマルチコアでも恩恵が無いって
昔は言ってたが今は変わったのか?
- 311 名前:デフォルトの名無しさん [2006/12/21(木) 20:09:14 ]
- >>310
JAVAはマルチスレッドにしても速度は上がらんよ。
- 312 名前:デフォルトの名無しさん [2006/12/21(木) 22:00:09 ]
- >>310
速度を気にするならJAVAは問題外
- 313 名前:デフォルトの名無しさん [2006/12/21(木) 23:29:59 ]
- てっきり >>194 みたいなことが書いてあるから…
.netは対応?済みらしいがマルチコア環境じゃないから試せない。
- 314 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:01:18 ]
- マルチスレッドは速度を向上させるのが目的ではないと思うがなあ
- 315 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:09:25 ]
- サーバ的に言えばスループットを多重化に影響されず一定とするためのものだわな。
XMLのパースとその他みたいなパイプライン?は既にやってるとこもあるみたいだけど。
- 316 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 00:10:31 ]
- >>310-313
AP レイヤで使うのに十分なくらいならスケールするがな。 マルチノード、マルチインスタンスにはした方が良いけど、 かなりの大規模ノードじゃなければ十分。
- 317 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 04:56:33 ]
- >>285
x86である必要があってx86なのではなく、 数が出ているx86のコストパフォーマンスが優れているからx86なのだと思う。
- 318 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 05:05:09 ]
- >>314
何が目的なのか、ハッキリ言ってよ。 >>316 クライアントが同時に複数いる状況で性能を要求されるサーバならば、 2コアとか4コアくらいなら、 同期する必要のない部分と同期する必要がある部分に分けるだけで、 十分だったりするしね。 >>315 XMLのパースなんかは、他のスレッドと同期する必要がない処理なので、 パイプラインにするよりも、普通にスレッドプーリングでいいでしょう。
- 319 名前:デフォルトの名無しさん mailto:sage [2006/12/22(金) 12:35:22 ]
- >>310
他の言語と同じように恩恵はあるよ。 恩恵がないのは遥か昔の green thread の頃かな。
- 320 名前:デフォルトの名無しさん [2007/02/14(水) 06:21:12 ]
- Intel,80コアでTFLOPSを実現する浮動小数点演算プロセッサ開発
ttp://www.4gamer.net/news.php?url=/news/history/2007.02/20070213183701detail.html
- 321 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:26:58 ]
- トイレで大きい方をして席に戻ってきたら、周りの席の同僚女3人に大笑いされた。
職場の女がニコニコしながら、 「上司の○○さんが呼んでいたので『地球の平和を守りにいってます!』と答えておきましたよ〜」 死にたい気持ちになった。
- 322 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:32:41 ]
- へたくそなコピペじゃねーぞ!
あまりにショックなので、こんな過疎スレに書き込んでいる。 今夜は一人で飲みたい。
- 323 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:38:00 ]
- ↓あまりに悔しいから、お前のあだ名は「ウンコマン」にしてやる!
- 324 名前:デフォルトの名無しさん mailto:sage [2007/03/06(火) 16:47:30 ]
- オッス、オラうんこまん!
地球防衛隊員ってのをやってるんだ。よろしくな!
- 325 名前:デフォルトの名無しさん [2007/03/06(火) 16:57:41 ]
- >>324
恥ずかしい自演乙
- 326 名前:デフォルトの名無しさん mailto:sage [2007/03/07(水) 01:42:39 ]
- >>321
なんじゃそのFFやらDQの発売日翌日に遅刻した予備校生の言い訳みたいなのは。
- 327 名前:デフォルトの名無しさん [2007/03/13(火) 14:25:23 ]
- それより昼に仏跳麺を食った後に目薬を買おうとミドリ薬品に寄ったら会社の山下
さん(結構かわいい)がレジで支払いしてるトコだった。そのレジ台に置いてあったの がイチジク浣腸の10個入りパッケージ。もう裕子ちゃんがお尻にイチジク浣腸を入 れてるのを想像して今も勃起しっぱなし。このことは会社の同僚にはだまってる。 噂を流したら俺だってわかるし山下さんもかわいそうだから。
- 328 名前:デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:14:45 ]
- 動画エンコってマルチスレッド化するより単純にコアの数だけ時間か容量で等分して
それぞれエンコさせたファイルをつなぎ合わせた方が速そうな気がするけど、結局は>>106,115,209なの?
- 329 名前:デフォルトの名無しさん [2007/03/20(火) 22:13:18 ]
- linuxでやれ。
- 330 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 15:28:42 ]
- やってみる価値は非常にありそうだな。
- 331 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 16:43:18 ]
- つなぎ目ってどうするんだろう
mpegでいうIフレームにすればいいだけ?
- 332 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 20:02:48 ]
- >>331
たぶんそうなんじゃない。 動画は前の画像の圧縮して解凍したものを使うから ある程度の時間の動画をひとつのスレッドにしたほうが 効果ある上に作るのがとても楽だね。
- 333 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 21:17:47 ]
- キャッシュ効率が下がるんじゃない?
- 334 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 21:47:44 ]
- 下がるだろうね。
キャッシュ重視で1枚の画像を複数のスレッドでMPEG圧縮する。 手間かける余裕があるかどうか。 CPUのマルチコア化を一般ユーザが使うようになるころは メモリとかHDDの性能はどうなるのかしら。
- 335 名前:デフォルトの名無しさん mailto:sage [2007/03/21(水) 22:43:12 ]
- エンコードに必要なワーキングセットをNとすると
総キャッシュ量/Nより多いスレッド数でやると効率下がるだけやね ・・・そこまでやるか?
- 336 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 03:49:20 ]
- ここだと一般論を装った妄想でお茶を濁されがちだから
Core2限定の専用スレ立てていい?
- 337 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 11:25:18 ]
- ダンゴ様の許可があればいい
- 338 名前:デフォルトの名無しさん mailto:sage [2007/03/22(木) 14:28:33 ]
- >>336
Xeonは除外?
- 339 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 02:25:42 ]
- >>336
どんな話がどう濁されているのか具体的に。 そもそも過疎ってるんだしスレを良い方向に変えていくのも一つ。 >>338 XeonもCore2ファミリじゃね?
- 340 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 02:55:13 ]
- 初期のXeonもCore2だっけ?
- 341 名前:デフォルトの名無しさん mailto:sage [2007/03/23(金) 03:15:39 ]
- ダンゴ的にはどうよ?
- 342 名前:デフォルトの名無しさん mailto:sage [2007/03/29(木) 00:56:14 ]
- 結局は高クロックのシングルコアが速い?
- 343 名前:デフォルトの名無しさん mailto:sage [2007/03/29(木) 04:29:47 ]
- それができないからthe free lunch is overなのでは?
- 344 名前:デフォルトの名無しさん [2007/03/29(木) 20:44:06 ]
- Core2は使うレジスタ数を減らせば速いとかどっかで見たんですが
どういうことでしょうか Pen3やNetBurst系とは逆?
- 345 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 00:00:33 ]
- この質問はダンゴじゃないとマトモに返答できないと見た
- 346 名前:・∀・)っ-○◎● mailto:sage [2007/03/30(金) 01:52:36 ]
- .
- 347 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 03:33:19 ]
- 32bitモード、つまり
増えたレジスタを活かさないモードなら速い、ということなら 皆知ってるけどね。
- 348 名前:デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:22:50 ]
- 人間活動 → スカラ
自然現象 → ベクトル 中途半端 → 今のCMP全般
- 349 名前:デフォルトの名無しさん [2007/04/03(火) 09:13:21 ]
- ____
/⌒ ⌒\ ホジホジ /( ●) (●)\ /::::::⌒(__人__)⌒::::: \ <で? | mj |ー'´ | \ 〈__ノ / ノ ノ
- 350 名前:デフォルトの名無しさん mailto:sage [2007/04/03(火) 19:26:14 ]
- おちんぽ
- 351 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:20:44 ]
- 結局、下手に最適化せずに、単純なバイナリで、プロセッサに条件予測させた方が速いってことか。
- 352 名前:デフォルトの名無しさん mailto:sage [2007/04/15(日) 03:08:29 ]
- 既出かもしれんけど
cag.csail.mit.edu/ps3/index.shtml
- 353 名前:デフォルトの名無しさん [2007/05/06(日) 00:35:15 ]
- JCSPの話はここでいいのか?
- 354 名前:デフォルトの名無しさん mailto:sage [2007/05/06(日) 02:41:23 ]
- 良いんじゃない。
Java 固有の質問だったら Java のスレでやった方が良いかもしれないけどね。
- 355 名前:デフォルトの名無しさん [2007/06/03(日) 02:01:31 ]
- 保守
- 356 名前:デフォルトの名無しさん [2007/06/03(日) 15:31:56 ]
- 逐次処理を並列処理に分割する手法で代表的なものって何?
- 357 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 15:33:02 ]
- OpenMP とか関数型言語で書き直すとか?
- 358 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 15:41:12 ]
- >>356
OpenMP、pthread、MPI 辺りですかね。 # SMP 環境でわざわざ MPI する人も少ないかもしれませんが。 ちなみに性能的には MPI > pthread > OpenMP、 お手軽さでは OpenMP > pthread > MPI の順でしょうか。
- 359 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 16:43:38 ]
- >>358
>ちなみに性能的には MPI > pthread > OpenMP、 ええっ!? SMP環境でMPIってpthreadより性能いいの?
- 360 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 17:47:44 ]
- OpenMP、pthread、MPI ってどこにあるの?
- 361 名前:デフォルトの名無しさん mailto:sage [2007/06/03(日) 18:15:19 ]
- 一番星を右に進んだ所、虹の彼方に
- 362 名前:デフォルトの名無しさん [2007/06/04(月) 19:05:59 ]
- ジョブを並列に分割する際に、何に注目して並列化すればよいのでしょう?
データですか?タスクですか?
- 363 名前:デフォルトの名無しさん mailto:sage [2007/06/04(月) 19:20:07 ]
- 適材適所。
- 364 名前:デフォルトの名無しさん [2007/06/04(月) 19:22:08 ]
- 栄枯盛衰
- 365 名前:デフォルトの名無しさん mailto:sage [2007/06/06(水) 00:22:34 ]
- >>359
MPIは複数の計算ノード(例えばPCとか)を高速な通信回線で接続した HPCクラスタ用ですね。 pthreadは共有メモリシステムじゃないと使えないので、CPUの数を増や してもいくつかの理由(メモリアクセスの集中やキャッシュコヒーレンシ 維持のためのオーバーヘッド増加)のために、システム全体の性能はある 程度で飽和してします。大体 CPU 8〜16 個くらいが限界でしょうか。 クラスタシステムではCPUだけではなくメモリも分散配置しているので、 うまく仕事を複数のノードに配分するようにプログラムを作ることがで きれば、もっとCPUを増やしてもシステム性能を向上させることができ ます。 # でもそのソフトを作ったりデバッグするのが大変なので、MPIは暇な # 学生が使える教育機関でしか人気が無いような気がする…。
- 366 名前:デフォルトの名無しさん mailto:sage [2007/06/06(水) 13:37:00 ]
- >>365
MPIが性能を十分に発揮するのは「高速な通信回線で接続したHPCクラスタ」での話ですよね >>358 ># SMP 環境でわざわざ MPI する人も少ないかもしれませんが。 > >ちなみに性能的には MPI > pthread > OpenMP、 >お手軽さでは OpenMP > pthread > MPI の順でしょうか。 「SMP 環境でわざわざ MPI」してpthreadより性能を発揮する場面ってあるんでしょうか? あるいは下から2行目の「MPI」っつてるのは「高速な通信回線で接続したHPCクラスタ」が前提と読むべきなんですかね?
- 367 名前:デフォルトの名無しさん mailto:sage [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か、その手のライブラリ使うことになると思う。
- 368 名前:デフォルトの名無しさん mailto:sage [2007/06/07(木) 23:03:08 ]
- >>367
>SMPだけどNUMAなアーキテクチャ これは定義矛盾 Opteron は NUMA NUMA への最適化は最近のカーネルなら大抵入ってるよ
- 369 名前:デフォルトの名無しさん mailto:sage [2007/06/07(木) 23:13:02 ]
- >>367
もまいはこれよめ www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/40555.pdf
- 370 名前:デフォルトの名無しさん [2007/06/15(金) 00:05:56 ]
- これってどう?
www.rbbtoday.com/news/20051219/27869.html
- 371 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 00:10:53 ]
- 機械語レベルで、並列化すんだろな
能書きは本当か知らんけど発想はありだな
- 372 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 00:13:22 ]
- >>370
ttp://www.nec.co.jp/press/ja/0512/1902.html これのことか?
- 373 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 06:55:05 ]
- 何を並列化するかによるわな。
マンデルブロ集合の計算とか、完全に並列化できるものなら、そらN台でN倍に なるだろうけど、そんな簡単な用途は極めてまれなわけで。 宣伝の一人歩きだろう。
- 374 名前:デフォルトの名無しさん mailto:sage [2007/06/15(金) 07:46:05 ]
- >極めてまれ
そうでもない。 処理はシンプルでも大量に捌かないといけない場合はままある。 #尤も、そういうケースは並列化の自動化も難しいが。
- 375 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 01:44:51 ]
- んなこたあねえべさ。
むしろ順次処理じゃないといけない場面の方が少ないんじゃねぇかな?
- 376 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 02:10:48 ]
- 画像処理とオンライン系のトランザクションは並列化に向いてる処理が多いって
よくいわれるよね。××ルータ、××フィルタ、××サーバと名前に付くアプリは 並列化してナンボな物が多い。 デスクトップアプリは 4 コアもあれば十分だと思うけど。
- 377 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 11:53:25 ]
- 大規模マルチコアプロセッサの発売に向け準備を進めるインテル
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氏は指摘する。 プログラマーたちは、キャッシュ共有技術やハードウェアスケジューリング 技術を理解したり、これに対応するためにたくさんの労力をつぎ込む必要 はない。これらのオペレーションは大抵、チップ自体によって処理される ため表面化しないのである。
- 378 名前:デフォルトの名無しさん [2007/06/16(土) 16:38:55 ]
- >>377
素晴らしい!! テクノロジーの進化ってとんでもねぇなw
- 379 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 22:47:24 ]
- Windows出たばかりの頃の宣伝の様だが
- 380 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 22:56:25 ]
- まあイソテルの「プログラミングの簡略化」の範囲はアプリ屋の話で、
コンパイラ屋ガンガレ、死ぬまでガンガレ by Intel って漏れの耳には聞こえてるが気のせい?
- 381 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 23:05:49 ]
- >>380
そういうのは NetBurst や Itanic で懲りていると思いたい…
- 382 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 23:42:46 ]
- >380
俺にはIntel以外のコンパイラは淘汰されてしまえ と聞こえるが
- 383 名前:デフォルトの名無しさん mailto:sage [2007/06/16(土) 23:54:34 ]
- ARM、gcc、VC++でつかえなけりゃいみねぇー
世の中ICCが全てみたいな発想がすかん INTELはいっつもAMDいじめて悦に浸ってる変態だし しねってかんじだ
- 384 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 00:13:12 ]
- そらそうよ、Intelはパラノイアが社訓だもん
- 385 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 01:16:16 ]
- いよいよAMDの時代
northwood.blog60.fc2.com/blog-entry-928.html northwood.blog60.fc2.com/blog-entry-932.html northwood.blog60.fc2.com/blog-entry-935.html blog.livedoor.jp/amd646464/archives/50980564.html
- 386 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 01:23:55 ]
- Intel社、ソフトウエアの並列化が研究開発部門の最重要課題に
www.eetimes.jp/contents/200705/19305_1_20070528174750.cfm マルチコア・プロセッサに対する需要の高まりを受け、米Intel社はソフトウエア の並列化を最重要課題に掲げている。その取り組みの一環として、特定用途 向けプログラミング言語や既存のプログラミング言語/アプリケーションの並列化 に関する研究に250名を投入している。「オレゴン州にある研究開発部門では、 全業務の実に約3/4をソフトウエア関連が占める」 インテルが開発ツールの新版を発売、ソフトウエアの並列化を支援 www.eetimes.jp/contents/200706/19707_1_20070605170230.cfm コンパイラは、ベクトル化が可能な場合、SSE命令セットを利用したコードを 生成する。また、C++のテンプレート・ライブラリとして実装されているTBBを 利用すると、ソフトウエア開発者が明示的にコードを記述しなくても、マルチ スレッド化できる。OpenMPライブラリを利用しており、実行時に利用可能な コア数分だけスレッドを生成する。
- 387 名前:デフォルトの名無しさん mailto:sage [2007/06/17(日) 15:02:51 ]
- AMDは甘ちゃん
IBMとIntelはプロフェッショナル
- 388 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 01:10:40 ]
- 次世代スパコンはスカラーとベクトルの複合型に,日立/NEC/富士通の「3社連合」で開発へ
techon.nikkeibp.co.jp/article/NEWS/20070613/134173/ アーキテクチャの概要は,スカラー型プロセサからなる演算システムにアクセ ラレータを付加し,さらにベクトル型プロセサからなる演算システムを組み合わ せる,というもの。スカラー部とベクトル部は,共有ファイル・システムを介して データをやり取りする。これによって様々な大規模計算シミュレーションが計算 のタイプに合わせた演算環境を選べるようになる。 ハードウエアだけでなく,ソフトウエアも同時に開発する。「制御フロントエンド」 のジョブ管理を通して,ユーザーはこれら二つのシステムの違いを意識せずに 最適な演算環境を選べるようにするという。
- 389 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 06:50:59 ]
- >>384
コンピュータ様って事ですね?市民。
- 390 名前:デフォルトの名無しさん [2007/06/18(月) 23:42:06 ]
- もうすぐメニーコアがでてくるらしい。
システム設計とかどうすりゃいいんだか・・・ pc.watch.impress.co.jp/docs/2007/0611/kaigai364.htm
- 391 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:46:07 ]
- いつも通り、頭のいい人が仕組みを考えて、俺らがそれに乗っかって儲ける
で良いんじゃないかな。頭のいい人の代わりを務めようとすると大変だけど。
- 392 名前:デフォルトの名無しさん mailto:sage [2007/06/18(月) 23:51:36 ]
- シーケンス図廃止からやってみようかな?
で、その代わりに何を使えばいい??
- 393 名前:デフォルトの名無しさん [2007/06/19(火) 18:18:04 ]
- 並列システム用のモデリングviewをUMLに策定してくれんかな。
- 394 名前:・∀・)っ-○◎● mailto:sage [2007/06/20(水) 00:23:28 ]
- あのさー
マルチコアに限らずソフトの最適化なんて、現場レベルでボトルネック分析し どこを重点的に並列化するか設計フェイズにフィードバックしながらやっていくもんで 日本伝統のウォーターフォールモデルじゃ、いくらお絵かきツールが便利になっても 全然役に立たんよ。 むしろUMLの本質は抽象化なんでそもそもマルチコアを意識する必要ねぇ。 逆に具体化しちゃうと、コア数の増減やパフォーマンスの見積もり違いで破綻する希ガス。 マルチスレッドは一般的にはObserverパターン、と本で得た知識をそのまま晒してみる。 ttp://www.hyuki.com/dp/cat_Observer.html それにしても結城先生お茶目だな。
- 395 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 00:28:27 ]
- さてと、、、
- 396 名前:デフォルトの名無しさん mailto:sage [2007/06/20(水) 16:51:08 ]
- Cellスレでボコボコにされて
泣く泣くこちらのスレに逃げてきた団子が ご迷惑をおかけしております。
- 397 名前:・∀・)っ-○◎● mailto:sage [2007/06/20(水) 22:12:33 ]
- ゲハ厨自演乙
- 398 名前:デフォルトの名無しさん [2007/06/21(木) 00:00:47 ]
- >>396
バカかお前www 何も知らないんだなwwwww ム板で厨認定された糞団子が帰る場所は 学歴とゲハだよwwwwwwww
- 399 名前:デフォルトの名無しさん mailto:sage [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の方で勝手にタイムアウトをしているのですが このような場合はどのようにすれば回避できるのでしょうか?
- 400 名前:デフォルトの名無しさん mailto:sage [2007/06/21(木) 22:38:31 ]
- 簡単なファイルコンバート処理(ファイル読み込み→変換→ファイル出力)を並列化したいんだけど、定番のパターンとか定石ってある?
自分で調べた感じだとProducer-Consumerパターンが使えそうなんだけど・・・。
- 401 名前:デフォルトの名無しさん mailto:sage [2007/06/23(土) 18:29:29 ]
- UNIXのパイプ
- 402 名前:デフォルトの名無しさん mailto:sage [2007/06/24(日) 23:14:58 ]
- フィックスターズが出している
www.shuwasystem.co.jp/cgi-bin/detail.cgi?isbn=4-7980-1462-1 は、役に立つのだろうか? 立ち読みした限りでは内容がちと薄い気がするのだが。
- 403 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 16:17:27 ]
- >>402
それ持ってるけど、動くプログラムが書かれているだけで幸せ。 とりあえずコードを何回も書いて覚えている途中。 変な癖が付きそーだったら「違うよ」って教えてくれるとウレシイ。
- 404 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 20:43:30 ]
- そんなレベルの奴が並列化なんかに手を出すのが間違い
- 405 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 21:33:51 ]
- 並列かなんてたいして技術いる事じゃないだろ
- 406 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:43:46 ]
- そういうやつが平気でぼけぼけかますのが並列化
- 407 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:46:28 ]
- 科学計算レベルでの並列化と業務ソフトの並列化は同じレベルでは
語れないと思うんだが。そんな意味で入門には>>402はちょうどいい。 javaERの俺にはダグリー先生の本のほうが面白かったけど。
- 408 名前:デフォルトの名無しさん mailto:sage [2007/06/26(火) 23:48:17 ]
- >>406
一緒にするなよ
- 409 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 08:23:06 ]
- Amazonでの評価は微妙だね。
www.amazon.co.jp/dp/4798014621
- 410 名前:デフォルトの名無しさん mailto:sage [2007/06/27(水) 18:12:05 ]
- 俺は釣られないぞ
- 411 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 01:44:41 ]
- なんでOpenMPばっか期待されてんの?
どこにもOpenMPなんて書いてないように見えるが(本のタイトルとかに)
- 412 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 01:46:42 ]
- デザインパターンの本。
↓ Javaについてはほとんどのってないので期待はずれ。 ↓ デザインパターンの本、評価は微妙。 だれもJavaって言ってないじゃん…
- 413 名前:デフォルトの名無しさん mailto:sage [2007/06/29(金) 13:17:14 ]
- たしかに目次にも一言もOpenMPの文字はないね。。。
よく分からん書評だ。 俺は↓の本で勉強したけど分かりやすかった。くどいくらいだけど。 Win32マルチスレッドプログラミング www.amazon.co.jp/dp/4756114040/
- 414 名前:デフォルトの名無しさん mailto:sage [2007/07/06(金) 09:47:57 ]
- www.ebjapan.com/content/l_news/2007/07/l_news070702_0101.html
これってハードレベルで並列を実現したってこと?
- 415 名前:デフォルトの名無しさん mailto:sage [2007/07/06(金) 12:21:00 ]
- >>414
説明読んでいたら、家政婦が私語を始めたり、殺人事件を目撃したりしてしまう展開が脳内を過ぎった。
- 416 名前:デフォルトの名無しさん [2007/07/07(土) 21:55:50 ]
- 業務レベルでの並列と、コードレベルでの並列って差があると思うのだが
対処方法ってどうなってるでしょうね?
- 417 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 22:04:37 ]
- >>415
FPGAのparallel random access machine/model じゃねーのそれって? しかし今回はそれを1個だけしか作れていないはず。 64個最大実装時(現在開発中)が現行CPUの100倍程度って事だな まぁ、IntelとかにX86を32個とか載せた板作ってもらった方が 書きやすいと思われる。価格も現実的だし。
- 418 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 22:18:17 ]
- seisei.s8.xrea.com/thread/
これはどうなんだろうね?
- 419 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 22:39:58 ]
- >>418
うさんくさすぎねーかw これが全部実現できるならIPAとかに公募して金もらうはず。 なんか穴があるはずだ。実用上の
- 420 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 23:05:23 ]
- >>418
すげぇ、胡散臭すぎて読む気にもならないよ。
- 421 名前:デフォルトの名無しさん mailto:sage [2007/07/07(土) 23:29:44 ]
- 読んでみたが、xorの計算をマルチスレッドで演算するソフトなわけね。
速度が速くなるとは書いてないようだな。 で?
- 422 名前:デフォルトの名無しさん mailto:sage [2007/07/09(月) 01:01:13 ]
- XORをまるちすれっど?
で?
- 423 名前:デフォルトの名無しさん mailto:sage [2007/07/10(火) 10:41:52 ]
- オーバーヘッドが少ないとか、実行時効率が良くなるとかじゃないみたいね。
分かりやすい管理方式の提案? で?
- 424 名前:デフォルトの名無しさん mailto:sage [2007/07/10(火) 11:41:21 ]
- 順序立てて処理する必要が無い部分はマルチスレッドで並列処理すれば蝶早く計算できる!
俺天才!!! って事?w URL削るともっと胡散臭いw
- 425 名前:デフォルトの名無しさん mailto:sage [2007/07/10(火) 15:18:46 ]
- えーと自家製単純インタプリタ(command)が
並列にできるところを並列化、 という感じ? じゃなくてこれは単なる dish の簡単な使用例か。 ttp://www2.chem.nagoya-u.ac.jp/matto/90/70Proj/dish/index.phtml
- 426 名前:デフォルトの名無しさん mailto:sage [2007/07/11(水) 22:20:15 ]
- >>424
やばい、ドキュメントDLで金とるよ的なページもある。
- 427 名前:デフォルトの名無しさん mailto:sage [2007/07/11(水) 23:45:26 ]
- 419です。
スマン、どうやらスレ汚しをしてしまったようだ。 削除依頼してくるわ。
- 428 名前:デフォルトの名無しさん mailto:sage [2007/07/12(木) 00:01:42 ]
- ごめん、↑は418の間違いね
- 429 名前:デフォルトの名無しさん mailto:sage [2007/07/12(木) 02:56:59 ]
- そりゃ潔癖すぎる
気楽にやろうぜ
- 430 名前:デフォルトの名無しさん [2007/07/17(火) 07:17:14 ]
- クロック数が違うCPUでマルチコア作ってほしい。
200MGHくらいのCPUが30個くらいついていて、2G強のCPUが一個くらいのやつ。 タスクで重いやつを2Gのやつに振るとかの処理はOSなりPG任せにする仕組みで。 無理か?
- 431 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 09:33:39 ]
- 200MGHってのがどんなCPUか知りませんが、やってできないことではありません。
まぁ殆ど、意味はないと思いますが。
- 432 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 11:49:26 ]
- メガドラか
- 433 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 12:32:41 ]
- 200メガギガヘンリー
- 434 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 12:38:57 ]
- 200万ギザエッチ
- 435 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 12:57:02 ]
- 200マゾガチハーレム
- 436 名前:デフォルトの名無しさん mailto:sage [2007/07/17(火) 21:41:58 ]
- ダンゴさんのレスが望まれるところだ
- 437 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 01:21:03 ]
- 悪趣味だな。
- 438 名前:・∀・)っ-○◎● mailto:sage [2007/07/18(水) 02:51:49 ]
- だーんごー
だーんごー たーっぷりー だーんごー
- 439 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 11:04:21 ]
- >>438
おいこら、「つぶつぶだんご」ってフレーズが頭ん中でリピートしちまったじゃないか。
- 440 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 21:12:27 ]
- >438
それ、たらこだろ?
- 441 名前:デフォルトの名無しさん [2007/07/18(水) 23:45:04 ]
- キャッシュヒット率を多少改善するくらいしかやれることなんてないだろ
- 442 名前:デフォルトの名無しさん mailto:sage [2007/07/18(水) 23:50:16 ]
- イチローの出番だわな
- 443 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 10:24:49 ]
- >>430
ヘテロなマルチコアならcellがあるじゃまいか
- 444 名前:デフォルトの名無しさん [2007/07/19(木) 11:45:36 ]
- そうじゃなくてね、クロック数の低いコアを十数個のせて低コストのプロセス
なりスレッドを割り当てして、OSなどの重い処理専用のコアというふうにわけ れば効率よくマルチプロセス・スレッドができると思ったのよ。 >200MGH 200MHと間違えたよorz
- 445 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 16:09:31 ]
- >クロック数の低いコアを十数個のせて低コストのプロセスなりスレッドを割り当てして
重い処理をするコアが数パーセントの稼働率でその処理やればいいんじゃない? あまった時間はクロックダウンして各種電源OFFしてればいいし。 ってのはともかくとして、キーボードやスイッチ、外部デバイスの監視みたいな 低速簡単タスクはPICとか使ってやってるシステムもあるよね。
- 446 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 16:19:17 ]
- どうやって低コストかどうかを判断するんだ。
アプリ自体にプロセス毎の振り分けフラッグでも付いてないと適切に割り当てられんし、 低コストならメインCPUでやっちゃってもすぐ終わるから問題ないとも言える。 その考え方ならCPUコア分割よりIOコストをうまく割り振ってどれだけCPUをビジーに保てるかを 考えたほうが建設的だと思う。
- 447 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 21:07:21 ]
- 分散すれば仕事が早くなるってアホな幻想いだいてるから
間違った方向にいくんだよなぁ。 人も機械もどれだけパンクギリギリまで仕事詰め込めるかが命なのに
- 448 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 22:52:24 ]
- >分散すれば仕事が早くなるってアホな幻想
お前がアホなんだろw
- 449 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 23:32:58 ]
- 無理なものは無理
- 450 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:00:15 ]
- つまり馬鹿に仕事を割り振る方法を考える時間があったら
自分でやった方が速いってことだな。
- 451 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:42:36 ]
- 工場の単純労働者は1000人必要かもしれない
だからといって社長(+役員)は20人もいらない
- 452 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:50:41 ]
- でもXeon20個搭載可能なマシンあったら
夢がひろがりんぐだろw
- 453 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 00:58:53 ]
- >>452
それなんていう暖房機具?
- 454 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 01:32:05 ]
- 1UラックマウントのXeon*2搭載可能なサーバがあるから、10Uラックでいけるな。
暖房器具っつーか、騒音源だな。
- 455 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 02:00:49 ]
- 今なら1U3台で済むよ
QuadXeon 6個+ママン3枚でオケ
- 456 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 06:53:20 ]
- Xeon20個っていってるのに6個って、何考えているんだ?
まさか、Xeon20個ってコア数だとおもっているのか? おめでたいな。
- 457 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 09:27:02 ]
- 頭が4つもついてる役員は怖いです。
- 458 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 11:07:36 ]
- バスが飽和しそうです。
- 459 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 23:18:00 ]
- >>454-456
お前らブレードサーバも知らんのか? 6U で Xeon 20個 コア 80個ぐらいは積めるだろ。
- 460 名前:デフォルトの名無しさん mailto:sage [2007/07/24(火) 21:52:02 ]
- japan.cnet.com/news/ent/story/0,2000056022,20353310,00.htm
- 461 名前:デフォルトの名無しさん mailto:sage [2007/07/25(水) 00:49:04 ]
- GPL?
- 462 名前:デフォルトの名無しさん mailto:sage [2007/07/25(水) 00:55:38 ]
- 記事読んだ感じだと、例外付き GPL なんじゃないの
- 463 名前:デフォルトの名無しさん mailto:sage [2007/07/26(木) 00:26:11 ]
- LGPLだなたしか。
でも実際これら使っても効果出る範囲狭いみたいだぞ。
- 464 名前:デフォルトの名無しさん [2007/08/04(土) 20:15:15 ]
- タスク境界を自動で検出するTOOLないかね?
- 465 名前:デフォルトの名無しさん mailto:sage [2007/08/16(木) 15:32:15 ]
- foobarなどで複数のエンコーダを使って処理速度を上げてるってやつがあるけど
よっぽどうまく設計しないとハードディスクへのアクセスがボトルネックとなるじゃね。
- 466 名前:デフォルトの名無しさん [2007/08/21(火) 09:25:35 ]
- www.itmedia.co.jp/news/articles/0708/21/news021.html
- 467 名前:デフォルトの名無しさん mailto:sage [2007/08/21(火) 16:40:31 ]
- >>465
どういう計算だよw
- 468 名前:デフォルトの名無しさん [2007/08/21(火) 22:27:55 ]
- pc.watch.impress.co.jp/docs/2007/0821/tilera.htm
- 469 名前:デフォルトの名無しさん [2007/08/22(水) 13:13:48 ]
- www.atmarkit.co.jp/news/200708/21/tile.html
- 470 名前:デフォルトの名無しさん [2007/08/23(木) 22:07:23 ]
- pc.watch.impress.co.jp/docs/2007/0821/tilera.htm
- 471 名前:デフォルトの名無しさん [2007/08/31(金) 20:12:44 ]
- Wikiペディアより
>また、Windows Vista Home Basicおよび同Home Premiumではマルチプロセッサには対応しておらず マジか
- 472 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 20:16:45 ]
- >>471
そこでいうマルチプロセッサは、マルチソケットのことでマルチコアでは ないことは理解してる?
- 473 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 20:26:13 ]
- 一応理解している。
シングルコアをくっつけて作るデュアル環境と、ダイに複数コアをのっける ものの違いだと認識している。 多分
- 474 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 20:40:22 ]
- XP HOMEもそうだったでしょ。
物理CPUに対応してるのは1個まで。 物理CPU1個ならコアが4個あっても大丈夫(のはず) 物理CPU2個はXP PROFESSIONALから。4個以上は知らない。
- 475 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 22:48:30 ]
- それは違うぞ。
- 476 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 23:02:14 ]
- じゃあどうなの
- 477 名前:デフォルトの名無しさん mailto:sage [2007/08/31(金) 23:03:08 ]
- いや、自分でもよくわからないんだけどさ
- 478 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 00:01:00 ]
- >>473
ちがうよ。 マルチプロセッサってのは文字通り マザボに CPU を複数のっけることだよ。 ハードディスクを 2 個繋げたり メモリを 4 枚さすのと同じ。
- 479 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 00:20:57 ]
- www.atmarkit.co.jp/fwin2k/special/whatiswin2k_rev1/server4.html
Windows 2000 Server Advanced Server 最大SMP CPU数 4CPU 8CPU win64xp.impress.co.jp/change/index.htm Windows XP Professional Windows XP Professional x64 Edition 対応CPU数 2 2 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 ソケット コア数は4個だろうが8個だろうが全て認識するようです
- 480 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 08:45:16 ]
- コアが32個あるタスクメジャー見たなwwwwwwww
- 481 名前:デフォルトの名無しさん [2008/01/15(火) 17:42:48 ]
- 並列化・並列計算のスレってこの板には多分ここくらいしかないので、
ここで質問します。 太陽系の惑星の軌道を並列計算をするときに、 時刻tでの惑星の速度と位置のデータを 他のプロセスに渡して次の時刻(t+1)の速度と位置を計算させて、 全ての惑星の分を計算し終わったら次の時刻の計算を・・・ と繰り返す処理をPVM + C言語で組んでいるのですが、 どうもデータの送受信部分のコーディングがうまくいきません。 繰り返し1回目はちゃんと結果が帰ってくるんけど、 2回目は送信はできるけど計算結果が帰ってこない、 というような状況になっております。 並列計算で繰り返し処理を行う場合は データの送受信の処理はどのようにコーディングすればいいのでしょうか。 (作りかけのプログラムをどっかにうpしたほうがいいんですかね・・・?)
- 482 名前:デフォルトの名無しさん mailto:sage [2008/01/15(火) 17:56:30 ]
- >>481
MPIのスレがあるぞ
- 483 名前:デフォルトの名無しさん [2008/01/16(水) 19:20:30 ]
- >>482
そうなんですがMPI以外の話になっちゃうので 抵抗がありまして・・・
- 484 名前:デフォルトの名無しさん mailto:sage [2008/01/16(水) 20:30:46 ]
- 地球時間とか木星時間の一年周期で同期したらいいんじゃね
- 485 名前:デフォルトの名無しさん [2008/03/29(土) 13:31:27 ]
- cygwin+gccだとどのような方法がありますか?
- 486 名前:デフォルトの名無しさん mailto:sage [2008/04/06(日) 22:12:28 ]
- ない
- 487 名前:デフォルトの名無しさん mailto:sage [2008/04/07(月) 12:52:16 ]
- lam-mpiならcygwinにインスコできた。
mpichもたぶんできる。
- 488 名前:デフォルトの名無しさん mailto:sage [2008/04/08(火) 08:42:45 ]
- IntelのCt言語っててにはいるのかな?
- 489 名前:デフォルトの名無しさん mailto:sage [2008/04/21(月) 23:13:24 ]
- 「小飼弾のアルファギークに逢ってきた」っていう本に
Dave ThomasがErlangの本を書いているって書いてあったんだけど 詳細が分かる人いますか? 07年7月に出版予定とか書いてあったけど、どうもAmazonの洋書でそれらしいものがない。
- 490 名前:デフォルトの名無しさん mailto:sage [2008/04/21(月) 23:14:06 ]
- すみません。
誤爆しました。
- 491 名前:デフォルトの名無しさん mailto:sage [2008/04/27(日) 21:21:30 ]
- 128bit レジスタ を 8 コアで SSE 拡張として繋げて、
1024bit のベクトルプロセッサとして使える。 、、、とかだったら面白くなりそうなんだけどな
- 492 名前:デフォルトの名無しさん mailto:sage [2008/04/28(月) 13:11:09 ]
- >>491
どれかのプロセスがそれをやっている間他のプロセスが割りを食いそうだからやだ。
- 493 名前:デフォルトの名無しさん mailto:sage [2008/04/28(月) 18:17:35 ]
- >>491
逆に並列性が下がりそう
- 494 名前:デフォルトの名無しさん mailto:sage [2008/04/28(月) 21:44:59 ]
- 素朴な疑問だけど、これからはメニーコアの時代、とかいうが、
コア間で「人月の神話」と同じ問題は発生しないのかえ
- 495 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 09:07:34 ]
- する。
- 496 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 11:53:18 ]
- つーか、大昔からのマルチプロセッシングの課題が
いかにリニアにスケールさせるか、です。
- 497 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 14:01:25 ]
- それじゃ漠然としすぎて無意味だよ
- 498 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 14:08:39 ]
- 大昔からリニアにスケールさせるにはどうしたらいいかって話で
結局は個別対応になるから、一般論として本当に軽い話しかできない 古い記事だけどマルチコア、マルチスレッドで どこらへんに苦労したかっていうのは書いてあるけどほとんど一般論 www.4gamer.net/specials/capcom_x_intel/capcom_x_intel_01.shtml EfficientC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。 だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし 結局は本人の試行錯誤という。
- 499 名前:デフォルトの名無しさん mailto:sage [2008/04/29(火) 14:28:00 ]
- >>497
知りたいことの的を絞ってくれればある程度話ができるよ。
- 500 名前:デフォルトの名無しさん [2008/05/10(土) 13:46:08 ]
- mac osx ppc64 で tbb を使って遊んでみようと思ってます(当然シングルコアなので雰囲気だけ)
ところが、libtbb.dylibとlibtbbmalloc.dylib を入れてもリンクエラーが発生します。 自分でソースからビルドしてdylibを作り直してもダメ。 dylibの中をみてもそれらしいシンボル名がないようなんですが、どうすれば動くんでしょうか。
- 501 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 14:33:45 ]
- おおむね一年研究してみたが、マルチコア化でいちばん厄介なのは
1.どれだけスレッドセーフなコードを簡単に作れるか 2.どれだけスレッドセーフを意識しなくてもよくできるか の二点にかかっている、これに伴って スレッド化が問題を引き起こすのは、作る側、使う側の間で、仕様伝達がもつれてしまったり、 一旦スレッド化すると、非スレッドセーフに戻したり、逆に非スレッドセーフに作ったコードを簡単にスレッド化できない事で オブジェクト指向で言えば、オブジェクト間の結合がスレッドによってむやみに強められてしまう点がまずい。 スレッドセーフは、メソッドにつけられる属性の一つとして機能するが、言語機構てきに簡単には取り付けられない。 なにしろ、何につていスレッドセーフかという問題もあって厄介だ。 逆のこの点を解消すれば、むしろ色々な物(IO同期処理等)が統合できて便利だと思った。 『やりたいことの記述と、どう実装するかの記述を分離する事』が最も重要だ。 >結局は個別対応になるから、一般論として本当に軽い話 初めて見た時は不可能そうに見えたが、一般論化しないかぎり成功しない、そしてそれは不可能でもないと思った。 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。 一言でいえば、いかにサクッと書けるか書き換えられるか、同期が必要なデータが明白化できるかが、そのまま並列化の性能になってしまう。 並列化はパフォーマンスを求めるために使う技術だが、パフォーマンスを求ている内は使い物になりそうにない。 VBが、GUIのコードをあっさり書けるようして、実用的にしたように、マルチコア化も同様なものが必要でスケールとかは意識しても仕方がないと思った。 概念として重要そうなのは、C#やVBのLINQやHaskell等で実装されている遅延評価が使えそうだという点か。
- 502 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 15:17:55 ]
- CPU・・・衝突、不一致を嫌う設計
脳・・・衝突、不一致を積極的に利用 CPUの設計原理を変えずに、脳の真似をするのは難しい。
- 503 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 18:27:12 ]
- >>501
> 逆に、タスクシステムなどという事をやっているうちは全くモノにならないという点も見えてきた。 業務用ゲーム業界に職人技的に伝えられてきたというあの「タスクシステム」?
- 504 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 18:51:40 ]
- タスクシステムなんてこのWEB全盛時代にはもはや化石だなw
- 505 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 19:31:26 ]
- 並列化のキーワードは網羅って聞いたことがあるような。
例えばソートだと、順列(全パターン)を作ってそれが並んでいるか調べるだけでいい。 現在の手法は今までのアルゴリズムを並列化しようとしているからロックとかで問題になっているんでしょ? アルゴリズムを根本から変えれば良いと思うけど。
- 506 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 20:18:15 ]
- >>503
カプコンのMTフレームワークは使うかどうかはともかく、見ておく価値はあるよ。 watch.impress.co.jp/game%2Fdocs/20070131/3dlp.htm 十分とは思えないが、役に立たない理屈と違い実戦的な並列化手法の一つだから。
- 507 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 20:19:49 ]
- >>505
量子コンピュータ時代になれば、役に立つかもなw
- 508 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 21:15:20 ]
- >>507
ある程度コア数が大きくなったら役立ちそうだと思うけど 別に1パターン1コアに分けなくてもいいし。
- 509 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 21:59:00 ]
- >>508
> ある程度コア数が大きくなったら役立ちそうだと思うけど 算数からやり直した方がいいと思う。
- 510 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:18:15 ]
- >>508
たとえば1000の組み合わせの数を数えてみたらどうかな? n qubitに対して、並列度が 2^n である量子コンピュータなら 2^1000程度の並列度を持たせれば、その組み合わせ数にも打ち勝てる可能性はあるが、 10個や20個のコアでなんとかなるかな?
- 511 名前:デフォルトの名無しさん mailto:sage [2008/05/10(土) 23:58:22 ]
- あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。 アルゴリズムが分かりやすいし。
- 512 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 07:51:09 ]
- >>511
極めて単純なものだけに有効でしかないよ 総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。 宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。 そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。 量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、 自分たちが感知できない別の宇宙にコンピュータを配置する、 今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。 これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。 ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。 それにしても一番気になるのは計算機よりも並行宇宙そのものだ。
- 513 名前:デフォルトの名無しさん mailto:sage [2008/05/12(月) 21:09:31 ]
- 量子コンピュータを神秘視しすぎだろwww
- 514 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 09:02:31 ]
- >>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ? どうころんでも、どう解釈してもキモ過ぎだよ
- 515 名前:デフォルトの名無しさん mailto:sage [2008/05/13(火) 09:15:37 ]
- 量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。 キモいと言えばキモい性質ではある。
- 516 名前:デフォルトの名無しさん mailto:sage [2008/05/14(水) 03:50:53 ]
- 並行宇宙ワロタ
- 517 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 06:37:49 ]
- 並行宇宙ヤバイ
- 518 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:49:58 ]
- >>512マジキモイ
- 519 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 19:51:44 ]
- 2XXX年のオリコン一位
「並列宇宙」
- 520 名前:デフォルトの名無しさん mailto:sage [2008/05/16(金) 22:01:54 ]
- >>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか 量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。
- 521 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 01:31:05 ]
- Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。
- 522 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 03:24:15 ]
- 宗教の話は他でやってくれないか。
- 523 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 04:33:17 ]
- ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ
- 524 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 05:23:47 ]
- >>520
量子コンピュータが量子力学の正しさを証明しても 並行宇宙解釈が主流になる事は無いと思われ
- 525 名前:デフォルトの名無しさん mailto:sage [2008/05/17(土) 05:33:35 ]
- ここム板やで。
- 526 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 14:45:50 ]
- >>1
boinc環境を用意してねらーを煽る。
- 527 名前:デフォルトの名無しさん mailto:sage [2008/05/18(日) 19:38:01 ]
- 懐かしの宇宙ヤバイを思い出した。
- 528 名前:デフォルトの名無しさん [2008/05/29(木) 23:59:57 ]
- ちょっと、細かい質問なんだが、
tbbの本38ページに書いてある、粒度ってどういう意味なんでしょうか。 本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。 たとえば、2コアのCPUで1000回のループのを並列処理するときに、grainsizeを500にする、 4コアならgrainsizeを250にすることで、理想的にスケールするということなんでしょうか。 この本肝心なとこの訳が意味不明で困る。 ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか(TBBのもいい参考書だとおもいますけど。)。
- 529 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 00:11:11 ]
- >>528
その本持ってないから意味不明で困る。 処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。
- 530 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 00:16:56 ]
- >この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁
- 531 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 09:09:33 ]
- >>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ 環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。 使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。 それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。 >>530 ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎
- 532 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 09:31:16 ]
- >>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ 環境に応じて調整している間は現実性はないと思うな。 使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。 ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。 それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
- 533 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 12:28:09 ]
- 調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってw
- 534 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 13:41:29 ]
- >>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw 例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。
- 535 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 14:24:20 ]
- >>534
「複数のマルチスレッドライブラリが組み合わさった状態」 になったら「ショボイ開発」って思わなきゃダメだよ
- 536 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 15:42:06 ]
- 10000行で完成する程度のコードしか組んだことないんだなw
- 537 名前:匿名 [2008/05/30(金) 15:45:44 ]
- 並列・分散処理に関しては以下のホームページが参考になります。
主要な言語に対応したツールなどの紹介もあります。 www.cspjapan.org
- 538 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 16:46:39 ]
- >>537
宣伝でつか? マルチポストでやるのは、あまりイメージ良くないですよ。
- 539 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 16:51:46 ]
- >>537
ちらっと見ただけだけど、通信部分が浮いている感じがするな、もっと洗練できると思う。
- 540 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:00:24 ]
- グリッドコンピューティング?には合ってる部分もあるのかもだけど
昨今のマルチコア活用方向とは全く合わんのじゃ… 大体想定環境・状況が古すぎるような…
- 541 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:06:31 ]
- プロセス代数は基本だと思うし、オブジェクト間通信という考えの元でも問題はないと思う。
マルチコア活用を阻害している最大の要因はパフォーマンスではなくて 直感的に記述することや効率よく記述すること、デバッグを容易にすることが重要だという点に気付いているかが気になった。
- 542 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:11:11 ]
- もうひとつあるな、現行残っているシングルスレッドモデルで記述された大量のコードを徐々に移行していくための仕組みがいる。
- 543 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:42:51 ]
- >>534
想定しなくていいように作るもんだろ それに囚人のジレンマは場違いもいいとこ
- 544 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 17:58:10 ]
- >>532
> コードがスマートになる粒度にハードウェアを調節しないと駄目だ。 プログラマからするとソフトウェアもコードがスマートになるように作ってほしいですよね。 >>543 俺も思ったけど、Wikiみたら使い方あってるみたい。 > 囚人のジレンマ > 個々の最適な選択が全体として最適な選択とはならない状況の例としてよく挙げられる問題。
- 545 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 18:01:14 ]
- >>543
すべてのライブラリが自家製とかありえないだろ、ふつう
- 546 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 18:12:32 ]
- >想定しなくていいように作るもんだろ
想定しなくていいように作る=毎回開発でスクラップアンドビルド だが、良いのか?
- 547 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:10:39 ]
- >想定しなくていいように作る=毎回開発でスクラップアンドビルド
うわっバカだ
- 548 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 21:58:47 ]
- マルチスレッド並列化で解決すべき深刻な問題の一つだからな、保守性の無さと再利用性の低さは。
- 549 名前:デフォルトの名無しさん mailto:sage [2008/05/30(金) 22:18:08 ]
- >>537
今更CSP紹介されてもな…何十年前の話題だよ。 CSPを普通に実装するとプロセス間をデータが流れることになり、 キャッシュを越えるコア間のデータ転送が増えて、途方もなく 効率悪いと思うんだが。 その辺まで言及してくれればこのスレ的な話題になる。
- 550 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 08:31:32 ]
- >>548
> 保守性の無さと再利用性の低さは。 STM はその辺強いのかね
- 551 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 13:48:09 ]
- >>550
変な用語を使うのはヤメレ、シングルスレッドモデルといいたいのだろうが・・・ ちょっとでも触ればマルチスレッドを使った並列化の現状が論外な状態だと判るはず。 可能ならとっくに流行っている。
- 552 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 13:50:49 ]
- >>549
現在のプロセッサの最大の弱点はプロセッサ相対で低速なメモリーであって キャッシュ間の転送は、小さくはないが致命的でもない。
- 553 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 14:30:34 ]
- >>551
アフォか。Software Transctional Memoryだろが
- 554 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 14:56:15 ]
- >>552
一般論としてはそうだが例えばfork/joinはスティールされない限り 同じスレッドで実行することでデータ転送を減らすよう考慮されてる スティールされるのが古いタスクからなのも同じ理由 それに比べてCSPはどうだ?
- 555 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:16:47 ]
- >>554
>fork/joinはスティールされない限り同じスレッドで実行することでデータ転送を減らすよう考慮されてる SMT(ハイパースレッディング)が登場してから、おかしな対処をしないと性能がでなくなって必ずしもそうなっていないよ、今は。
- 556 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:24:58 ]
- >>555
そうか?tbbやjsr166yのfor/joinは>554で書いたようになってると理解してるが。 ソースキボン
- 557 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:25:21 ]
- しかしまぁ、オペレーションズ・リサーチは情報系出身なら常識だろうと思うが、こういった基本すら知らない奴はどうしてくれるかなぁ
ゲーム理論や囚人のジレンマも知らないというのはどうかと思うんだ・・・
- 558 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:28:29 ]
- >>556
Core 2 Quadマシンと、Windows Vista 買ってきて、ひとつアプリを走らせろ そして、タスクマネージャーなり、ガジェットからCPUメーターをダウンロードして睨めっこをするんだ そうすれば、ソースも必要ないし説明するまでもない筈。
- 559 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:36:48 ]
- >>558
まさかProcessor affinityの話をしてるのか?
- 560 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:37:45 ]
- >>559
謎用語出す前に、基本を勉強しとけ
- 561 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:43:23 ]
- >>560
謎用語て…単なる煽りか?それなら消えてくれ 煽りじゃないなら>558とjork/joinのタスクスケジューリングの関係を説明してほしい
- 562 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:44:11 ]
- ソースだせと、なぞ用語で捲し立てるのが趣味なら消えてくれ
- 563 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:46:20 ]
- >>557
常識だと思うけど、大学卒業して10年の俺はさっぱり覚えてないw
- 564 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:46:37 ]
- 頭の悪いGKがいる、絶対いるw
- 565 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:56:40 ]
- >>562
Processor affinityはWindowsでもLinuxでも商用UNIXでもAPIになってる 特定のプロセス/スレッドを特定のCPUに割り当てられやすくするもの。 fork/joinのスケジュールがスレッドのローカルなキューからタスクを 取ってくるのも新しいタスクをキューの先頭に入れるのも 他のスレッドからキューの後ろからスティールするのも Processor affinityの元でスレッドが同じコア上で実行される場合に キャッシュが効率的に使われることを目指していると俺は理解している。 さて、>555や>558について説明してもらえないかな
- 566 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 18:58:27 ]
- >>565
CPUメーターみてみなよ、OSが勝手にスケジュールを調整してこちらの意向を無視している。
- 567 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:03:08 ]
- >>566
そのアプリがSetThreadAffinityMask読んでないなけだろ
- 568 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:04:05 ]
- >>567
単に、特定アプリに依存すると障害が多いからMSが調整しただけかと
- 569 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:08:58 ]
- >>568
意味が分からない SetThreadAffinityMaskを呼び出していないスレッドをOSが勝手に スケジュールするのは当然のことだ お前さんの言ってるアプリはSetThreadAffinityMaskを呼び出してるのか? 呼び出してないアプリでCPUメーター見ても全く意味がないんだが Processor affinityを知らなかっただけじゃね?
- 570 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:10:20 ]
- そっちの言っている事こそ意味不明だわw
- 571 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:12:50 ]
- じゃあさ、>558で「ひとつアプリを走らせろ」のアプリが
SetThreadAffinityMaskを呼び出してるアプリのことかどうかだけ答えてくれ yes/noだけでいいからさ
- 572 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:14:01 ]
- こんなの、つまらないコード書いて、パフォーマンス確認目的でパフォーマンスカウンタ見れば一発なんだが・・・
なんでこんなややこしい話が登場するのかと・・・
- 573 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:14:46 ]
- バカ相手にするのは疲れる
- 574 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:22:31 ]
- >>572
ややこしい話はしていない そのつまらないコードでSetThreadAffinityMaskを呼んだのかどうか、それだけだ。 これもyes/noだけでいいから答えてくれ
- 575 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 19:31:59 ]
- SetThreadAffinityMaskじゃなくSetProcessAffinityMaskなら
タスクマネージャーから設定できる。 プロセスタブでプロセスを選んで右クリック、関係の設定でCPUを選ぶだけ
- 576 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:07:00 ]
- 逃げたようだな。結局Processor affinityすら知らなかっただけだけか
何が「基本を勉強しとけ」だよw きっとfork/joinも何のことかわかってないんだろうな…
- 577 名前:デフォルトの名無しさん [2008/05/31(土) 20:31:28 ]
- 割り込んでごめんなさい。
windows 2k serverってマルチコアに対応してますか? windows serverは全部対応してるって記事をネットで見たけど、 記事自体、いまいち信用できないんです。
- 578 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 20:57:52 ]
- 雑誌記事が信用できずに、誰の発言かもわからない
掲示板の話を信用するんですか?
- 579 名前:デフォルトの名無しさん [2008/05/31(土) 21:16:49 ]
- >>578
どっちもどっちですが、広告だらけのブログで「対応してる。」って言われるのと比べるなら、 まだ、ここのほうが信用できます。 「ここで公式に書いてるよ!」みたいなレスがあればなぁなどと思った次第です。
- 580 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 21:31:15 ]
- それプログラミングと関係ないだろスレ違いだしageんな
- 581 名前:デフォルトの名無しさん [2008/05/31(土) 22:21:36 ]
- >>578
P4-2.4Cで2個見えてるから、2個までは対応してると思うよ #手元に2コアまでしかないからそれ以上は分からんw
- 582 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:25:52 ]
- 初心者ですまんが
Pg作るのにマルチコアなんて気にする必要アンの? いいところスレッド処理とか流せば しかたねえな ってかってに動いてくれそうだけど
- 583 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:35:21 ]
- そのいいところってのが難しいんじゃない?
いままでみたいな粗い粒度のスレッドの使い方じゃなくて、もっと積極的に 例えば単なるクイックソートを2〜4スレッドで並列実行して高速化しようとか、 そういうのを考えるんじゃないかなたぶん
- 584 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:35:59 ]
- >>582
ここは君が来るところではないんだよ。 ここはデュアルコアならシングルコアの2倍、クアッドコアなら4倍の パフォーマンスを目指すスレ。 今のところ有益な議論は一度もないけどな。
- 585 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:54:45 ]
- Processor affinityも知らないSoftware Transactional Memoryも知らない
wait freeやlock freeの話も出ない 有益な議論のしようがないなw
- 586 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:56:05 ]
- >>584
キャッシュに入るような小さな処理から頻繁にメモリアクセスが必要な処理をした際 実際のパフォーマンスを比較したものってどっかにないの?
- 587 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:03:12 ]
- マルチスレッドスレと話題かぶるからなぁ
- 588 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:17:48 ]
- >>582
俺も気になった。 winのapiには無いと思う。 2つのスレッドを2つのコアにわけるなら話も早いけど、 1つのスレッドを2つのコアにわけると、なんか、戻りとか処理のオーバーヘッドがでかそう。 win上で動くプログラムからそこを制御できるかも、よくわかんないし。 と、初心者は思うのでした。
- 589 名前:デフォルトの名無しさん mailto:sage [2008/05/31(土) 23:52:50 ]
- 初心者だと思うなら、「winのapiには無いと思う。」なんてろくろく調べもしないで
レスするなよ。
- 590 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:07:59 ]
- マルチコア対応apiはwinにはないね。未熟なOSなのかも。
- 591 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:18:47 ]
- 同一ソケット上のマルチコアに特化したAPIはないわな。未熟だわなwww
- 592 名前:デフォルトの名無しさん [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の判断だけど、多分2つCPUあるときと同じだから、win2kでも大丈夫な気がする。 こっちはあんま自信ない。 以上、>>577の自己回答でした。
- 593 名前:デフォルトの名無しさん [2008/06/01(日) 00:22:55 ]
- >>589
嫌味な上級者は、絶対何も言わないんだよな。 さっきからずっと、むかつくレスしてんのこいつだろ? 上司でたまにいるんだよ。 知ったかして、具体的に何も言わないで、誰かが言ったら便乗するやつ。
- 594 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:27:06 ]
- そりゃ、言うべきじゃない時を心得てるのが上級者というものだからなあ
- 595 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:31:12 ]
- >>592
MSDN見たなら「参照」も見るといいよ
- 596 名前:デフォルトの名無しさん [2008/06/01(日) 00:43:55 ]
- >>592
あんまり調べる気無い。 何か映像関係の高速処理組むなら別だけど予定もないし。 スレッド、プロセス関連は完全に2、3継承のクラス化しちゃってるし、 いまさらOSの判断以上の速度が出るように直す気はない。
- 597 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:44:33 ]
- 時代がマルチコアなのになぜ対応apiがないのか?
これはMSの怠慢ではないだろうか 高いOSライセンス代(1台につき1万〜3万)を定期的(5年程度)に払っているというのに ひどい話だ
- 598 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 00:51:54 ]
- >>597
マルチコア対応APIって具体的にどういうものよ?
- 599 名前:デフォルトの名無しさん [2008/06/01(日) 01:06:17 ]
- >>597
だからwindowsにもあるって。 プロセッサを直接指定できるapiが。 やっぱNT系のカーネル作った連中は偉いわ。 おれもまだまだ2kで行く。
- 600 名前:デフォルトの名無しさん mailto:sage [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は既にある。
- 601 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:12:08 ]
- マルチダイもマルチコアに含めてるしな、、、思想的には
ていうか、やっぱまだ2kって需要あるかなー? 今新規にフリーソフト作ってるが、どこまでサポートするか悩む
- 602 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:15:22 ]
- >>599
Processor affinityはDECのVMSの時代からある。 WindowsNTと作った連中は同じだけどなw
- 603 名前:デフォルトの名無しさん [2008/06/01(日) 01:19:14 ]
- >>601
俺、フリーソフトは、2kで作って、xpで軽く動かしてテスト終わり。 2kで動いて、xpで動かなくなったことはない。 基本、Direct X関係に気をつけるだけ。
- 604 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:22:24 ]
- CPUが別パッケージかオンダイかを気にするような場面には出くわしたことないなあ
キャッシュの奪い合いとか同期の頻度とかが問題になるのかな? むしろhyper threadingが特別だったんじゃないかと思う
- 605 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:24:49 ]
- Win32のSetThreadAffinityMaskはaffinity maskがDWORDで32bitしかない
64/128/256のSuperdomeはOSからは256プロセッサに見えるんだがどうするんだ?w
- 606 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:27:16 ]
- hyper threadingは鬼門
- 607 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 01:29:44 ]
- >>606
Pen4のHyper Threadingだけが鬼門? SMT全般が鬼門? ちょっとだけPower使ったときは何もなかったけどな
- 608 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:01:39 ]
- >>605
いずれSEtThreadAffinityMaskExが出来るだけよ
- 609 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:05:55 ]
- >>608
いずれってかSuperdomeにWindowsが乗ってから5年以上経ってないか? Windows乗ったSuperdome俺は見たことないけどw
- 610 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:08:16 ]
- テキトウに仮想化でもしたほうが効率よさそうな気が
- 611 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 02:14:38 ]
- >>610
それは現実的すぐるw とりあえずタスクマネージャーはこうなる ttp://www.microsoft.com/japan/sql/images/ssj/ki03_02_l.jpg これで「関連の設定」は64CPU設定できるのか? つかItaniumだから64bit Windowsか…
- 612 名前:デフォルトの名無しさん mailto:sage [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 );
- 613 名前:デフォルトの名無しさん mailto:sage [2008/06/01(日) 03:25:02 ]
- >>607
606じゃないけど、HTは面倒な存在じゃない? 普通のマルチプロセッサなら異なるプロセッサ間で同じキャッシュラインに アクセスしない方が良いが、HTの場合は逆でしょ? ベンチ取ってないんで、どのくらい影響があるのかは具体的には分からんが。
- 614 名前:デフォルトの名無しさん [2008/06/01(日) 03:36:55 ]
- menndouda
- 615 名前:デフォルトの名無しさん mailto:sage [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やキャッシュ共有のコアを ノードと見なすことができると、細粒度並列実行で効果的なヒントを 与えられるかもしれない。
- 616 名前:デフォルトの名無しさん [2008/06/03(火) 13:35:38 ]
- マルチコア対策としてこんなのがあります。
www.axon7.com/ また、これも参考になります。 www.cspjapan.org/
- 617 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 13:45:14 ]
- >>616
>537
- 618 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 13:58:55 ]
- マルチプロセス、マルチスレッド、マルチコア、マルチプロセッサ、SMT、メモコン共有、キャッシュ共有、演算器共有。
これが複合的に絡んだときの最適化は複雑すぎる。
- 619 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 14:44:35 ]
- >>617
>549
- 620 名前:デフォルトの名無しさん mailto:sage [2008/06/03(火) 14:47:41 ]
- 間違えた、>619は>616へ。
>>618 それをコンパイラで成し遂げることが前提のItaniumは不可能に挑んだようなものだな
- 621 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 13:51:00 ]
- マルチコアは、今までのソフトウェア技術を台無しにしてくれる素晴らしい技術だよね。
これからはソフトウェアとハードウェアの境界が無くなって、 プログラムを作るのは、より一層大変になる。
- 622 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 14:08:33 ]
- ハードとソフトが緊密に絡む領域はこれまでもあったんだけどな
無停止システムとか
- 623 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 14:08:49 ]
- 今までのマルチプロセッサ向けのソフトウェア技術の延長にあるから
台無しという事は無いよ。もう何十年も研究が続けられている分野だ。
- 624 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 15:54:23 ]
- 何十年も研究とか、無駄の極地だねwww
- 625 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 16:04:53 ]
- ロックフリーのアルゴリズムやトランザクショナルな変数アクセスが
もっと一般化してくれば、そんなに恐れる物でもない気がするけどね
- 626 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 17:43:57 ]
- >>621
いったい何に怯えているんだろうか
- 627 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 18:51:05 ]
- まあそりゃ単一スレッドで速くなるほうがありがたいけどな
- 628 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 19:06:01 ]
- 荒い粒度の並列化や、ベクトルの並列処理はとっくに研究され尽くされてるけど、
その中間が非常に厄介。 しかし、これからは単一スレッドでは速くならないわけだから、それをやらないといけない。
- 629 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 19:53:53 ]
- ループを展開する自動並列化くらいはインフラとして整備して欲しいね
- 630 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 23:02:40 ]
- >>629
自動じゃなくてもparallel array使えばおk
- 631 名前:デフォルトの名無しさん mailto:sage [2008/06/05(木) 23:56:43 ]
- >>628
divide and conquer work stealing fork/join parallel array
- 632 名前:デフォルトの名無しさん mailto:sage [2008/06/07(土) 23:32:29 ]
- 遅レスだが
ハードウェア・ソフトウェア協調設計等は組み込みでは昔からよく見られるんじゃないか? まあ、シミュレーター等の開発統合環境が整えられているなら最適化はむずかしくないよ。 ただ工数と時間と労力が膨大に費やされていくだけで
- 633 名前:デフォルトの名無しさん mailto:sage [2008/06/13(金) 19:49:18 ]
- 組み込みの場合は、環境のプロセッサ数やプロセス数は固定されてるから、難易度は低いんじゃないかな。
PCの場合は、対象のプロセッサ数は予想できないし、同時にどんなプロセスが動くかも分からないから、難易度が高い。 というか、PCの場合は、何らかの動的最適化メカニズムが必要になるんだよね。 pc.watch.impress.co.jp/docs/2008/0613/hot554.htm インテルはCを拡張してJITコンパイラで最適化する研究をしてるようだけど、 実用化はまだまだ先だよな。
- 634 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 06:28:11 ]
- 1.マルチなんたらとか並列化とか、なにも考えずに作る。
2.あとは開発環境とOSがなんとかしてくれる。 3.下手なこと考えるより、そのほうが最終的に効率が良い。 こういうのが理想なんだけどなぁ…。
- 635 名前:デフォルトの名無しさん mailto:sage [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の言語仕様の 枠組みでスケーラビリティを上げるのは難しい」ため、マルチコア、 マルチプロセッサといった密度の高い並列化よりも、クラスターや グリッドのようにネットワークで接続された複数ホストによる並列化を 実現していくのがいいのではないかという。
- 636 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 10:51:06 ]
- >>634
それ何て第五世代 >>635 むしろマルチコア関係なくね?
- 637 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 10:59:42 ]
- マルチコア向けの最適化はしない方向だ、という内容だな。
- 638 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 16:27:58 ]
- 今後もRubyのスレッドはマルチコアを使いこなすようにはしない方針ということだな
- 639 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 16:42:50 ]
- Rubyなんて並列化のこと何も考えてないじゃん。
書いててわくわくするとか日和ったこと言ってる言語では到底無理。
- 640 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 20:49:23 ]
- 並列化に興味をもったRuby使いはErlangあたりに移行するのだろうか
- 641 名前:デフォルトの名無しさん mailto:sage [2008/07/06(日) 23:42:11 ]
- アルファブロガー(笑)あたりに煽ってもらえばイッパツよ
- 642 名前:デフォルトの名無しさん mailto:sage [2008/07/07(月) 14:51:27 ]
- jruby
- 643 名前:デフォルトの名無しさん mailto:sage [2008/07/12(土) 12:34:27 ]
- Erlangが騒がれてるのは副作用がないのとメッセージングがあるからなの?
ほかの言語でも多少見苦しくなっても同じことはできんの?教えてエロイ人。
- 644 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 10:33:33 ]
- >クラスターや
>グリッドのようにネットワークで接続された複数ホストによる並列化を >実現していくのがいいのではないかという。 ハードは明らかにマルチコアに進んでいて、 サーバも集約統合が進んでいるというのに。 Rubyみたいなソフト側が手前の都合だけで 「いいのではないか」とかいって方針だしても何の意味もないわけだが。 誰もそんなハード持ってません。 今のハードにあってません。 ってなるだけ。
- 645 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 17:36:31 ]
- なに、寝ぼけたレスしてるんだ?
>>644 は、Ryby という新言語について語っているんだぞ。
- 646 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 19:45:47 ]
- >>645
誰に言ってるの?
- 647 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 20:28:00 ]
- なに、寝ぼけたレスしてるんだ?
>>644 は、Ruby という言語について語っているんだぞ。
- 648 名前:デフォルトの名無しさん mailto:sage [2008/09/06(土) 20:50:57 ]
- なんだ、キ印か。
- 649 名前:デフォルトの名無しさん mailto:sage [2008/09/27(土) 22:48:29 ]
- >>644 って、Googleのサーバーとか、AmazonのEC2とか、分散環境が流行ってるのを知らないのか。
サーバーの集約統合が進んでるのは、既存のサーバーや負荷の低いサーバーでしょ。
- 650 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:23:48 ]
- 分散環境が流行ってるって…
すごい規模なんだからどっちにしても分散が必要なのは当たり前。 googleなんかは2003年の時点でこれからはマルチコアみたいなこと言ってるぞ。
- 651 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:40:39 ]
- 実際流行ってるんだけどなぁ。
クラウドとかいうキーワードでぐぐってみりゃわかると思うよ。 実効性はともかくね。
- 652 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:44:47 ]
- クラウドが流行ってるってのはSOAが流行ってるってのと
どっこいどっこいだな。 ごく一部で当たり前になってるのと広く使われてるのとは 全然違ってて、どっちの話をしてるかがズレてるんだな。
- 653 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:49:52 ]
- P2P→グリッド(言い換え)→クラウド(言い換え2)
- 654 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:50:04 ]
- オフコン時代の鯖だと鯖っていえば特定の対応関係になってたのが
OOのポリモフィズムみたいな多態になっただけだ C<->Sの関係が1:1だったのが C<->Sの関係がN:Mになっただけだ SOAはC<->Sの関係がN:1だったがな たしたことない。言葉変えて変化を促そうとしている単なる言い換えだ 詐欺の一種だ
- 655 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 17:56:49 ]
- クラウドとマルチコアって関係ないじゃん
- 656 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:12:59 ]
- まあ関係はないね
ハードの保守性とソフトのスケーラビリティを考えて、 マルチコアのマシンを仮想化してクラウドにするみたいな 話は聴いた事あるけど >>654 ハイプで成り立ってる所も大きいから、そんなもんかと www.atmarkit.co.jp/aig/04biz/hypecycle.html
- 657 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:41:15 ]
- とりあえずクラウドはスレ違いだろ
並列化の粒度が違う。クラウドは祖粒度、こっちは細粒度 ネタがないから構わんけど
- 658 名前:651 mailto:sage [2008/09/28(日) 18:45:37 ]
- >>652
どっこいどっこいというか、いままでSOAをかついでたところが、クラウドを担ぐようになってる。 SOAのように、クラウドは流行っている。まあそういう意味だ。 この件は、これで。
- 659 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:52:32 ]
- すかしっ屁こいてクライアント騙すのがクラウドなのか?
- 660 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 18:59:16 ]
- そう思う奴はいつまでも足踏みしてればいいのさ
- 661 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 19:07:46 ]
- >>657
×祖粒度 ○粗粒度
- 662 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:04:14 ]
- クラウドもSOAもわかってないやつ多すぎ。
そんなやつらがマルチコア云々なんてしょーもねー。 せいぜい単純労働者としてコキ使われてなw
- 663 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:08:22 ]
- どっちもバズワードなんだから分かっているという方がおかしい
- 664 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:36:35 ]
- バズワード自体がバズワードというパラノイア
- 665 名前:デフォルトの名無しさん mailto:sage [2008/09/28(日) 21:46:40 ]
- バズワードを使ってる人間はバズワードかどうかなんて気にしていないから、
一回りして結局おk
- 666 名前:デフォルトの名無しさん mailto:sage [2008/09/29(月) 17:24:22 ]
- >>658
SOAと普及でぐぐると ・普及が進まない ・普及促進 ・普及狙う ・普及を目指す ・普及を後押しする こんなんばっかですけど? 流行ってるけど普及しない。笛吹けど踊らずw
- 667 名前:デフォルトの名無しさん mailto:sage [2008/09/30(火) 01:37:12 ]
- クラウドはどうかと思うが、分散は物理的な話でもあるし必要なところには普及するんじゃないかな。
CPUでの並列だと限界が低いし拡張も難しいから、>>656の言うようなマルチコアマシンの仮想化で分散ってのが現実的ではないだろうか
- 668 名前:デフォルトの名無しさん mailto:sage [2008/09/30(火) 07:01:26 ]
- つまり金融工学みたいな
もんですね
- 669 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 18:54:26 ]
- 「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
www.computerworld.jp/topics/cloud/123069.html
- 670 名前:644 mailto:sage [2008/10/01(水) 20:30:34 ]
- 644ですが普段アーキスレとかに書いている身からすると、
このスレの住人はレベルが低すぎます。 キミらが並列化について語るのはまず無理。 チップあたりの性能をあげられなくなったら、 分散処理でも同一コストで性能あげられないの。 Rubyの件はいかにもソフトしかしらない人向けの 苦しいいいわけだなあと。
- 671 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 20:51:50 ]
- 自分以外みんなバカ症候群
- 672 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 23:06:07 ]
- ひんと: 賢い奴はこんなスレの住人なんて相手にしない
- 673 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 00:04:30 ]
- レベルが低過ぎてどこを縦読みすれば良いのか分からないや
- 674 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 00:21:48 ]
- アーキスレってどこ?
殴りこみかけてくる
- 675 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 00:59:37 ]
- 残念だけど、現状ではマルチコアってサーバサイドや一部の
embarrassingly parallel な処理以外では絵に描いた餅だよね。 デスクトップ機でクアッドコア以上のプロセッサが必要な 場面は思い付かない。それこそハード寄りの知識を持っていない、 スレッド周りの実装の知識も無い様なプログラマが、難しい事を 考えずに処理性能を出せる仕組みが欲しい物だね。fork/join でも ヘテロなマルチコアでも何でも良いけど。
- 676 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 01:16:48 ]
- 後はトランザクショナルメモリと投機的実行も期待してるけど
なかなかこういうのは普及しないねえ…
- 677 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 01:20:49 ]
- ゲーム機でやってるじゃん
- 678 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 02:33:49 ]
- >>676
投機的実行ってRockのスカウトスレッド? 命令レベルの投機的実行と紛らわしいから用語は分けたいな 同時投機スレッド(Simultaneous Speculative Threading)とかな トランザクショナルメモリはどうかねー RockのHTMじゃアプリケーションレベルのトランザクション 扱うのは無理だしSTM組み合わせるとオーバーヘッドが大きすぎて 性能出ないと予想してる つRockの出荷来年の後半とか遅れすぎだろjk
- 679 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 20:15:08 ]
- 今普及しているデュアルコアマシンみたいな感じで
6 core のマシンが一番売れ筋のマシンになったら プログラマはどうすればいい?
- 680 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:08:30 ]
- Vistaをお勧めする
あとセキュリティソフトを3つぐらい重ねがけ これで万全
- 681 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:30:33 ]
- >>674
CPUアーキテクチャについて語れ Part.12 pc11.2ch.net/test/read.cgi/jisaku/1219884494/ 最近は常駐コテの意地の張り合いばかりでつまらないくなってきてるけど アーキテクチャスレは↑ 普段は名無しだが、MACオタ(翻訳)などは漏れ。 がんばって殴り込みに言ってくれや。
- 682 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 21:43:42 ]
- >>681
なんでこのスレ来てるの?
- 683 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:18:05 ]
- >>681
2chらしいスレだなw 40 名前:Socket774[sage] 投稿日:2008/08/29(金) 02:47:03 ID:Yk6PbdtE ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします とか書かれててワロタ お前そんなに態度悪いのかよw
- 684 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:36:01 ]
- ダンゴさんそこでがんばってたのか
お似合いだなw
- 685 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:43:59 ]
- せっかく収まるところに収まってるのに煽らないでくれ。頼むから。
- 686 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:45:17 ]
- 644みたいな状態って、自分の専門は知ってるんだけど他のことは知らなくて、自分の知らないことはたいしたことないって思ってるだけなんだよね。
というか、自分が他のことを知らないことを知らない。 だから、「このスレの住人はレベルが低すぎ」とか言っちゃう。
- 687 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:48:56 ]
- でもまぁ、このスレのレベルが低いのは事実だろう。
レベル高い議論って一つでもあったか?ないよな。そういうことだ
- 688 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 00:53:53 ]
- マルチコア用のテンプレートライブラリを活用しているという話を聞かないね
良さげなのにググっても実際に使っている例が殆ど出て来ない C++ の人気が無いのかテンプレートが嫌われてるのか… www.threadingbuildingblocks.org/ spc.unige.ch/mptl sourceforge.net/projects/rpa www.extreme.indiana.edu/hpc++/docs/overview/class-lib/PSTL/
- 689 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:26:23 ]
- ライブラリの話はマルチスレッドスレがあるからなあ
このスレいらない子なんじゃ…
- 690 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:39:29 ]
- >>687
「住人はレベルが低すぎ」などと書いて無用に荒らすのが一番レベル低いがな。
- 691 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 02:36:30 ]
- >>689
要らなかったらスレが亡くなるだけだから気にしなくておk
- 692 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 03:39:27 ]
- >>689
マルチスレッドとマルチコアでの並列化は違う。
- 693 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:03:36 ]
- >>692
どう違うか語ってもらおうか
- 694 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:06:23 ]
- マルチスレッドは、タイムスライスで同時に動かなくてもおけ
- 695 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 04:31:02 ]
- マルチスレッドが並列に動かなくていいわけないだろ
マルチコア以前からマルチプロセッサは当たり前にあるんだしよぉ 本気でレベル低いなここ…
- 696 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 05:34:37 ]
- ・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできなくてもマルチスレッドは可能ってことわかってるのかな?
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。
- 697 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 07:28:21 ]
- windowsもクラウドが標準になるんだな
japanese.engadget.com/2008/10/01/os-windows-cloud/
- 698 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 10:41:52 ]
- >>696
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできない時のマルチスレッドとマルチコア/マルチプロセサでのマルチスレッドじゃ状況が違うってことわかってるのかな? しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。 >>692 そもそも、マルチコアとマルチスレッドを比較するなよ。
- 699 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 10:53:10 ]
- >>698
おいおい、状況は違うのは分かるが、プログラムは同じにしとかないと まずいだろ。 どこかのエンコソフトみたいにCPUのコア数によって使うルーチンを切り替える ようにするなら話は別だが。
- 700 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 11:50:27 ]
- 誰もプログラムを別にするとかなんて言ってないけど?
状況が違うと言うのはシングルコア and シングルプロセサで問題ないプログラムでも マルチコア or マルチプロセサで問題が発生するケースがあるってだけ。 種々の要件によって、その状況によってプログラムを切り替える実装はあると思うが、 それはもっと条件を限定しないと議論できない。
- 701 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:03:57 ]
- デッドロックとかレース状態とかそういう次元の事かな。
確かにシングルコアでは問題ありとしながら問題が潜在化してたものが マルチコアにした途端に顕在化する場合はあるね。
- 702 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:37:48 ]
- >>701
マルチスレッドプログラミングとしては単なるバグじゃん
- 703 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:38:00 ]
- > 確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
> マルチコアにした途端に顕在化する場合はあるね。 そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル プロセサではあり得ない問題」のことだよ。
- 704 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:39:40 ]
- >>703
それはクリティカルセクションを入れるのが当たり前だろ
- 705 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:40:56 ]
- >そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
>ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル >プロセサではあり得ない問題」のことだよ。 アトミック操作でないのにロックせずに破壊した場合プログラマの責任だと思うが。
- 706 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:42:23 ]
- >>703
そんなバグ埋め込んでマルチスレッドとか恥ずかしいぞ
- 707 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 12:43:53 ]
- >>703
もうちょっとOS関連の本を読んでマルチプロセス/マルチスレッドに ついて勉強してから書いた方がいいよ。恥かくだけだぞ今のままじゃ。
- 708 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:08:13 ]
- >>698
そもそもというなら、マルチスレッドとマルチコアの話は、 >>689に言ってくださいな 「マルチスレッドが並列に動かなくていいわけないだろ」とか言っておいて逆切れせずに。
- 709 名前:689 mailto:sage [2008/10/03(金) 13:38:17 ]
- >>708
比較なんかしてないぞ マルチスレッドがマルチコア環境で正しく並行動作するのは当然 だからライブラリの話はマルチスレッドスレの方がそれなりに議論してて 適切だろうってことだ マルチスレッドスレを並行動作しなくていい話題に限定したら 糞スレ確定で速攻落ちるぞw
- 710 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:44:20 ]
- 同じ変数を複数スレッドで更新する可能性があるなら、UP/MPに限らずバリア入れる。
更新するのが一人だけだったら、ちょっと考えてから決める。
- 711 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:44:22 ]
- そういう話は、その時点でやってくださいな。
あと出しで切れるのカコワルイ
- 712 名前:711 mailto:sage [2008/10/03(金) 13:44:54 ]
- >> 709 ね。
- 713 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 13:49:36 ]
- >>711
どこが後出し?w
- 714 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 17:59:44 ]
- >>704
そもそもクリティカルセクションをどう構成するかと言うレベルの話だから、 君には用はないので当分 ROM っててくれ。 >>705-706 シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。 マルチコア/マルチプロセサではちゃんと動かないから良くないコーディングと 言うならまだわかるが。 >>707 どこがどうおかしいかちゃんと指摘してくれ。 まさか、>>705-706 の的外れの指摘のこと言ってるのか? (w
- 715 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:19:54 ]
- >>714
アホですか RISCはロード/ストア命令とモディファイ命令を1命令で実行できない 物があるのでアトミックではない場合がある
- 716 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:20:58 ]
- つーか明らかな自分のミスを認められないグラマって
必要ないな。 こういう奴がいると絶対にプログラムにバグを入れてくれる。
- 717 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:28:36 ]
- そろそろダンゴさんがピシっと〆めてくれそうだ
- 718 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:32:18 ]
- つかシングルコアでも他デバイスがDMAしてきたらアトミックにならんやろ
メモリにアクセスするプロセッサがひとつだけっていつの話?
- 719 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:33:29 ]
- Java のでも GCC 組み込みのでも、OS ネイティブのでも良いけど、
アトミック命令ってみんな使ってるの?
- 720 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:53:25 ]
- 排他やると暗黙的に使われるんじゃね
- 721 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 20:56:23 ]
- 無意味な連番つけるときに AtomicInteger を使ったことはある
- 722 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 21:03:47 ]
- AtomicReferenceFieldUpdaterは友達
- 723 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 21:41:05 ]
- レベルの低いスレ/話題は伸びるのが速い。
- 724 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 21:49:12 ]
- レベルの低い話題に詳しそうだな
- 725 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:04:26 ]
- >>715
> RISCはロード/ストア命令とモディファイ命令を1命令で実行できない > 物があるのでアトミックではない場合がある そんなプロセサにメモリに対する inc 命令なんかあるのか? あるんならそのプロセサの型名書いてくれ。 >>716 「明らかな自分のミス」ってどれのこと? ちゃんと指摘してくれって書いてあるのに指摘できないの? >>718 ああ、DMA はあるな。 ただ、通常の DMAC はレジスタで制御するから、メモリ上で排他なんかしないでしょ? > メモリにアクセスするプロセッサがひとつだけっていつの話? 今でも普通にあるよ。PC しか眼中にないの?
- 726 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:07:57 ]
- また前提が増えたな。
DMA無しだとさ。
- 727 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:19:48 ]
- >>718見て、Windows 98で386のときのInterlockedIncrementは、
デバイスドライバ内で割り込み禁止してincを実行するって話を思い出した。 blogs.msdn.com/oldnewthing/archive/2004/05/06/127141.aspx
- 728 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:22:31 ]
- >>726
また? DMA 以外で増えた前提って何のことだ、ちゃんと書いてくれよ。
- 729 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 22:37:24 ]
- >>725
> そんなプロセサにメモリに対する inc 命令なんかあるのか? > あるんならそのプロセサの型名書いてくれ。 無いからバグなんだろ。 >714 の > シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。 に対する返信だろう。
- 730 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:00:16 ]
- >>728
きっと>714の「シングルプロセサ/シングルコアなら」のことだろうね
- 731 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:01:26 ]
- >>725
> 今でも普通にあるよ。PC しか眼中にないの? SPARC/Power/Itaniumサーバも眼中に入ってるよ
- 732 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:05:07 ]
- >>725
> 「明らかな自分のミス」ってどれのこと? > ちゃんと指摘してくれって書いてあるのに指摘できないの? >714の > シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。 のことだろうね
- 733 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:23:14 ]
- Itaniumなんてもうフェードアウトだろw
- 734 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:27:20 ]
- >>733
FNHではバリバリですよ FはSPARCに注力した方がいいと思うけど東証決まってるからなあ
- 735 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:31:27 ]
- なんか、自分のミスはスルー、この反応みると本当に気づいてないようだ。だから自分はノーミスだと思っている。
前提をあとからつけて、人の意見を間違っているという。 まわりが全員レベル低いんじゃなくて、君ひとりがまわりの会話についていけてないんだってば。
- 736 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:42:48 ]
- >>729, >>732
> 無いからバグなんだろ。 「メモリに対する inc 命令持たないプロセサだとメモリのインクリメントは必然的に 複数命令になるからアトミックじゃないだろ?」って言ってるの? ならすまん、inc 命令の話してる時にその命令持たないプロセサまで考慮して話せと 言う奴がいることまでは想定できなかったよ。 世の中には自力ではメモリのインクリメント自体ができないプロセサもあったりする からそこから前提におけということかな? (w >>730 >>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。 >>731 > SPARC/Power/Itaniumサーバも眼中に入ってるよ で、それしか知らないと思ってていいのか? なら、もう少し見聞広めた方がいいんじゃね? としか言えないけど。 >>735 「ミス」とか「間違っている」とか威勢のいいこと書きながら具体的な内容が全く ないのが、ちょっと笑える。
- 737 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:43:57 ]
- 指摘されてもスルーなのが笑える
- 738 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:44:39 ]
- これはひどい。
いくらなんでも釣りだろ?
- 739 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:52:04 ]
- itaniumはもう終わりだろwww
と5年間言われ続けて、無事生存中
- 740 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 23:58:00 ]
- >>725
incはアトミックじゃない。 でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。 おまえさんはコンパイラがincに落とすのを当然と考えた上でincがバス制御しない事を忘れてる。
- 741 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:03:13 ]
- >>736
> >>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。 その前提を持ち出してるのが大間違いの元なんだよ。 マルチスレッドプログラミング全般としてはそんな前提はないわけ。 君にとってはシングルプロセッサかつシングルコアがデフォで マルチプロセッサ/マルチコアが特殊なのかもしれないが、 マルチスレッドプログラミング全般としてはシングルプロセッサかつ シングルコアはマルチプロセッサ/マルチコアの特殊ケースでしかない。 マルチプロセッサ/マルチコアでちゃんと動かないようなのはただのバグ。
- 742 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:07:03 ]
- というか、このスレ全体がひどい。
まず、議論になってない。 そして、議論以前に半分以上の書き込みが用語を並べてみているだけで技術的に意味の通る文章になっていない。 コンピュータ用語に語彙の偏った人口無脳がはき出したような文面の書き込みばかりで流れがない。 今時マルチスレッド、マルチコア、分散処理の区別もつけられない人がこんなにいるなんて信じられない。 日本のプログラマってこんなレベル低いんだ…こりゃ将来が危ぶまれるわ。
- 743 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:10:15 ]
- >>742
だってここ2chだし
- 744 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:14:50 ]
- >>742
たしかに、この発言とかひどいよね 「マルチスレッドが並列に動かなくていいわけないだろ」
- 745 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:18:26 ]
- >>744
どうひどいか語ってもらおうか
- 746 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:20:49 ]
- >>742
「このスレ全体がひどい。」とか「議論になってない。」とか威勢のいいこと書きながら具体的な内容が全く ないのが、ちょっと笑える。
- 747 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:21:03 ]
- 今このPC、 AthlonXP 1500+ で 53プロセス 562スレッド 動いてるぜー
- 748 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:21:33 ]
- >>745
マルチスレッドは並列に動かなくてもいい。
- 749 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:23:52 ]
- マルチスレットは、タイムスライスでもいいから、並列に同時に動く必要はない。
- 750 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:30:07 ]
- GreenThread
- 751 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:38:13 ]
- >>748-749
並列に「動かさなくてもいい」ならそうだが 「動かない」ってのはダメだろ つか確かに議論になってないな コンテキスト整理するからちょっと待ってろ
- 752 名前:742 mailto:sage [2008/10/04(土) 00:38:53 ]
- そもそも「同時に動く」ってのはどういう意味でいってるつもりなんだ?
意味わからん。 たとえば ・レジスタやメモリに結果を書くのを同時といってる? ・実行ユニットで演算されるのを同時といってる? ・前後を入れ替えても意味が変わらない処理を同時だといってる? もう少し頭の中で整理してかいてよ。 タイムスライスってどういう意味でいってるの? コンテキスト情報をスワップすることがよくいわれる時分割の本質的な意味でしょ? コンテキスト情報が複数ハード上にあるのがマルチプロセッサだったりマルチコアだったり ハードウエアマルチスレッディングがスレッドレベルで並列であることの本質なわけだけど。 CPUが実行ユニットで同時に計算しているとか同時にメモリに結果を書くとか関係ないよね? このスレで議論している連中は用語をならべているだけで、その中身についてはよくわかってない気がする。 回路設計が本業の漏れからみてもまず基礎がひどいと思いました。
- 753 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:39:04 ]
- >>737
どこがスルー? 具体的に指摘しなよ。 >>740 > incはアトミックじゃない。 DMA の話? それ以外にシングルコア/シングルプロセサを前提としてあるなら、具体的に 書いてくれ。 > でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。 そう言う命令がないプロセサもあるから、ちゃんと前提つけないとクレームつけられるよ。(w > おまえさんはコンパイラがincに落とすのを当然と考えた 人の心まで読めるの? 上級エスパーさんにはかなわないな。 >>741 前提つけたら、そんな前提が間違ってると来たか...。 そこまでしてレスしたいの? まあ、どっちにしろそう言う文句は >>696 辺りにつけてくれ。
- 754 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:41:31 ]
- >>752
> このスレで議論している連中は用語をならべているだけで、その中身については > よくわかってない気がする。 自己紹介乙。
- 755 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:42:44 ]
- 結局、そこで議論にならなくなってるわけでね。
- 756 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:47:57 ]
- そろそろ753はコテハンつけて欲しい
- 757 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 00:50:19 ]
- >753は>703なんだよな?
だが>753は>696じゃないのか? 俺流れが見えてねぇw
- 758 名前:デフォルトの名無しさん [2008/10/04(土) 01:04:29 ]
- 元々このスレはハードウェア主体でマルチコア化が進んでいるせいで、
ソフトウェアを並列化しないといけなくなったのに不満を持った アンチマルチコア派wがたてたスレだからね。本当はソフト屋さんの ためのスレッドなんだけど、有意義な話がなかなかでない。 回路屋が何かとソフト屋を馬鹿にしているようだけど、せっかく マルチコアの石があっても、ソフトウェア側の理論がないと意味がなく、 またソフト屋はソフト屋の理屈があるのでそこら辺勘違いしないように お願いします。 並列化といっても必ずしもバスアービタがどうとかそういう回路よりの 話だけでなく、並列型言語とかプロセス代数とか形式手法とかそういう話を 期待ているんだけど、やっぱり並列化に対するソフトウェア技術者の 意識は弱く、そういう話をができる人はあまりいないみたいだね。 (俺も話ができない一人だが、そういう人の出現を待ってこのスレ読んでます)
- 759 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 01:12:53 ]
- だんごやさんだよ。
色んな意味でマルチスレッドだよ。
- 760 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:16:34 ]
- > 並列型言語とかプロセス代数とか形式手法とか
ここ強調すると住人総入れ替えじゃないか?w もし次スレ立てるならスレタイに【Π計算】って入れようぜ
- 761 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 01:20:36 ]
- Π革命
- 762 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:21:23 ]
- >>757
> >753は>703なんだよな? あたり。 > だが>753は>696じゃないのか? >>696 じゃなくて、>>698 > 俺流れが見えてねぇw 簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは マルチプロセサ」で、状況が違う例としてメモリに対する inc 命令を取り上げ たら、inc 命令ないプロセサでは状況が違うとか (当たり前だ)、そもそも 「シングルコアでシングルプロセサ」なんて前提がおかしいとか言う奴が出て きて騒いでるだけ。 # 正直 DMA のこと忘れてたのは事実。 # DMAC とメモリーを排他制御したことないので、すっかり忘れてた。 まあ、流れを追う価値はないから、安心してくれ。(w
- 763 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:24:51 ]
- △ やっぱり並列化に対するソフトウェア技術者の意識は弱く
○ ソフトウェアベンダの合理的経営判断に基づいた技術者・コード屋に対する適切な仕事配分の結果
- 764 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:28:36 ]
- Cilk とか UPC とか?
- 765 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:33:11 ]
- >>762
> 簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは > マルチプロセサ」で、状況が違う例 その状況の違いは本来不要だったんだよ どっちもマルチスレッドスレの対象になってるんだから 発端は >>689 > ライブラリの話はマルチスレッドスレがあるからなあ > このスレいらない子なんじゃ… >>692 > マルチスレッドとマルチコアでの並列化は違う。 なんだから、マルチスレッドスレでは扱わないがこのスレ(マルチコアスレ) の対象になる違いが話題になるべきだったんだ マルチスレッドスレが「シングルコアでシングルプロセサ」の話題限定なら 外れてないがそんなこたーないわけ
- 766 名前:レトリック君 mailto:sage [2008/10/04(土) 01:35:48 ]
- 以前からあった並列計算機以上のことはできない罠
- 767 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:36:41 ]
- >>764
C++なら>688、Javaならjsr166yのfork/joinやParallelArray、C#ならTPLとか?
- 768 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:41:26 ]
- OpenMP, MPI
- 769 名前:742 mailto:sage [2008/10/04(土) 01:43:47 ]
- >>758
まあ、回路屋といっても計算機のアーキテクチャとかあんまり関係ないんだけど。 それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、 シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、 CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが このスレを読み返すと前提から大分抜け落ちているように見える。 ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく ことはできない。個人的にはマルチコアは好きではないが、 ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
- 770 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 01:49:43 ]
- 一方グーグルはマルチプロセスを使った(クロームで)
- 771 名前:デフォルトの名無しさん [2008/10/04(土) 01:57:42 ]
- > それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
> シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、 仕方ないのはいいけど、マルチコアにした後にどうやって使うか回路屋 まったくノーアイデアでしょ。ソフト屋としてはめちゃくちゃケツ ふかされている感がたっぷりなんですが...。 > CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが > このスレを読み返すと前提から大分抜け落ちているように見える。 こういう風に好意的(というか同情的?)に思うソフト屋は少ないんじゃないの? だって勝手に回路屋がこれからはマルチコアの時代だよねっ!て勝手に言っているんだもん。 仕方なくやっているんだったら、もうちょっとネガティブな感じでアピールして欲しい。 > ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく > ことはできない。個人的にはマルチコアは好きではないが、 > ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。 これは結局お互いさまという当たり前の話になるので、まあ言い分としては 理解できます。
- 772 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:06:23 ]
- 今までの時代がソフトウェア屋さんに優し過ぎたって事なんじゃないの
- 773 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:12:01 ]
- 優しかった時代なんてない
- 774 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:16:27 ]
- 布団で寝てても数ヶ月したらクロックが高いプロセッサが出てくるなんて
夢の様な時代だったじゃない。
- 775 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:17:46 ]
- 相対的にはこの15年くらいはそれ以前より優しかったと言える
でなけりゃJavaがメインストリームになることはなかったはず
- 776 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 02:41:50 ]
- >>771
>回路屋 >まったくノーアイデアでしょ。 ノーアイディアっつー事も無いんじゃない? あまり詳しくないけど、、、 Intel >> TBB Sun >> JSR166y, Fortress IBM >> X10 サーバサイドなら仮想化とか Map/Reduce とかもあるし、 マルチプロセッサの歴史が長いから、そもそもスケールする アプリも多いよ。
- 777 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 03:47:55 ]
- PCIバスもバスマスタになるからメモリ書き込むよ
- 778 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 03:57:30 ]
- Pentium 4で3GHz到達したくらいまでが天国だったろ?
- 779 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 05:11:09 ]
- MapReduceはサーバーサイドじゃないけどね。
- 780 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 07:42:59 ]
- >>765
> その状況の違いは本来不要だったんだよ え゛っ、今更そんな言い訳ですか...。 だったら、RISC がどうのこうのとか言ってた奴はまんまバカじゃん。 まあ、実際バカだと思うけど。(w て言うか、マルチコアスレだからこそ、シングルプロセサ and シン グルコアとの違いを書いただけで、常識的なことだから普通に流され ると思っていたんだが...。
- 781 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 11:49:44 ]
- >>780
今更って…>709でも同じように書いてるんだけど 言い訳とか後出し(>711)とか意味わかんないし 話が>689から始まったのを分かってないのか? > て言うか、マルチコアスレだからこそ、シングルプロセサ and シン > グルコアとの違いを書いただけで 繰り返しになるが、マルチスレッドスレがシングルコアスレなら それが違いになるが、そんなこたーないわけ この話続けてもかみ合いそうもないから俺はもう逃げるよ
- 782 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 15:34:42 ]
- この板の連中もたいしたことねーな
- 783 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 15:39:07 ]
- >>779
わざわざ説明しなくても良いと思ったんだけど、必要だった?
- 784 名前:デフォルトの名無しさん [2008/10/04(土) 16:18:04 ]
- なんか不思議だよね。CPUのクロックは別にまだ上げられるだろ。
消費電力考えたら、マルチコアにいくのがいいよね〜っていうだけで。 で、マルチコアのプログラム支援が言語レベルであれば理想的だが、 なくてもそこそこやれる(やれてる)でしょ?コア数が100とか 1000とかになってくると、言語レベルの支援がないと厳しく なってくるかもしれんが。 何がいいたいか、自分でもわからn
- 785 名前:デフォルトの名無しさん [2008/10/04(土) 16:53:06 ]
- あげられないからマルチコアになったんだよ。
- 786 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 17:39:15 ]
- クロックは上げられるけど、投資対効果が期待出来るスピードで
クロックを上げ続けるのは無理。それより余ったトランジスタで コアを増やした方が取り敢えず嬉しい。
- 787 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 17:49:33 ]
- マルチコアの方が使っててスカスカに軽く感じるじゃん?
当面はそれでいいんじゃないかと思う。 で、ユーザーがマルチコアの潜在能力を活かしてプログラム 全体の速度を上げられないかと言い出したらそういうプログラム を作ればいいが、そうするとシングルコアと同じく多数のプログラム は同時に動かしにくくなる。
- 788 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 18:35:45 ]
- どうせみんな8つくらい同時にプログラム動かすよね。
じゃあ、クライアントアプリなら、なんも考えなくてもいいんじゃないか
- 789 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 18:42:25 ]
- 8つくらい立ち上げてても、ほとんどのプログラムは待機状態だと思う
- 790 名前:>>780 mailto:sage [2008/10/04(土) 18:46:34 ]
- >>781
>>692 マルチスレッドとマルチコアでの並列化は違う。 >>692 そもそも、マルチコアとマルチスレッドを比較するなよ。 >>709 比較なんかしてないぞ 「違う」と書きながら、指摘されたら「比較してない」って言い張るわけですね。 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。 まあ、「逃げる」とか書いてるぐらいだから、流石にもうでてこないだろう。 普通に考えても、恥ずかしくて出てこれないと思うけど。(w
- 791 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 19:18:44 ]
- >>790
>692と>709は別人ね。
- 792 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 19:54:15 ]
- マルチコアに対応と言っても並列化したいのはほんの一部分だし、
スレッドプールとタスクキューを作れば何とかなりそうな気が…
- 793 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:00:29 ]
- つまり「ミニOS」みたいな構造にしてCPUにさせる仕事を細かく分解し
やらせる仕事は片っ端からキューに叩き込んで行き仕事を終えたコア が次の仕事を取りに来る、とか
- 794 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:13:07 ]
- 並列化したい部分なんてのは単純に並列化すればいいだけで何の問題もなく、
特に並列化したいわけでもない普通の部分をいかに並列化してパフォーマンスアップに繋げようかってのが難しいんじゃない?
- 795 名前:デフォルトの名無しさん mailto:sage [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
- 796 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:50:19 ]
- 長文ウゼ(´Α`)
- 797 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 20:50:26 ]
- よくしらんがコンカレントCとかadaとかか?
- 798 名前:>>780 mailto:sage [2008/10/04(土) 21:11:32 ]
- >>795
まあレス番素直に読めばそうだな。 そうすると、>>708 は話の流れに関係なく唐突に「比較なんかしてないぞ」と 喚きだすちょっと危ない人になるけど、それでいいんだよね。(w
- 799 名前:>>780 mailto:sage [2008/10/04(土) 21:13:34 ]
- すまん、レス番間違えた。
そうすると、>>709 は話の流れに関係なく唐突に「比較なんかしてないぞ」と 喚きだすちょっと危ない人になるけど、それでいいんだよね。(w
- 800 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/04(土) 21:34:04 ]
- >>784
パイプラインを細分化してもレイテンシが大きくなりすぎて効率が上がらないし 配線間隔が狭くなりすぎてリーク電流を抑えるのに神経使う時代が到来した今 シングルコアでクロックをひたすら上げるアプローチなんてどこもやらないよ。 強いて言えばPOWER6くらいか。 5年で5〜10倍なんてペースで進化する時代はもう終わった。 コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが 一番有効な手段だったりする。
- 801 名前:デフォルトの名無しさん mailto:sage [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)だろ
- 802 名前:>>780 mailto:sage [2008/10/04(土) 22:23:09 ]
- だったら、おまえら二人で相談でも何でもして解決してくれよ。
俺は、>>692 に「比較するのはおかしい」と指摘しただけで、 お前ら二人が別人かどうかなんてわからんのだし。
- 803 名前:デフォルトの名無しさん mailto:sage [2008/10/04(土) 22:48:07 ]
- >>802
> お前ら二人が別人かどうかなんてわからんのだし。 誤読しといて開き直るなよw
- 804 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 00:01:55 ]
- ここ住人は行った人結構いそうだな
ttp://d.hatena.ne.jp/potasiumch/20080827#1219824560
- 805 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 00:59:13 ]
- >一般企業での並列化は遅々として進んでいない。某 Ad○be 社に
>並列化コンサルティングに行ったところ、「○○処理の部分はプログラマが >だいぶ前に死んだのでそれ以降誰も触っていない・触れない」「え、リコンパイル? >そんなことしたらもう動かなくなったりしないかなあ」などと言われた。 >(だからあの会社の製品はあんなに重いのだろうか?) ワロタと同時にゾッとした
- 806 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 01:03:11 ]
- シングルコアとクロック数の話で 「周波数と消費電力が2乗の関係」
ということが論じられていない件について
- 807 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 01:05:48 ]
- ああ、CPUなんて1Hzでいいよ
- 808 名前:デフォルトの名無しさん mailto:sage [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:ノード当たりのリーク電流
- 809 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/10/05(日) 01:33:10 ]
- >>806
同じアーキテクチャで同一電圧での話なら2乗だけど ある程度以上はクロックを上げるのに電圧盛らないといけないので3乗になるんじゃなかったっけ
- 810 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 01:57:03 ]
- >>806
ここはソフトウェアの板だから、そっち方面の話題の需要は無いと思われ
- 811 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 02:22:54 ]
- ソフトオンリーの人がハードを含む話をすると悲惨たからな。
>>50->>57あたりにソフトウエアの板のマルチコアCPUに対する理解度があらわれているよ。
- 812 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 02:24:48 ]
- ソフトウエア板住人の
- 813 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 03:28:52 ]
- 生活に直結していないから不要な知識なんじゃないの。
多分 >>803 みたいな話がむしろ当然な世界でしょ。 食い扶持に影響する様になったらガッと動くけど、 手を抜ける所は手を抜くのも仕事では重要だし、 コア数が一桁のうちは今のままでも困らないかと。 秘伝のソースを書き換えたりアーキテクチャを一から 変更したりするとテストだ互換性だと色々面倒だし。
- 814 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 03:30:01 ]
- スマソ。レス番間違えた。
× >>803 ◎ >>805
- 815 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 04:24:03 ]
- レンダラーとかゲームの思考エンジンとか、並列処理に向いてるソフトウェアでも
売り物じゃないオープンソースのは並列化されていない事が殆どだね。やっぱり 一手間加えるのがマンドクサイのかな。
- 816 名前:デフォルトの名無しさん [2008/10/05(日) 04:44:56 ]
- >>800
> コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが > 一番有効な手段だったりする。 いやだから、そんなことは当たり前であって。2個とか4個とかなら、その CPUをフルに活用するようなプログラム作れるかもしれないが。 100個とか1000個とかになったときには言語レベルで支援がないと きつくなるのじゃないかな?っていう話。まぁ100個とかになる前に、 バスネックになると思うが。
- 817 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 05:05:58 ]
- 100 CPU 越えのマシンは既にあるよ。
1 socket で 64 並列の CPU もあるし。
- 818 名前:>>780 mailto:sage [2008/10/05(日) 10:06:49 ]
- >>803
おまえらが別人かどうかもわからんのに誤読とか言われても知らんがな。 にちゃん初心者か?
- 819 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 11:26:23 ]
- >>816
なるほろ 確かに、これから先コア数がガンガン増えていったとして デクストップアプリケーション、例えばExcelなんかが その性能に比例して進化していけるのか 今までのアプローチでそれが可能なのか 不安が残るな
- 820 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 16:06:29 ]
- 今のスペックでそこそこ動いているものを挙げたって仕方ないだろ。
コア数が増えるならそれに適応したシステムになるのは当然。 コア数が増えて初めて恩恵を得るようなものを作っていかないといけない。
- 821 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 17:31:58 ]
- マシンがすでにあることなど関係ない
- 822 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 17:33:14 ]
- >>811
どうみてもまじめにつっこむとことちゃうだろ
- 823 名前:デフォルトの名無しさん mailto:sage [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
- 824 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 18:17:26 ]
- オマイ等そろそろ他所でやれよな。
2ch だからって何書いても良いという訳じゃないんだぜ。
- 825 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 18:50:17 ]
- ああそろそろ規制議論板に報告して芋掘りしてもらう頃合いだな
- 826 名前:>>780 mailto:sage [2008/10/05(日) 21:00:25 ]
- >>823
> 別人ってわかるだろうが そもそもお前が誰かもわからんのに、何を言ってるんだろうこの人。(w
- 827 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 21:47:07 ]
- >>826
そうだね、君の読解力じゃ無理だよねw 笑えるよなぁ、コテハン付けて勝利宣言(>790)のつもりが墓穴だもんなwww そのコテハンそろそろ捨てた方がいいんじゃないの?他の人に迷惑だしさ 普通に考えても、恥ずかしくて出てこれないと思うけど。(w
- 828 名前:デフォルトの名無しさん [2008/10/05(日) 22:09:02 ]
- 私のために争うのはやめて!
てのはさておき、いい加減にしたらどうなんだ。 元の話でいえば、シングルコアのCPU上のマルチスレッドプログラム が、マルチコアのCPU上で動作しなくなることなんて、バグじゃなく ても当然ありうる。タイムスライス限定とかいうなよ?自分の 知ってる範囲だけがマルチスレッドじゃないのだから。 優先度に基づいたマルチスレッドもあるし、そういう環境で無駄な 排他を排除することは当然ありうる。マルチスレッドじゃないが、 割り込み禁止で排他する場合も、マルチコアじゃぁ別のCPUで 割り込みハンドラが動くこともある。
- 829 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:13:16 ]
- 最初からシングルコアっていうかその環境専用に作ってるならバグじゃないし
マルチコアは想定外と最初から言ってないなら普通はバグと判断される それだけのこと
- 830 名前:デフォルトの名無しさん [2008/10/05(日) 22:19:23 ]
- >>829
何をいいたいのかわからんが。そのプログラムがどんな システム向けに作られたかしだいでしょ。最初から 「マルチコアを想定して作ることを求められたプログラム」 ならバグであるし、そうでないならバグではない。 30年前のシングルコアしかなかった時代のプログラム は全部バグっているというのかい?
- 831 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:19:45 ]
- 折角の週末を無駄にして、君たちは一体何と戦っているんだい?
- 832 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:33:00 ]
- >>830
俺は>829に同意。 デフォでマルチプロセッサをサポートしてるのが当然な環境が今は多い。 PCでもWindowsNTWSは最初から2プロセッサをサポートしてたよな。 動作環境にNTが含まれていたら、対象外と明示していない限り、 マルチプロセッサ/マルチコアで動かなければそれはバグ。 前提の環境がマルチプロセッサを含まないことが明白な場合は別。
- 833 名前:デフォルトの名無しさん [2008/10/05(日) 22:39:15 ]
- >>832
だから、なんのプログラムに対してバグっているといっているのだ? 仮にあなたが発注元で要求仕様に「マルチコアでも動作すること」 という条件を含めていなかったら、それはバグではなくて仕様。 その変のフリーでころがってるプログラムがマルチコアで動作しな いとしたら、それは*あなたが*バグであるかどうかを判断する 立場にはないよ。作者がマルチコアに対応するつもりでプログラム 作っているなら*作者*はバグであるというかもしれないし、 シングルコアのみに対応するつもりなら、*作者*は仕様だと いうだろう。 前提が不明なのだよ。
- 834 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:52:05 ]
- それはない。逆。
このソフトはマルチコア環境では動作しません。 とうたっていない限り、バグ。
- 835 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:55:17 ]
- >>833
仮に動作環境がWindows2000やXPだったら、「マルチコアで動作しない」 と書いてない限り、動かなかったらバグだよ。 OSがサポートしている環境ではマルチコアもその範囲内だから。 それは明白だよ。不明じゃない。 はっきり書いてない場合にマルチコアで動いて当然の環境があるんだよ。 作者がマルチコアを想定してなくて動かなかったなら、コードを直すか ドキュメントの動作環境を直すかのどちらかは必要だろう。 つまりコードのバグか、ドキュメントのバグかのどちらかになる。
- 836 名前:デフォルトの名無しさん mailto:sage [2008/10/05(日) 22:58:00 ]
- 極端な話、3GHz以上のCPUでは動きませんと明記していないかぎり、
3.2GHzだろうが5GHzだろうが暗黙の了解でソフトは動いて当然。 動かなかったらバグだろ。それと同じだよ。
- 837 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 01:31:30 ]
- 特殊なソフトじゃない限り、「シングルコアのCPUじゃないと動きません」なんて、許されんな。
- 838 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 02:40:38 ]
- 『動く』と書いてあるのに動かないのはバグ。
書いてなくて動かないなら、動かなくてもおk
- 839 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 02:51:16 ]
- 『動かない』と書いてないのに動かないのはバグ。
書いてあって動かないなら、動かなくてもおk
- 840 名前:デフォルトの名無しさん [2008/10/06(月) 03:01:12 ]
- >>835
Windozeとか、べつにタイムスライスしかないのだから、ドライバで ないかぎりマルチスレッドプログラムは、普通にマルチコアでも動く だろ。何をいってるんだ?
- 841 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 03:07:14 ]
- >>840
上のほう読んでよ。アトミック操作を適切に行っていないプログラムは、 マルチコアで動かないけどシングルコアでマルチスレッドなら動くって眉唾なこと言っている奴がいたんだ。
- 842 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 03:56:07 ]
- >>838
そう思ってるのは開発側だけだな。
- 843 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 04:13:35 ]
- そういや昔、マルチスレッドのプログラムがちゃんと動くかどうかテストするのに
マルチプロセッサのPC組み立てたっけ。 90MHzのPentiumでDaytonaだった。
- 844 名前:は@携帯 ◆cplnFO9T0I [2008/10/06(月) 09:53:26 ]
- 高速なCPUで動かないソフトといったらWindows95だろ
たかだかK6-2の350MHzでコケるってどんだけだよと
- 845 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 10:29:44 ]
- コア数が増えてoccam復権しねぇかなぁ
- 846 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 11:09:06 ]
- >>843
マヌケだなw
- 847 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 15:08:16 ]
- >>840-841
二人とも0点
- 848 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 16:37:47 ]
- 一般的なソフトウェア開発の観点では、プロセッサもしくはランタイム環境の、主にメモリモデルに起因する問題が多い
- 849 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 21:15:49 ]
- >>864
理解できない時は素直に認めた方がいいぞ。
- 850 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 21:22:16 ]
- スルーパス出ました
- 851 名前:>>780 mailto:sage [2008/10/06(月) 22:02:03 ]
- >>827
>>826
- 852 名前:デフォルトの名無しさん mailto:sage [2008/10/19(日) 13:24:40 ]
- このスレ絶望的にレベルが低いですね。
- 853 名前:デフォルトの名無しさん mailto:sage [2008/10/19(日) 13:33:32 ]
- 今日はそうみたいだな。
- 854 名前:デフォルトの名無しさん mailto:sage [2008/10/19(日) 13:36:45 ]
- ダンゴさんが最近発言していないからな
|

|