【マルチコア】並列化について語る【使いこなせ】
at TECH
[1からを表示]
50:デフォルトの名無しさん
06/01/19 15:24:48
そのうちマルチコアって言ってもCPUが4個とか8個とか16個とかが当たり前になるんだろうな。
そしてその後1スレッドを1CPUで動かす時代が来る。
51:デフォルトの名無しさん
06/01/19 15:31:48
10年後。
CPUのクロックは100GHzになり、16384コア32768コアも当り前になり、
メモリは256Gバイトが3千円ぐらい。HDDは250Tバイトが1万円を切る。
もちろんPCの電源を入れると複数個のOSが同時に起動する。
52:デフォルトの名無しさん
06/01/19 15:50:07
> CPUのクロックは100GHzになり、
わかってないな、こいつ
53:デフォルトの名無しさん
06/01/19 15:53:03
>>52
なるだろう。
54:デフォルトの名無しさん
06/01/19 15:54:53
>>52
電気で動くCPUとも書かれていないから良いんじゃない?
55:デフォルトの名無しさん
06/01/19 21:01:49
これが技術的に可能になれば100GHzのCPUや256GBのメモリもできるだろ。
URLﾘﾝｸ(www.nanoelectronics.jp)
そのころにはHDDもこれに置き換わっているかも･･･
URLﾘﾝｸ(www.nanoelectronics.jp)
究極の並列処理素子。ここまで行ったら･･･
URLﾘﾝｸ(www.nanoelectronics.jp)
56:デフォルトの名無しさん
06/01/19 21:44:58
実現してない話はどうでもいい
57:デフォルトの名無しさん
06/01/19 22:59:21
シングルコアで順調に速くなっていくんだったら、マルチコアなんて要らんだろ。サーバはともかく。
１０年で分子コンピュータ技術が実用レベルに達して商用になるかと言えば、ならない方に賭けるな。
だってCPUの基礎技術は２０年以上変わってないのでは？
58:デフォルトの名無しさん
06/01/19 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
( ＾ω＾) ∧＿∧
／ ＼ （ ）何言ってんだこいつ
.＿＿| | .| |＿ / ヽ
||＼ ￣￣￣￣ ／ .| | |
||＼..∧＿∧ (⌒＼|_＿./ ./
||. （ ） ~＼___＿_ノ| ∧＿∧
/ ヽ 氏ねよ ＼| （ ）
| ヽ ＼/ ヽ. ｵﾏｴ馬鹿だろ
| |ヽ、二⌒) ／ .| | |
.| ヽ ＼∧＿∧ (⌒＼|_＿./ /
59:デフォルトの名無しさん
06/01/19 23:04:43
前：デフォルトの名無しさん ：2006/01/19(木) 23:01:19
￣￣￣￣￣￣)／￣￣￣￣￣￣￣￣￣￣
( ＾ω＾) ∧＿∧
／ ＼ （ ）何言ってんだこいつ
.＿＿| | .| |＿ / ヽ
||＼ ￣￣￣￣ ／ .| | |
||＼..∧＿∧ (⌒＼|_＿./ ./
||. （ ） ~＼___＿_ノ| ∧＿∧
/ ヽ 氏ねよ ＼| （ ）
| ヽ ＼/ ヽ. ｵﾏｴ馬鹿だろ
| |ヽ、二⌒) ／ .| | |
.| ヽ ＼∧＿∧ (⌒＼|_＿./ /
60:デフォルトの名無しさん
06/01/19 23:34:08
分子コンピュータの開発なんてもう10年以上前からやってるわけだが
61:デフォルトの名無しさん
06/01/20 00:04:15
C MAGAZINE 2006年2月号
URLﾘﾝｸ(www.cmagazine.jp)
デュアルコア・マルチコアのCPUで大活躍
OpenMPで賢いマルチスレッドプログラミング（前編）
62:デフォルトの名無しさん
06/01/20 00:06:04
いい最終回だった
63:デフォルトの名無しさん
06/01/20 00:37:36
実際のところ最もパワーが必要になるのは鯖とかエンコとかゲームだから
それらはマルチスレッド化での効果はわりと大きいからべつにいいんじゃね？
>>48
あり
Java5のインクリメンタルGCのデフォ並列世代別GCになってる
通常のアプリが動いてる後ろでガリガリGCしてくれてる
そしてストップが必要になるGCについてもこれもオプションで並列動作可能
あずーるとかみたいにハードのサポートが来るのが一番だと思うけどね
そうでなくとも中間言語系はバックグラウンドでかなり動いてるから
アプリは何もしてなくても2コアでもびっくりするほど恩恵を受けるよ
64:デフォルトの名無しさん
06/01/20 00:51:17
Emacsのマルチスレッド化はいつのことになるやら・・・
65:デフォルトの名無しさん
06/01/20 02:55:56
>>61
前編で終るのか・・・。
66:デフォルトの名無しさん
06/01/20 03:01:37
最終号はなにか凝ったことするのかな
67:デフォルトの名無しさん
06/01/21 12:49:44
メモリー自体にCPUを乗せて、簡単な処理はメモリーが直接計算する、という案は駄目でつか？
今の技術なら、Z80CPU1万個を一枚のチップに乗せて、並列に計算させるぐらいの事は、
できそうな気がするけどな・・・無茶か？
68:デフォルトの名無しさん
06/01/21 12:50:44
>>67
消費電力が物凄い事になりそうだぞ？
69:デフォルトの名無しさん
06/01/21 12:52:41
>>67
似たようなアーキテクチャがNTTのCELLでなかったかい？
70:デフォルトの名無しさん
06/01/21 12:54:05
オブジェクト指向はクラスタ化のためにやるんだと思ってた・・・
71:デフォルトの名無しさん
06/01/21 12:56:33
普通の会社はメモリと密接にってのはまず無理
メモリってデータ取り出すだけでどういう動作するか分かってる？
せいぜいメモリコントローラ作ってフロントエンドで処理するしかないよ
Z801万個くらいの性能デイならFPGAでできそうだが
72:デフォルトの名無しさん
06/01/21 13:00:46
描画メモリーならレイトレースするエンジンがそんな感じだと思った
73:デフォルトの名無しさん
06/01/21 15:20:43
ようわからんが、これってそんな感じ？
GPGPU
ｽﾚﾘﾝｸ(tech板)
74:デフォルトの名無しさん
06/01/21 15:46:47
>>73
保守乙
75:デフォルトの名無しさん
06/01/21 16:43:50
よく知らんが、WRAMとかSGRAMとかVRAMとか、その系統じゃね？
もう名前を聞かなくなって久しいが。
まだ特定用途向けに使われてるのかな。
76:デフォルトの名無しさん
06/01/21 17:26:33
箱○に載ってるね。メモリアクセスだけで、Zバッファや
アンチエリアシングの処理をするのに使われている。
77:デフォルトの名無しさん
06/01/22 01:29:23
Cellはゲームに特化したプロセッサだから汎用には不向きだぞ。
78:デフォルトの名無しさん
06/01/22 03:06:27
だねえ、CELLは倍精度演算とか弱いし、特定のメディア用プロセッサであって
汎用CPUにはなれない。
そのかわりDSPの塊みたいなものだから用途が合えばめちゃ速いと思う。
79:デフォルトの名無しさん
06/01/22 10:13:15
mpeg2やDivXの高品質リアルタイムエンコ、とかは?
80:デフォルトの名無しさん
06/01/22 10:15:50
デジタル回路で処理してるだけかと
81:デフォルトの名無しさん
06/01/22 11:16:09
メモリというかレジスタだな。
82:1=メガデモスレ660
06/01/22 21:10:22
ｽﾚﾘﾝｸ(jisaku板)
マルチスレッドスレに貼り付けてあったんだけど、面白そうなので
ここにも貼っておく。アンチマルチコアって自分だけじゃないのを
初めて知った。PC自作板ってつまんないから全然みないんだよね。
83:デフォルトの名無しさん
06/01/22 21:16:12
つーか、アンチうざい
新しいのが出てきてそれについていけないやつだと思うけど
84:デフォルトの名無しさん
06/01/22 23:21:03
2コアぐらいなら、OSとアプリケーションでおおまかにひとつづつ使い切るような感じで、
別にシングルスレッドのアプリケーションでも意味あると思うんだよね。
だけど、４、８とコアが増えてくるとそうはいかない。負荷がかかってるのにも関わらず
アイドル状態のコアが出てきちゃいそう。
85:デフォルトの名無しさん
06/01/22 23:31:53
>>84
> 2コアぐらいなら、OSとアプリケーションでおおまか
> にひとつづつ使い切るような感じで、
流石にお馬鹿の Windows でも、そんなにＯＳのオーバー
ヘッドはでかくない。シングルスレッドプログラムではマル
チコア/マルチプロセサの恩恵はほぼないので、
> 負荷がかかってるのにも関わらずアイドル状態のコアが
> 出てきちゃいそう。
と言うのは、２コアでも十分ある。
86:デフォルトの名無しさん
06/01/23 00:49:24
>>85
自作板を見てると、DualはWindowsの体感速度が上がるからっていう理由で
買ってる人が多いみたいなんだよね。IEやエクスプローラを含めたOS全般と
自分の使ってるアプリケーションの両方が同時にスムーズに動くと。
だけど、そういう人たちでもさすがに４個や８個もの多コアは買わないだろうな
という気がした。
87:デフォルトの名無しさん
06/01/23 00:52:06
>>83
そういうやつが周りに一杯いるけどそういう奴は蹴落としていくしかないと思う。
なんとなく小泉総理が親友を作らず孤独な少年であったというのが分かる気がする
88:デフォルトの名無しさん
06/01/23 01:15:57
淘汰されるなら淘汰されるで歓迎
89:デフォルトの名無しさん
06/01/23 02:47:28
>>85
常に一個位アイドルなCPUが居るのって結構重要だったりする。
エンコやら異常事態やらで地獄の様に重い時でもUIの応答が軽いのはストレスを生まない。
90:デフォルトの名無しさん
06/01/23 06:14:19
それはnice値変えるだけでもいいような
91:デフォルトの名無しさん
06/01/23 07:30:41
それはniceなアイディアだ
92:デフォルトの名無しさん
06/01/23 08:55:09
アンチってなんなの？
マルチスレッドプログラムがかけない人なの？
シングルコアの性能をもっとあげる方法を発明できる人なの？
アンチとして存在してる意味がﾜｶﾗﾈ
93:デフォルトの名無しさん
06/01/23 09:40:16
>>92
今まで普通にプログラムを作ってきたプログラマー達だね。
彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
>>63の言うとおりにガベージコレクションの性能が上がったとしたらそれだけで彼らは失職の危機にさらされる。
まあ、主にゲームプログラマーだけどね。
実際ゲームはシングルスレッド信仰がすごい強い分野だと思う。
ただ、滑稽なのはゲームなんてクリエイティブな分野でそんなに技術屋さんがでしゃばっていること。
本当はマルチコアでどんな新しいゲームが作れるかを考えるべきなのにそれを邪魔するだけの典型的な既得権益者なので
外野としてはそんな害虫どもにはさっさと消えてもらうことを祈るだけだね
94:デフォルトの名無しさん
06/01/23 12:54:33
＞彼らは今まで作り上げ積み上げてきた自分の技術が無駄になるのではないかと戦々恐々としている。
＞おもにアセンブラ・C/C++を使ってシングルスレッドでのパフォーマンスを上げることに血眼になってきた人たち
それで困るのは半端な連中だけだ
きっちっとした技術を積み上げてきたヤシなら、それほど恐怖でもない
むしろ他の連中と差をつけるチャンスだ罠
95:デフォルトの名無しさん
06/01/23 13:25:29
>>93
ガベコレの性能とゲームプログラマの失職に何の関係がある？
あと、ゲームのどの変の処理にマルチスレッドを導入するべきだと思う？
96:デフォルトの名無しさん
06/01/23 14:51:31
>>95
GCの性能が上がったら高級言語でもそこそこゲームが作れるようになるじゃないか。
ベンチマークではC++と関数型なんてほとんど変わらないしな。
そうなるとある程度ライブラリとかフレームワーク作ったり業務系と同じようになってくるんじゃないかな?
単純にシングルコアの性能だけでも相当向上してるのだからそうやってやり方が変わって脱落者が出るのでは？。
どんなゲームがいいかは例えばRTSのようなゲームで個々のユニットを複雑なアルゴリズムで動かすとかはどうだ?
97:デフォルトの名無しさん
06/01/23 15:35:46
D言語の時代ｸﾙｰ?
98:デフォルトの名無しさん
06/01/23 15:56:06
DってGC性能が低いんだったっけ？
それ以前に仕様がまだ固定化されてないのが気になるが
それとDはスレッドの機能が初期のJavaベースで非常に少ない気がするんだが
今後マルチスレッドプログラミングが増えればこのへんとかネックになってくるかもね
ま、必要になってくれば標準APIとして実装されるとは思うけど
今後スレッドが言語に組み込まれてない環境は厳しくなるよね
99:デフォルトの名無しさん
06/01/23 16:43:54
>>96
処理速度の向上によって今までC/C++でしかできない・C/C++が望ましかったような
ゲームが、Javaや関数型言語でも実装できるようになるだろう、という予測？
それともイチから実装する難易度が超絶的に上がり、結果必然的に高レベルなライブラリが
整備されるので、高級言語だけでもなんでもできるようになるだろうという話？
後者は理解できるけど、前者は疑問なような気がする。
生産性の向上によって確保した知的資源は、更なる難問の解決に使われるのが普通だから。
（そうじゃないと低賃金労働でしか生き残れない）
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 でスケールするように作られているのか???
ネタ振りとしてはこれくらいで良いか?
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5389日前に更新/215 KB
担当:undef