- 1 名前：デフォルトの名無しさん [2006/01/18(水) 08:31:11 ]
- 最近のCPUはマルチコアが技術トレンドになっています。
それに伴い、ソフトウェアは並列化というパラダイムシフトが
求められています。効率のよく並列化を実現するためにはアル
ゴリズムやデータ構造といった部分を根本から見直す必要が
あります。しかし、トレンドができてからあまり時間が経って
ないため、そいういったノウハウが蓄積されていません。
そこで、マルチコアを生かすためのソフトウェア設計というのは
どういうものか？という議論をするためのスレッドを立てました。
ソフトウェアの並列化に対して考えのある人や、インターネット
上のリソース、論文等があればどんどん書き込んだりリンクを
貼ってください。
【関連スレ】
OpenMPプログラミング
pc8.2ch.net/test/read.cgi/tech/1102483474/l50
- 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
ＥｆｆｉｃｉｅｎｔC++も肝心の部分は結局言及できずにたいしたことは書いてなかった。
だから、個別の事例をまとめるしかないと思うが、そういう記述をできる人は
その筋で仕事してたりする人ぐらいだから記事としては出てこないだろうし
結局は本人の試行錯誤という。
- 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 ]
- タスクシステムなんてこのＷＥＢ全盛時代にはもはや化石だなｗ
- 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の本３８ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。
たとえば、2コアのＣＰＵで１０００回のループのを並列処理するときに、grainsizeを５００にする、
４コアならgrainsizeを２５０にすることで、理想的にスケールするということなんでしょうか。
この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか（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分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってｗ
- 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すら知らなかっただけだけか
何が「基本を勉強しとけ」だよｗ
きっと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コアまでしかないからそれ以上は分からんｗ
- 582 名前：デフォルトの名無しさん mailto:sage [2008/05/31(土) 22:25:52 ]
- 初心者ですまんが
Ｐｇ作るのにマルチコアなんて気にする必要アンの？
いいところスレッド処理とか流せば
しかたねえな ってかってに動いてくれそうだけど
- 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の話も出ない
有益な議論のしようがないなｗ
- 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には無いと思う。
２つのスレッドを２つのコアにわけるなら話も早いけど、
１つのスレッドを２つのコアにわけると、なんか、戻りとか処理のオーバーヘッドがでかそう。
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はないわな。未熟だわなｗｗｗ
- 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の判断だけど、多分２つ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
あんまり調べる気無い。
何か映像関係の高速処理組むなら別だけど予定もないし。
スレッド、プロセス関連は完全に２、３継承のクラス化しちゃってるし、
いまさらOSの判断以上の速度が出るように直す気はない。
|
 |
