[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/09 15:34 / Filesize : 215 KB / Number-of Response : 855
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん [2006/01/18(水) 08:31:11 ]
最近のCPUはマルチコアが技術トレンドになっています。

それに伴い、ソフトウェアは並列化というパラダイムシフトが
求められています。効率のよく並列化を実現するためにはアル
ゴリズムやデータ構造といった部分を根本から見直す必要が
あります。しかし、トレンドができてからあまり時間が経って
ないため、そいういったノウハウが蓄積されていません。

そこで、マルチコアを生かすためのソフトウェア設計というのは
どういうものか?という議論をするためのスレッドを立てました。

ソフトウェアの並列化に対して考えのある人や、インターネット
上のリソース、論文等があればどんどん書き込んだりリンクを
貼ってください。

【関連スレ】
OpenMPプログラミング
pc8.2ch.net/test/read.cgi/tech/1102483474/l50


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は不可能に挑んだようなものだな






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<215KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef