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

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

[前50を表示]
100:デフォルトの名無しさん
06/01/23 19:08:23
豪華なマシンになってPGが楽になる・・・なんてことはなく、
実際は性能を限界まで出しきることを期待されてひどい目に遭うだけ。

101:デフォルトの名無しさん
06/01/23 19:23:38
>>100
ゲーム業界だとSFC,PS,PS2の時に聞かされた、PS2はまぁ期待にそえんでもなかったが。

102:デフォルトの名無しさん
06/01/23 21:29:20
ゲームってシングルスレッド信仰というより、わざわざマルチスレッドで
コンテキストスイッチするメリットがあまりないだけじゃないだろうか。
負荷もでかいし同期が必要なものは余計やりにくい。

103:デフォルトの名無しさん
06/01/23 21:34:00
むしろ並列演算言語が欲しい所だな
つ～か、マルチスレッドである必要は全く無いんだよ
並列演算が可能なら、シングルスレッドでもかまわない
その意味では、昔はＭＭＸに期待したわけだが・・・

104:デフォルトの名無しさん
06/01/23 21:39:09
>>99
どっちかというと前者かな?Javaや関数型がそのまま使われるかは知らないけどPS3でオープンソースな人たちが勝手に実験始めるでしょ
低賃金労働から逃れるためにはライブラリ屋になるのが自然。ライブラリ屋が儲かるか知らんけど。

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

105:デフォルトの名無しさん
06/01/23 21:40:22
マルチスレッドによる並列性の引き合いにMMXによる並列性
を出すのはどうかと思う。

106:デフォルトの名無しさん
06/01/23 21:40:59
>>103
バス幅とバスクロックの壁は厚かった

107:デフォルトの名無しさん
06/01/23 21:46:54
>>105
下手にマルチスレッドを使うよりは、並列演算を行った方が処理が早くなると思わないか？

108:デフォルトの名無しさん
06/01/23 21:49:21
１０個のコアがあるのなら、１０個別々に処理するよりも、
同時に同一処理を行わせるのもアリだと思うんだよな。

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

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

110:デフォルトの名無しさん
06/01/23 21:51:37
>>107
いやだから用途が違うと思うんだけど。MMXつかって速くなるところに
マルチスレッド使っても速くなるようなケースは限られると思うが。
（逆もまた然り）

111:デフォルトの名無しさん
06/01/23 21:56:48
>>110
コアがたくさんあったとしても、一つのスレッドの扱えるコアは一つ？

112:デフォルトの名無しさん
06/01/23 22:00:41
>>111
話の流れがわからん

113:デフォルトの名無しさん
06/01/23 22:01:05
>>103
NeoMagic の MiMagic6 なんかがその路線で、16x16ピクセルの画像を
対象とした演算なんかを1命令でできる演算ユニットを積んでます。

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

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

114:デフォルトの名無しさん
06/01/23 22:06:50
>>112
つまり、10個のコアがある場合に10個演算する場合は、10個スレッドを立ち上げて、
10個同時に演算して、演算が終われば元のスレッドに戻せば、10倍の速度で演算できるのでは？
って事。

115:デフォルトの名無しさん
06/01/23 22:14:20
>>114
しかしバス幅とバスクロックの壁は、非情なまでにも分厚かった

116:デフォルトの名無しさん
06/01/23 22:15:56
>>114
それふつうにマルチコアの利点

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

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

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

117:デフォルトの名無しさん
06/01/23 22:19:09
>>114
俺が言いたいのは、SIMDは局所的な並列で、マルチスレッドはもっと大域的ってこと。

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

118:デフォルトの名無しさん
06/01/23 22:54:48
関連スレ追加
ｽﾚﾘﾝｸ(tech板)

119:デフォルトの名無しさん
06/01/24 01:34:42
>>117
スレッドのというか処理の粒度の問題って解くべき問題との関係が深すぎるからこのスレのタイトルだと混乱するかもしれない。

120:デフォルトの名無しさん
06/01/24 02:24:55
スレッドとマルチコアは何の関係もないだろ。

121:デフォルトの名無しさん
06/01/24 03:39:30
マルチプロセッサ(SMT含)を想定してのマルチスレッドプログラミングと全く同じだもんな。
プロセッサ間の通信速度や、外部(メモリ)との通信速度が違う、というだけで。

122:デフォルトの名無しさん
06/01/24 04:37:07
>>109
つまり技術的にはインドに負けることが前提なわけですな。

123:デフォルトの名無しさん
06/01/24 11:46:28
マルチコアのマルチスレッドって、通常のマルチプロセッサに比べて
注意するところあんの？　ハイパースレッドプロセッサだったら
スピンロック問題とか言うのがあった気はするけど。

124:デフォルトの名無しさん
06/01/24 12:57:29
>>86
自作板のあれは、多くの場合、負け惜しみです。
体感速度が云々と言ってる人達は、遅いCPUをdualにしています。

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

125:デフォルトの名無しさん
06/01/24 12:59:39
>>102
ゲームはCPUを他のスレッドに譲るという概念がないから。
ビジーウェイトとか平気でやるからな、ゲームプログラマは。

126:デフォルトの名無しさん
06/01/24 13:00:32
>>107
並列演算を行った上で、
さらに、
マルチスレッドですよ。

127:デフォルトの名無しさん
06/01/24 13:58:16
できるやつは新しいのが出てきてもいい物を作る
できないやつは昔からの作り方にこだわり進歩しない

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

128:デフォルトの名無しさん
06/01/24 14:03:03
>>125
そんなアホはさすがに居ない。
、、と思いたいが、居る所には居るのか。

129:デフォルトの名無しさん
06/01/24 14:41:26
>>127
君みたいなのをみるとイライラする。

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

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

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

130:デフォルトの名無しさん
06/01/24 15:03:11
>>129
>はっきりいって現状、中身がないって
>いっているつもりなんだけど。

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

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

132:デフォルトの名無しさん
06/01/24 15:11:56
>>125
ジャンルにもよるが、ゲームってのは譲り合いの最たる分野だよ。
処理落ちと戦うアプリが他にどれほどあると思う。ただ他のプロセス
のことを考えるのはPCやらんとわかりにくいね。

133:デフォルトの名無しさん
06/01/24 15:23:10
あと、ユーザの立場からデュアルコアまではメリットがあるといのも了解事項?

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

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

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

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

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

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

135:デフォルトの名無しさん
06/01/24 16:14:17
>>134
>プログラムがより簡単になるとかあるんだよ

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

136:デフォルトの名無しさん
06/01/24 16:41:52
>>135
そういうこと

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

137:デフォルトの名無しさん
06/01/24 16:45:51
>>136
その辺はシングルプロセッサでも別スレッドだべ？

138:デフォルトの名無しさん
06/01/24 16:46:55
サウンドやネットワーク周りをメインスレッドで動かすのはちっと
考えられん。

139:138
06/01/24 16:49:06
昔のゲーム機でサウンドをVSyncで処理している事例はあるにはあったけどね

140:デフォルトの名無しさん
06/01/24 17:41:23
>>137
だね

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

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

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

141:デフォルトの名無しさん
06/01/24 17:43:26
やっぱり、プログラム板的にはマルチコアだからって何ら特別なことは
なく、マルチスレッドでプログラムを書けばよい、でOK？

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

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

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

143:デフォルトの名無しさん
06/01/24 17:54:32
>>141
それじゃあ話がおわっちまうが確かにその通りじゃね

144:デフォルトの名無しさん
06/01/24 18:05:43
>>142
だから同期のライブラリが充実している高級言語が有利なんだよ

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

145:デフォルトの名無しさん
06/01/24 18:26:39
>>144
高級言語という話の流れはどこから？

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

146:デフォルトの名無しさん
06/01/24 18:30:12
>>145
スレッドプールとかあるし、ユーザーは意識させないよ

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

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

147:デフォルトの名無しさん
06/01/24 18:35:55
んな細かいことはどーでもいいから、
読み書き速くするとか、読み書き中にゲーム続行できるようにしといてくれ。

148:デフォルトの名無しさん
06/01/24 18:43:20
そりゃプロセッサが複数あればそうだろう。依存関係のない部分
は簡単に並列化できるからね。

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

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

150:デフォルトの名無しさん
06/01/24 18:47:18
>>148
スレッド数をスレッドプールでコントロールする場合ループさせないほうがいい

