- 1 名前：デフォルトの名無しさん [2006/01/18(水) 08:31:11 ]
- 最近のCPUはマルチコアが技術トレンドになっています。
それに伴い、ソフトウェアは並列化というパラダイムシフトが
求められています。効率のよく並列化を実現するためにはアル
ゴリズムやデータ構造といった部分を根本から見直す必要が
あります。しかし、トレンドができてからあまり時間が経って
ないため、そいういったノウハウが蓄積されていません。
そこで、マルチコアを生かすためのソフトウェア設計というのは
どういうものか？という議論をするためのスレッドを立てました。
ソフトウェアの並列化に対して考えのある人や、インターネット
上のリソース、論文等があればどんどん書き込んだりリンクを
貼ってください。
【関連スレ】
OpenMPプログラミング
pc8.2ch.net/test/read.cgi/tech/1102483474/l50
- 91 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 07:30:41 ]
- それはniceなアイディアだ
- 92 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 08:55:09 ]
- アンチってなんなの？
マルチスレッドプログラムがかけない人なの？
シングルコアの性能をもっとあげる方法を発明できる人なの？
アンチとして存在してる意味がﾜｶﾗﾈ
- 93 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 09:40:16 ]
- >>92
今まで普通にプログラムを作ってきたプログラマー達だね。
彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
>>63の言うとおりにガベージコレクションの性能が上がったとしたらそれだけで彼らは失職の危機にさらされる。
まあ、主にゲームプログラマーだけどね。
実際ゲームはシングルスレッド信仰がすごい強い分野だと思う。
ただ、滑稽なのはゲームなんてクリエイティブな分野でそんなに技術屋さんがでしゃばっていること。
本当はマルチコアでどんな新しいゲームが作れるかを考えるべきなのにそれを邪魔するだけの典型的な既得権益者なので
外野としてはそんな害虫どもにはさっさと消えてもらうことを祈るだけだね
- 94 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 12:54:33 ]
- ＞彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
＞おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
それで困るのは半端な連中だけだ
きっちっとした技術を積み上げてきたヤシなら、それほど恐怖でもない
むしろ他の連中と差をつけるチャンスだ罠
- 95 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 13:25:29 ]
- >>93
ガベコレの性能とゲームプログラマの失職に何の関係がある？
あと、ゲームのどの変の処理にマルチスレッドを導入するべきだと思う？
- 96 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 14:51:31 ]
- >>95
GCの性能が上がったら高級言語でもそこそこゲームが作れるようになるじゃないか。
ベンチマークではC++と関数型なんてほとんど変わらないしな。
そうなるとある程度ライブラリとかフレームワーク作ったり業務系と同じようになってくるんじゃないかな?
単純にシングルコアの性能だけでも相当向上してるのだからそうやってやり方が変わって脱落者が出るのでは？。
どんなゲームがいいかは例えばRTSのようなゲームで個々のユニットを複雑なアルゴリズムで動かすとかはどうだ?
- 97 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 15:35:46 ]
- D言語の時代ｸﾙｰ?
- 98 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 15:56:06 ]
- DってGC性能が低いんだったっけ？
それ以前に仕様がまだ固定化されてないのが気になるが
それとDはスレッドの機能が初期のJavaベースで非常に少ない気がするんだが
今後マルチスレッドプログラミングが増えればこのへんとかネックになってくるかもね
ま、必要になってくれば標準APIとして実装されるとは思うけど
今後スレッドが言語に組み込まれてない環境は厳しくなるよね
- 99 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 16:43:54 ]
- >>96
処理速度の向上によって今までC/C++でしかできない・C/C++が望ましかったような
ゲームが、Javaや関数型言語でも実装できるようになるだろう、という予測？
それともイチから実装する難易度が超絶的に上がり、結果必然的に高レベルなライブラリが
整備されるので、高級言語だけでもなんでもできるようになるだろうという話？
後者は理解できるけど、前者は疑問なような気がする。
生産性の向上によって確保した知的資源は、更なる難問の解決に使われるのが普通だから。
（そうじゃないと低賃金労働でしか生き残れない）
- 100 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 19:08:23 ]
- 豪華なマシンになってPGが楽になる・・・なんてことはなく、
実際は性能を限界まで出しきることを期待されてひどい目に遭うだけ。
- 101 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 19:23:38 ]
- >>100
ゲーム業界だとSFC,PS,PS2の時に聞かされた、PS2はまぁ期待にそえんでもなかったが。
- 102 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:29:20 ]
- ゲームってシングルスレッド信仰というより、わざわざマルチスレッドで
コンテキストスイッチするメリットがあまりないだけじゃないだろうか。
負荷もでかいし同期が必要なものは余計やりにくい。
- 103 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:34:00 ]
- むしろ並列演算言語が欲しい所だな
つ〜か、マルチスレッドである必要は全く無いんだよ
並列演算が可能なら、シングルスレッドでもかまわない
その意味では、昔はＭＭＸに期待したわけだが・・・
- 104 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:39:09 ]
- >>99
どっちかというと前者かな?Javaや関数型がそのまま使われるかは知らないけどPS3でオープンソースな人たちが勝手に実験始めるでしょ
低賃金労働から逃れるためにはライブラリ屋になるのが自然。ライブラリ屋が儲かるか知らんけど。
後者は手動での最適化するのが本当にできるのか疑問視していて、並列化言語を実用化させたほうが早いと思ってる。
- 105 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:40:22 ]
- マルチスレッドによる並列性の引き合いにMMXによる並列性
を出すのはどうかと思う。
- 106 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:40:59 ]
- >>103
バス幅とバスクロックの壁は厚かった
- 107 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:46:54 ]
- >>105
下手にマルチスレッドを使うよりは、並列演算を行った方が処理が早くなると思わないか？
- 108 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:49:21 ]
- １０個のコアがあるのなら、１０個別々に処理するよりも、
同時に同一処理を行わせるのもアリだと思うんだよな。
- 109 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:50:41 ]
- >>104
するってえと高賃金乙な国内の業者さんたちは結局ライブラリだの物理モデルだの
並列処理向き言語＋プラットフォーム開発だの、GCがどうとかいうレベルではなく難しい
ことをやらざるを得なくなって、「余った知的リソース⇒難しい仕事」という流れになるような・・・
成功しないのでそういう流れにはならない、という可能性も高いけど。
数学はインド人の方が得意そうだし。
- 110 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:51:37 ]
- >>107
いやだから用途が違うと思うんだけど。MMXつかって速くなるところに
マルチスレッド使っても速くなるようなケースは限られると思うが。
（逆もまた然り）
- 111 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:56:48 ]
- >>110
コアがたくさんあったとしても、一つのスレッドの扱えるコアは一つ？
- 112 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:00:41 ]
- >>111
話の流れがわからん
- 113 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:01:05 ]
- >>103
NeoMagic の MiMagic6 なんかがその路線で、16x16ピクセルの画像を
対象とした演算なんかを1命令でできる演算ユニットを積んでます。
中〜大規模SIMDってのも、応用範囲は限られるものの確かに面白い。
けれどもクロック上げて水で冷やしてガンガンパワー使えるなら不要な
手法なのかなという気もしないでもない・・・
小さいモノの中ではダイナミック・リコンフィギュアラブルLSIとかが
そういう思想のもののような気がするけど違うかもしれない。
- 114 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:06:50 ]
- >>112
つまり、10個のコアがある場合に10個演算する場合は、10個スレッドを立ち上げて、
10個同時に演算して、演算が終われば元のスレッドに戻せば、10倍の速度で演算できるのでは？
って事。
- 115 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:14:20 ]
- >>114
しかしバス幅とバスクロックの壁は、非情なまでにも分厚かった
- 116 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:15:56 ]
- >>114
それふつうにマルチコアの利点
今後はどの点が並列処理できるかという設計レベルの重要性がますわけだ
今まではそのCPUにあわせてどうすれば少ない時間で処理できるかの最適化をする
という点だったからね
JavaのコンカレントAPIみたいなのが普及せんときついかもね
- 117 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 22:19:09 ]
- >>114
俺が言いたいのは、SIMDは局所的な並列で、マルチスレッドはもっと大域的ってこと。
MMXは隣接ピクセル間の並列性、マルチスレッドはブロックごとに区切るような
（マルチレンダリング）用途でしょう。俺なら同時に使うけどね。どっちかが
肩代わりするもんじゃない。
- 118 名前：デフォルトの名無しさん [2006/01/23(月) 22:54:48 ]
- 関連スレ追加
pc8.2ch.net/test/read.cgi/tech/1099819556/
- 119 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 01:34:42 ]
- >>117
スレッドのというか処理の粒度の問題って解くべき問題との関係が深すぎるからこのスレのタイトルだと混乱するかもしれない。
- 120 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 02:24:55 ]
- スレッドとマルチコアは何の関係もないだろ。
- 121 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 03:39:30 ]
- マルチプロセッサ(SMT含)を想定してのマルチスレッドプログラミングと全く同じだもんな。
プロセッサ間の通信速度や、外部(メモリ)との通信速度が違う、というだけで。
- 122 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 04:37:07 ]
- >>109
つまり技術的にはインドに負けることが前提なわけですな。
- 123 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 11:46:28 ]
- マルチコアのマルチスレッドって、通常のマルチプロセッサに比べて
注意するところあんの？ ハイパースレッドプロセッサだったら
スピンロック問題とか言うのがあった気はするけど。
- 124 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 12:57:29 ]
- >>86
自作板のあれは、多くの場合、負け惜しみです。
体感速度が云々と言ってる人達は、遅いCPUをdualにしています。
本当にCPU速度が必要な人達は、
マルチスレッドで動くアプリを使っていて、
ユーザの操作のためにCPUが丸々1個アイドルで待機しているのでレスポンスが良い
なんてことにはならないのです。
- 125 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 12:59:39 ]
- >>102
ゲームはCPUを他のスレッドに譲るという概念がないから。
ビジーウェイトとか平気でやるからな、ゲームプログラマは。
- 126 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:00:32 ]
- >>107
並列演算を行った上で、
さらに、
マルチスレッドですよ。
- 127 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:58:16 ]
- できるやつは新しいのが出てきてもいい物を作る
できないやつは昔からの作り方にこだわり進歩しない
ゲーム製作スレのオブジェクト指向いらねという話と似てる
- 128 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 14:03:03 ]
- >>125
そんなアホはさすがに居ない。
、、と思いたいが、居る所には居るのか。
- 129 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 14:41:26 ]
- >>127
君みたいなのをみるとイライラする。
みんなマルチコア、マルチコアいっているけど、はっきりいって現状、中身がないって
いっているつもりなんだけど。マルチコアの性能を生かした設計というのは難しいし、
まだそれは誰も解決していない。それを簡単だというならそれをちゃんとわかるように
それをどうやって解決したか書いてくれ。ここはそれを解決するためにみんなで考えま
しょうっていうスレだ。
マルチコアをマンセーするのとその技術をマスターするのは、天と地ほど差があるよ。
マンセーするだけでマスターした気になっているのは中身が無い。
もうちょっと真剣に技術に対して考えてくれ。
- 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
プールに既にあるから起動しなくて良い。ので高速。
現状のシングルスレッドでのイベントディスパッチャが、
スレッド数１のスレッドプールに相当します。
例えば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のままだとメモリのボトルネックがもっとひどい事にならない？
コア数が増えるとクロスバースイッチとか導入するＰＣも出るのかな？
- 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 ]
- でも、自前でスクリプト言語を作ったりすると、
わざわざマルチスレッドにする必然性が、
高速化以外には全く無くなったりする罠。ｗ
- 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();//おわるまでまつ
とインナークラスでかけるな
スタック変数とのやり取りでは面倒なことになるが
|
 |