151:デフォルトの名無しさん
06/01/24 18:51:41
スレッドプールってサーバなんかのトランザクション処理以外にも使うんだ?
どんな用途で使ってるの?

152:デフォルトの名無しさん
06/01/24 18:56:57
スレッドプールはイベント駆動との中間みたいなもんか。

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

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

153:デフォルトの名無しさん
06/01/24 19:00:38
イベントディスパッチの代わりにプールからスレッドを起動するのか。何か重そうな。

154:デフォルトの名無しさん
06/01/24 19:11:53
例えば、Winsock2系で(非標準だけど)最速といわれているIOCPは
スレッドプールを利用した仕組みだよ。

155:デフォルトの名無しさん
06/01/24 19:17:25
>>151
プールに既にあるから起動しなくて良い。ので高速。
現状のシングルスレッドでのイベントディスパッチャが、
スレッド数１のスレッドプールに相当します。

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

156:デフォルトの名無しさん
06/01/24 19:23:45
ふぅん、面白そうだね。ちょっと調べて実装してみたいな。
ｻﾝｸｽ。

157:デフォルトの名無しさん
06/01/24 19:45:30
とはいえ話にあったBGMにはスレッドプールは向かないんじゃね？
詰まっていて鳴らせませんじゃすまないし。

158:デフォルトの名無しさん
06/01/24 19:54:09
元々リニアにスケールする処理→スレッドプール
特殊な処理をメインスレッドから外出ししたい→普通にスレッド作る

...なんじゃないの。

159:デフォルトの名無しさん
06/01/24 20:09:39
スレッドプールはシングルスレッドでもいいんだけどマルチプロセッサ
に不可分散させたい時に便利だってことかー？

160:デフォルトの名無しさん
06/01/24 20:14:23
簡単に別スレッド使える構文が欲しい。C++では何度も導入の
意見が出て却下され続けてるそうだが、

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

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

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

161:デフォルトの名無しさん
06/01/24 20:18:40
現状のsmpのままだとメモリのボトルネックがもっとひどい事にならない？
コア数が増えるとクロスバースイッチとか導入するＰＣも出るのかな？

162:デフォルトの名無しさん
06/01/24 20:21:31
>>159
シングルコア･シングルプロセッサの場合でも、
とあるスレッドがI/Oで待たされてる間に他のスレッドで
他の処理ができる（かもしれない）、という普通のマルチ
スレッドの利点も提供される。

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

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

163:デフォルトの名無しさん
06/01/24 20:22:31
>>160
スレッド生成クラスとラムダで事足りるからじゃないの？
make_thread終了の同期とる方法をOSから隠蔽する方が面倒くさそうだし。

164:デフォルトの名無しさん
06/01/24 20:33:48
＞スレッド生成クラスとラムダ
それなあに？

165:デフォルトの名無しさん
06/01/24 20:36:15
どっちかっていうと閉包欲しいよ閉包。
ちょっとスレッドとかにも便利だよ。

166:デフォルトの名無しさん
06/01/24 20:50:57
make_thread foo();

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

167:デフォルトの名無しさん
06/01/24 20:52:28
URLﾘﾝｸ(216.55.183.63)

168:デフォルトの名無しさん
06/01/24 20:55:31
BGMの補充に関してはいわゆるブロッキングキューでいい
充填する側はキューサイズがいっぱいだとキューがあくまで待つ
そして取り出す側はキューが取り出せる状態になるまで待つ

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

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

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

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

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

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

↓以下ループ

170:デフォルトの名無しさん
06/01/24 21:33:12
一々、茶々入れんと気が済まんのか。御主は。

171:デフォルトの名無しさん
06/01/24 21:45:26
普通にマルチスレッドの話でいいんでないの？
スレの名前も並列化だけだし。
マルチコアが普及することによって・・・というだけでしょ。

172:デフォルトの名無しさん
06/01/24 21:52:45
あっちよりこっちが賑わってるのはスレタイの勝利ですか

173:デフォルトの名無しさん
06/01/24 21:58:02
>>172
あっちってOpenMPスレ？

174:デフォルトの名無しさん
06/01/24 22:14:53
マルチスレッドって名前付いてるスレ

175:デフォルトの名無しさん
06/01/24 22:25:37
まあ、賑わってるって言ったって、住人の顔ぶれは
ほとんど変わらないと思うけどな。

176:デフォルトの名無しさん
06/01/24 22:31:25
あっちはC＋Win32ベースでしかも基本的なところから先に進んでない
単純な排他制御だけではお話になりませぬ

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

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

177:デフォルトの名無しさん
06/01/24 23:14:45
このスレッドの場合は極端な事を言い出しても、
まだまだ使い古されて無い技術だから叩きづらいんだよ
だから好き勝手に色々な事が言える

178:デフォルトの名無しさん
06/01/24 23:16:55
>>164
多分、どっかの誰かが作ったスクリプト言語だったと思う

179:デフォルトの名無しさん
06/01/24 23:19:21
まあ結局、並列化を効率よくやろうとすると、自前でスクリプト言語を作るか、
現時点で存在するスクリプト言語に頼るかの、二者択一になってくるんだよな

180:デフォルトの名無しさん
06/01/24 23:20:46
あるいは、同期機能を駆使してC++で作るとか・・・

181:デフォルトの名無しさん
06/01/24 23:23:25
でも、自前でスクリプト言語を作ったりすると、
わざわざマルチスレッドにする必然性が、
高速化以外には全く無くなったりする罠。ｗ

182:デフォルトの名無しさん
06/01/24 23:28:21
Javaもまあ、スクリプト言語の一種といえば一種か

183:デフォルトの名無しさん
06/01/24 23:36:41
>>160
一カ所のメモリーに対する多重アクセスを防ぐのが難しくなるからかと

184:デフォルトの名無しさん
06/01/24 23:36:58
>>178
Boost か何かのライブラリの機能でしょ。

185:デフォルトの名無しさん
06/01/24 23:38:03
>>179
スクリプト言語は、GC という並列化と相性が悪い物を抱え込む事になる。

186:デフォルトの名無しさん
06/01/24 23:38:23
何でマルチコアの話で「スクリプト言語」がでてくるんだ？

187:デフォルトの名無しさん
06/01/24 23:40:51
気にしちゃダメ

188:デフォルトの名無しさん
06/01/24 23:44:35
>>186
スレッドの管理が面倒だからかと
面倒な処理は、誰かが勝手にやってくれる方が楽だからな

189:デフォルトの名無しさん
06/01/25 00:15:33
>>160
Javaならすぐかけるのにね

190:デフォルトの名無しさん
06/01/25 00:31:21
そろそろC++も言語にスレッドを組み込んでしまって、何らかの
シンタックスシュガーが欲しいところ。

191:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/01/25 02:00:13
スレッドの話はスレ違いだろ。スレッドだけにスレ違いw

193:デフォルトの名無しさん
06/01/25 06:15:51
>>191
へ～、Javaだと仮想関数をそんな風に作れるんだ・・・

194:デフォルトの名無しさん
06/01/25 09:46:54
マルチコア時代もJavaで決まり！！！
ドントネット死滅ケテーイ（禿藁嘲笑）

195:デフォルトの名無しさん
06/01/25 11:01:49
>>191
記述は楽なんだけど、外側のローカル変数を受け継いで欲しい。
中の処理にパラメータはどうやって渡すのがお行儀いいの？

>>193
仮想関数？

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

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

197:デフォルトの名無しさん
06/01/25 12:54:27
final宣言されたローカル変う右派コンストラクタでコピーされて渡されてる
そもそもfinalは変更が不可能なのでお手軽に変数を渡すわけにはいかないよ
普通にクラス作ればいいだけだけどね

198:デフォルトの名無しさん
06/01/25 12:58:30
>>191
>>160の例はそういうことじゃなくて、i=0からi=99までの初期状態を持つ
100個のスレッドの生成と実行と待ち合わせが簡易な構文でできればなー、
という話なのでは？

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

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

199:デフォルトの名無しさん
06/01/25 13:42:21
Javaのそれをクロージャと呼ぶと、変な人が湧いてくるよ。

200:デフォルトの名無しさん
06/01/25 15:58:45
>>133
お前はスレッドの優先度を設定しないアホプログラマか。

201:デフォルトの名無しさん
06/01/25 16:55:05
Win32限定なら、QueueUserWorkItem()一発かな。
自動的にスレッドプールを作って関数を実行してくれる。

202:デフォルトの名無しさん
06/01/25 19:01:32
>>198
匿名内部クラスでぐぐれ

203:デフォルトの名無しさん
06/01/25 23:28:05
マルチスレッドなんて時代遅れ。
これからはマルチコア。これだね。

204:デフォルトの名無しさん
06/01/26 00:12:15
>>199
コンパイラ・スクリプトエンジン相談室によく出没するあいつらか？

205:デフォルトの名無しさん
06/01/26 00:13:24
Lispこそがすべての起源。
Lispを知らずしてプログラミングを語るべからず。

206:デフォルトの名無しさん
06/01/26 01:06:43
>>200
いや、プライオリティの問題もあるが、それだけじゃない。

207:デフォルトの名無しさん
06/01/26 03:25:18
マルチコアだと重いタスクを裏に回せるのがメリットかね。
シングルコアで重いタスクを裏に回しても、裏のタスクの
進行が遅くなるか表のタスクが足を引っ張られることが
多い。

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

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

208:デフォルトの名無しさん
06/01/26 03:36:50
×マルチコアなら
〇マルチプロセッサ(HTT含)なら

209:デフォルトの名無しさん
06/01/26 08:43:17
で、結局、バス幅とバスクロックの壁はどうにかなりますか？

210:デフォルトの名無しさん
06/01/26 09:03:54
>>206
いくらプライオリティが低くても、
一旦CPUを割り当てられたら、割り込みがかかるまで、一定時間はCPUを占有する、
という問題はあるけれど、ユーザのインタラクティブな操作は割り込みをかけるので問題なし。

211:デフォルトの名無しさん
06/01/26 09:07:08
スループットを犠牲にしてでもレスポンスを良くしたければ、
CPUの割り当て時間を短くしてしまうのも手ですよ。

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

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

213:デフォルトの名無しさん
06/01/26 14:46:16
インテルのデュアルって肩並べて爆熱してるだけのツインプロセッサじゃないのか？

214:デフォルトの名無しさん
06/01/26 15:46:58
IntelCoreしらんのか

215:デフォルトの名無しさん
06/01/26 17:54:54
しらんがな

216:デフォルトの名無しさん
06/01/26 18:13:20
>211から>212へ行く話の流れがわからない。
>212は何に関するaffinityのことを言っているの？
CPUの割り当て時間との関係は？

217:デフォルトの名無しさん
06/01/26 23:50:22
Windows では Thread Affinity って言葉は使わないのかな。

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

218:デフォルトの名無しさん
06/01/27 22:22:57
Windowsでアフィニティと言えば、
プロセスやスレッドを特定のCPUだけにしか割り当てないようにアプリがOSにお願いすることだよね。

219:デフォルトの名無しさん
06/01/28 05:00:41
それは UNIX で Processor Bind と呼んでる機能かな。

220:デフォルトの名無しさん
06/01/29 18:42:42
名前を前例に倣わんのはMSの悪いところ。とはいえスレッド関連は
NTのほうがUNIXより早いんかね？

221:デフォルトの名無しさん
06/01/29 22:15:40
お前ら並列プログラミングを語る前にLispについて学べ

222:デフォルトの名無しさん
06/01/29 22:23:30
>>221
なんで？いまの並列化言語は論理型のほうがすすんでないか?

223:デフォルトの名無しさん
06/01/29 22:43:33
Lispを知らずしてプログラミング言語を語るべからず

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

224:デフォルトの名無しさん
06/01/29 22:46:33
>>223
各所で Lisp を貶めるのは止めてくれ

225:デフォルトの名無しさん
06/01/29 22:57:15
>>223
おまえみたいなのがいるからLisp使いがバカにされる

226:デフォルトの名無しさん
06/01/29 23:23:26
>>223はこういう念仏を唱えるだけのアホウがいる、という話かと思ったら
アホウ当人だったのか。

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

227:デフォルトの名無しさん
06/02/02 19:13:07
そんなことしてるのがリアルに居るとは信じられんが、ｶﾅｼｽ

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

229:デフォルトの名無しさん
06/02/02 23:41:51
>>228
>>224

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

231:デフォルトの名無しさん
06/02/03 04:00:13
>>230
>適度に制限されたフレーム

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

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

あ、それから…、

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

232:デフォルトの名無しさん
06/02/03 04:49:07
俺はlisp知らんけど、
もし本当にlispが並列処理向きだったとして

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

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

233:デフォルトの名無しさん
06/02/03 04:57:20
>>232
>もし本当にlispが並列処理向きだったとして

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

234:デフォルトの名無しさん
06/02/03 05:03:49
並列化言語の側も盛り上がってないし、今の並列処理の枠組みは pthread とかに
依存しているんで、今後も C とか Java でどうするかって話が主流なんじゃないかな。
関数型言語にもちっと頑張って欲しい所。

235:デフォルトの名無しさん
06/02/03 09:51:27
どの言語がいいだの悪いだのはモノ作れるようになってから語れ
('A`)

236:デフォルトの名無しさん
06/02/03 09:57:14
自分で言語を作るのは、手間がかかるんだよ。ｗ

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

237:デフォルトの名無しさん
06/02/03 21:26:44
別に実装の話まで入り込む必要は無いんだけど、並列化を支援する言語のフィーチャーに
どんな物があるのかは興味がある。

238:デフォルトの名無しさん
06/02/04 00:05:15
>>237
そういう話題は、「マルチスレッドプログラミング相談室」で。

239:デフォルトの名無しさん
06/02/04 05:24:48
あっちは実践、こっちは理論や研究レベルってことで、こっちでもいいんじゃない？

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

これなんか実際に、後から何スレッドで動かすか指定するみたい。
URLﾘﾝｸ(www.haskell.org)

240:デフォルトの名無しさん
06/02/04 05:28:19
と思ったら普通にプログラムの方でも指定するみたいだな。
並列に出来るからって勝手に全部並列化したらオーバーヘッドの方が大きくなっちまうか。

241:デフォルトの名無しさん
06/02/04 13:27:34
ウザいLisp厨のせいで折角のふいんきが台無しだな

242:デフォルトの名無しさん
06/02/11 19:50:33
スレ頓挫か？

243:デフォルトの名無しさん
06/02/11 20:06:40
なんかネタがねぇ。だれかネタ提供してくれ。

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

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

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

244:デフォルトの名無しさん
06/02/11 20:12:43
たまにはageとく

245:デフォルトの名無しさん
06/02/11 21:05:00
　　　 -‐-　　
__ 〃　　　　ヽ
ヽ＼　ノﾉﾉ）ﾍ)､!〉
　(0_)!　(┃┃〈ﾘ　はわわ～マルチが245ゲットですぅ～～
　 Vﾚﾘ､" lﾌ／　　　
　　　　(　￣￣￣《目
　　　　|　＝＝＝《目
　　　　|＿＿|　　　 ∥
　　　∠|_|_|_|_ゝ　　∥ 　　　　　　∧＿_∧
　　　　 |__|_|　　　　 ∥ 　　　　　 ┝・∀・┥ﾄﾗﾗｰも2ｹﾞｯﾄ。
　　　　|　| |　　　　 ∥ 　　　　　（　　　　）　
　　　　 |__|__|　　　　 ∥ 　　　　　|〓 | 〓|　　
　　　　|　＼＼　　皿皿　　　（＿_）＿_）.　

246:デフォルトの名無しさん
06/02/12 10:34:53
トララーがﾜｶﾝﾈ

247:デフォルトの名無しさん
06/02/12 23:55:41
OSがプリエンプティブであればマルチコアかどうかは
さほど問題ではないと思うのだがどうか。

248:デフォルトの名無しさん
06/02/13 00:18:59
>>247
それは必要条件であって十分条件じゃない。

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

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

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

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

249:デフォルトの名無しさん
06/02/13 10:57:19
シングルスレッド最強

250:デフォルトの名無しさん
06/02/13 20:52:13
シングルスレッドで作って、適当にexecすればいいじゃん。
何を悩んでいるのかわからない。

251:デフォルトの名無しさん
06/02/13 20:58:46
もう面倒くさいよ。

252:デフォルトの名無しさん
06/02/14 15:41:09
おわりか

253:デフォルトの名無しさん
06/02/23 13:09:55
URLﾘﾝｸ(japan.cnet.com)
Cell向けにOctopilerツールが発表されるらしい。
どういう形で支援するか謎だ。そのあたりの情報が外部にも出してもらえると、
今後のマルチコア向けアプリケーションの開発に少しは参考になりそう。

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

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

254:デフォルトの名無しさん
06/02/23 13:48:56
マルチコアでマルチスレッド処理が平気でできれば、これから食いぶちがありますあ？

255:デフォルトの名無しさん
06/02/23 14:21:45
なにやっても食っていける。重要なのは仕事取る（就職含む）対人スキル。
プログラミングはそれからだ。

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

256:デフォルトの名無しさん
06/02/23 14:56:45
ドカタ乙

257:デフォルトの名無しさん
06/03/04 22:34:53
特に意味はないが、保守っとく。
ちょっと古いけど、Timed Calculus of Communicating Systems つーのを調査中。

258:デフォルトの名無しさん
06/03/06 22:39:39
保守

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

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

260:デフォルトの名無しさん
06/03/07 08:21:54
そりゃCCSなら説明がたくさんあるだろうな・・・

261:デフォルトの名無しさん
06/03/12 02:13:05
>>253
OpenMPのpragmaを流用するみたい

262:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 22:08:36
TextSS　のWindowsXP(Professional)64bit対応化おながいします

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

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

263:デフォルトの名無しさん
06/03/18 22:23:01
>>261
そうなんですか。できることは限定されているような気がしますが、
普通にCellに最適化されたプログラムを書くより大分楽にはなり
そうですね。

264:デフォルトの名無しさん
06/03/22 23:49:32
URLﾘﾝｸ(it.nikkei.co.jp)
やっぱり開発が難しいそうですよ。新しいノウハウが必要らしい。予想通りだ。
マルチコアはいいけどソフトウェアの負担は大きい。

265:デフォルトの名無しさん
06/03/23 00:22:34
86とか汎用の石のマルチコアが難しいというのと
Cellが難しいというのとはたぶん難しい場所が違う

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

266:デフォルトの名無しさん
06/03/23 00:25:24
>>265
それが新しいノウハウだろｗ
PS2 のころから Vu0 マイクロコード動かしてた連中にとっては、今までの延長だろうけど

267:デフォルトの名無しさん
06/03/23 01:12:40
８６系ってＣＰＵの思想があれだから、マルチコア化を困難にさせてるんだよな・・・

268:デフォルトの名無しさん
06/03/23 01:20:43
↑
こういう知ったかがわくのはどうにかならないのか？

269:デフォルトの名無しさん
06/03/23 01:22:39
>>267
思想がアレなのはiApx432だろ。

270:デフォルトの名無しさん
06/03/23 01:24:49
レジスタが専業化されてるってやつだろ？
今でこそ区別無く使えるようになったけど、それでもニーモニック汚過ぎ。

271:デフォルトの名無しさん
06/03/23 10:15:02
uOp fusion のコストが高すぎるといってるのか？
俺には的外れに思えるが。

272:デフォルトの名無しさん
06/03/24 05:57:20
↑
こういう知ったかがわくのはどうにかならないのか？

273:デフォルトの名無しさん
06/03/24 11:57:44
267が論旨を明確にすればいいだけの話。

274:デフォルトの名無しさん
06/03/24 17:50:04
デコーダが複雑になるから、メニイコアでかつ個々のコアの
処理速度も上げるってのがやりにくいんじゃない？

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

275:デフォルトの名無しさん
06/03/24 22:46:44
つまりメタセコイアは生きた化石だということか。

276:デフォルトの名無しさん
06/05/14 23:36:57
鯖側は、簡単というか今まで通りでよいが、
クライアント側は大変だな。

277:デフォルトの名無しさん
06/05/14 23:54:33
そうでもない

278:デフォルトの名無しさん
06/09/10 14:07:50
ho

279:デフォルトの名無しさん
06/09/10 20:48:00
>>276
2-4 並列くらいでいいんだから余裕じゃ。
大変って言ってる奴が居たら、それは「ﾏﾝﾄﾞｸｾ」って意味か、「もっと金寄越せ」って
意味かのどちらか。

280:デフォルトの名無しさん
06/09/15 00:56:12
Objective-C + Cocoa なソースで OpenMP って使えるの??

281:デフォルトの名無しさん
06/09/30 23:13:10
Cilkってどう？

282:デフォルトの名無しさん
06/09/30 23:34:11
ｲｿﾃﾙが発表した４コアってプログラミング的にはどうなん？
性能を活かせるコンパイラってあるの？

283:デフォルトの名無しさん
06/10/01 00:38:46
80コアか・・・
機械的に最適化できる方法あるのかな？
URLﾘﾝｸ(techon.nikkeibp.co.jp)

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

285:デフォルトの名無しさん
06/10/08 15:44:34
そこまでしてx86である必要がないような。

286:デフォルトの名無しさん
06/10/08 19:56:41
互換性が重要だからね。
x86系は（PC/AT互換機が業界標準になったおかげで）業界標準になったから過去の互換性切れないんだよ。

287:デフォルトの名無しさん
06/10/08 22:54:13
ソースレベルで保持運用されてるUNIXなら、CPUの互換性なんて関係無いのにね。

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

289:288
06/10/08 23:32:09
×公開
○開示
だな。まぁ公開も商用である限りまず望めないだろうね。

290:デフォルトの名無しさん
06/10/09 00:12:55
倒産したソフト会社のプログラム使ってるわけでもあるまいて
その会社がコンパイルし直せば済む事をチマチマとw

291:デフォルトの名無しさん
06/10/09 00:29:27
>>290
ユーザーが増えないから売れそうもないので対応しない
バイナリが流通しないから新しいアーキテクチャのユーザが増えない
以下繰り返し

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

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

293:デフォルトの名無しさん
06/10/12 15:26:01
OpenMPは全然性能が出ないとか書いてあるページがあるけど、どうなのかなあ。
適切に大きな粒度でやれば、スケールしないはずが無いと思うんだけど・・・

294:デフォルトの名無しさん
06/10/12 21:35:46
>>293
それは使い方間違ってるだけだろ。
俺が反論してやるからURLｷﾎﾞｿ

295:デフォルトの名無しさん
06/11/18 02:08:28
そいつの考え方がおかしいんじゃねーのかどこか知らんが

296:デフォルトの名無しさん
06/11/26 14:08:24
>>290
コンパイルできれば、そしてできたバイナリが予想通りの挙動を示してくれればいいんだけどね。

297:デフォルトの名無しさん
06/11/26 14:41:15
挙動不審

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

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

299:デフォルトの名無しさん
06/11/26 22:45:47
volatile最強宣言ｋｔｋｒ

300:デフォルトの名無しさん
06/11/26 22:53:22
> マルチコアって何で難しいの？同期処理も必要なの以外はvolatille宣言しとけばいいんじゃないの？
釣りですか？

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

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

301:デフォルトの名無しさん
06/11/26 22:54:32
訂正
> プロセス代数という数学。プロセス代数にはSP、π計算、CCSなどがある。
↓
> プロセス代数という数学。プロセス代数にはCSP、π計算、CCSなどがある。

302:デフォルトの名無しさん
06/11/26 23:10:00
ヘテロ環境での最適配置戦略とか
reconfigurableなLSIを活用するとか
学者さんは嫌いそうだが必要になりそう

303:デフォルトの名無しさん
06/12/20 00:38:23
おお、こんなスレが。
並列プログラム用のライブラリを作成しています。（C++/Unix用）
URLﾘﾝｸ(pards.sourceforge.jp)
よろしければ御意見下さい。

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

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

304:デフォルトの名無しさん
06/12/20 00:53:18
sureddo版を作る気はないのかえ？

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

306:デフォルトの名無しさん
06/12/20 02:09:16
なるほろ。

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

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

307:デフォルトの名無しさん
06/12/20 18:23:59
>>303
ネットワーク越しあり？

308:デフォルトの名無しさん
06/12/20 23:21:00
あら、すごいと思ったけど、やはりその筋の研究をされている方ですか。

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

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

次ページ