08/05/10 23:58:22
あーかなり勘違いしてたよ。
でも、そこに道があるような気がする。
アルゴリズムが分かりやすいし。
512:デフォルトの名無しさん
08/05/12 07:51:09
>>511
極めて単純なものだけに有効でしかないよ
総列挙を行うと、ひとつ条件分岐が増えるごとに二倍になる。倍々ゲームだからな。
宇宙の全素粒子をトランジスタにしたって追いつかないほどの並列度がすぐに必要になる。
そして、総列挙以外の方法で解けない問題はNP問題といって、楽しい研究対象だ。
量子コンピュータは、時間的な並行宇宙が倍々ゲームで増えていくことを利用して、
自分たちが感知できない別の宇宙にコンピュータを配置する、
今配置すれば、処理を何工程か経ることによって未来の並行宇宙に倍々ゲームでマシンを配置できる。
これに一斉処理をさせれば、宇宙の全素粒子の冪乗に当たるような並列度が取れるので、解けることもある。
ただし、結果を得る方法がきわめて特殊なので、結局解けないケースが多い。
それにしても一番気になるのは計算機よりも並行宇宙そのものだ。
513:デフォルトの名無しさん
08/05/12 21:09:31
量子コンピュータを神秘視しすぎだろwww
514:デフォルトの名無しさん
08/05/13 09:02:31
>>513
逆に問うてみようか、並行宇宙でないとすると、ありゃ何処で計算されてるいんだ？
どうころんでも、どう解釈してもキモ過ぎだよ
515:デフォルトの名無しさん
08/05/13 09:15:37
量子の状態は重ね合わせで表されるような状態である。
それは量子というものの性質そのものであって、解釈なぞどうでもよい。
キモいと言えばキモい性質ではある。
516:デフォルトの名無しさん
08/05/14 03:50:53
並行宇宙ﾜﾛﾀ
517:デフォルトの名無しさん
08/05/16 06:37:49
並行宇宙ヤバイ
518:デフォルトの名無しさん
08/05/16 19:49:58
>>512マジキモイ
519:デフォルトの名無しさん
08/05/16 19:51:44
2XXX年のオリコン一位
「並列宇宙」
520:デフォルトの名無しさん
08/05/16 22:01:54
>>517-519 話についていけないなら泣いていい(笑)
はたしてテンソル積はどこまでも増やしてゆけるのか
量子コンピュータをみていると、現在の物理法則はどこまで正しいかどうか見ものだよ。
521:デフォルトの名無しさん
08/05/17 01:31:05
Erlangスレに進展があったよ。
どっかのいい人がホームページ作ってくれたみたい。
522:デフォルトの名無しさん
08/05/17 03:24:15
宗教の話は他でやってくれないか。
523:デフォルトの名無しさん
08/05/17 04:33:17
ミクロとマクロの視点を
ごっちゃにしているアホが騒いでいるだけ
524:デフォルトの名無しさん
08/05/17 05:23:47
>>520
量子コンピュータが量子力学の正しさを証明しても
並行宇宙解釈が主流になる事は無いと思われ
525:デフォルトの名無しさん
08/05/17 05:33:35
ここム板やで。
526:デフォルトの名無しさん
08/05/18 14:45:50
>>1
boinc環境を用意してねらーを煽る。
527:デフォルトの名無しさん
08/05/18 19:38:01
懐かしの宇宙ヤバイを思い出した。
528:デフォルトの名無しさん
08/05/29 23:59:57
ちょっと、細かい質問なんだが、
tbbの本３８ページに書いてある、粒度ってどういう意味なんでしょうか。
本書曰く「grainsize は、プロセッサーに分配する妥当なサイズのチャンクに割当てる反復回数」とあります。
たとえば、2コアのＣＰＵで１０００回のループのを並列処理するときに、grainsizeを５００にする、
４コアならgrainsizeを２５０にすることで、理想的にスケールするということなんでしょうか。
この本肝心なとこの訳が意味不明で困る。
ーーマルチコアで並列処理をスケールさせることをテーマにしたよいほんないでしょうか（TBBのもいい参考書だとおもいますけど。）。
529:デフォルトの名無しさん
08/05/30 00:11:11
>>528
その本持ってないから意味不明で困る。
処理を細かい粒に分けて並列処理をする。粒度は粒の大きさだ。粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ。
530:デフォルトの名無しさん
08/05/30 00:16:56
>この本肝心なとこの訳が意味不明で困る
文句言ってる暇があるなら原著嫁
531:デフォルトの名無しさん
08/05/30 09:09:33
>>529
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな、ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
>>530
ツマンネー事いってないで必要な情報は全部書けよ、この自己完結野郎
532:デフォルトの名無しさん
08/05/30 09:31:16
>>531 の文書が変だとおもったのでちょっと修正
>粒を細かくすると並列度は上がるがオーバーヘッドが増える。環境に応じた適切な粒度に調整するわけだ
環境に応じて調整している間は現実性はないと思うな。
使える並列化にするには、コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
ソフトの開発は時間との戦いだ、それができないと理想論で終わってしまう。
それが不可能なら、VMなりを作ってそこで吸収できるような構造にする事が不可欠。
533:デフォルトの名無しさん
08/05/30 12:28:09
調整といっても、問い合わせたプロセッサ数で分割とか、100mS分くらいに分割するとか程度だろ。その程度のことで開発は時間との戦いとか理想論とかってｗ
534:デフォルトの名無しさん
08/05/30 13:41:29
>>533
ややこしいデッドロック問題とか、複数のマルチスレッドライブラリが組み合わさった状態とかまったく想定していないショボイ開発だけ見ているだろw
例えば、ライブラリが二つあるだけでも最優先で実行すべきコードが変化するんだぜ、囚人のジレンマって言ってな、個々ライブラリが最優先に実行してほしい物を最優先にすると、最低な結果になる事も結構あるんだぜ。
535:デフォルトの名無しさん
08/05/30 14:24:20
>>534
「複数のマルチスレッドライブラリが組み合わさった状態」
になったら「ショボイ開発」って思わなきゃダメだよ
536:デフォルトの名無しさん
08/05/30 15:42:06
10000行で完成する程度のコードしか組んだことないんだなw
537:匿名
08/05/30 15:45:44
並列・分散処理に関しては以下のホームページが参考になります。
主要な言語に対応したツールなどの紹介もあります。
www.cspjapan.org
538:デフォルトの名無しさん
08/05/30 16:46:39
>>537
宣伝でつか？
マルチポストでやるのは、あまりイメージ良くないですよ。
539:デフォルトの名無しさん
08/05/30 16:51:46
>>537
ちらっと見ただけだけど、通信部分が浮いている感じがするな、もっと洗練できると思う。
540:デフォルトの名無しさん
08/05/30 17:00:24
グリッドコンピューティング？には合ってる部分もあるのかもだけど
昨今のマルチコア活用方向とは全く合わんのじゃ…
大体想定環境・状況が古すぎるような…
541:デフォルトの名無しさん
08/05/30 17:06:31
プロセス代数は基本だと思うし、オブジェクト間通信という考えの元でも問題はないと思う。
マルチコア活用を阻害している最大の要因はパフォーマンスではなくて
直感的に記述することや効率よく記述すること、デバッグを容易にすることが重要だという点に気付いているかが気になった。
542:デフォルトの名無しさん
08/05/30 17:11:11
もうひとつあるな、現行残っているシングルスレッドモデルで記述された大量のコードを徐々に移行していくための仕組みがいる。
543:デフォルトの名無しさん
08/05/30 17:42:51
>>534
想定しなくていいように作るもんだろ
それに囚人のジレンマは場違いもいいとこ
544:デフォルトの名無しさん
08/05/30 17:58:10
>>532
> コードがスマートになる粒度にハードウェアを調節しないと駄目だ。
プログラマからするとソフトウェアもコードがスマートになるように作ってほしいですよね。
>>543
俺も思ったけど、Wikiみたら使い方あってるみたい。
> 囚人のジレンマ
> 個々の最適な選択が全体として最適な選択とはならない状況の例としてよく挙げられる問題。
545:デフォルトの名無しさん
08/05/30 18:01:14
>>543
すべてのライブラリが自家製とかありえないだろ、ふつう
546:デフォルトの名無しさん
08/05/30 18:12:32
>想定しなくていいように作るもんだろ
想定しなくていいように作る＝毎回開発でスクラップアンドビルド
だが、良いのか？
547:デフォルトの名無しさん
08/05/30 21:10:39
>想定しなくていいように作る＝毎回開発でスクラップアンドビルド
うわっバカだ
548:デフォルトの名無しさん
08/05/30 21:58:47
マルチスレッド並列化で解決すべき深刻な問題の一つだからな、保守性の無さと再利用性の低さは。
549:デフォルトの名無しさん
08/05/30 22:18:08
>>537
今更CSP紹介されてもな…何十年前の話題だよ。
CSPを普通に実装するとプロセス間をデータが流れることになり、
キャッシュを越えるコア間のデータ転送が増えて、途方もなく
効率悪いと思うんだが。
その辺まで言及してくれればこのスレ的な話題になる。
550:デフォルトの名無しさん
08/05/31 08:31:32
>>548
＞ 保守性の無さと再利用性の低さは。
STM はその辺強いのかね
551:デフォルトの名無しさん
08/05/31 13:48:09
>>550
変な用語を使うのはヤメレ、シングルスレッドモデルといいたいのだろうが・・・
ちょっとでも触ればマルチスレッドを使った並列化の現状が論外な状態だと判るはず。
可能ならとっくに流行っている。
552:デフォルトの名無しさん
08/05/31 13:50:49
>>549
現在のプロセッサの最大の弱点はプロセッサ相対で低速なメモリーであって
キャッシュ間の転送は、小さくはないが致命的でもない。
553:デフォルトの名無しさん
08/05/31 14:30:34
>>551
アフォか。Software Transctional Memoryだろが
554:デフォルトの名無しさん
08/05/31 14:56:15
>>552
一般論としてはそうだが例えばfork/joinはスティールされない限り
同じスレッドで実行することでデータ転送を減らすよう考慮されてる
スティールされるのが古いタスクからなのも同じ理由
それに比べてCSPはどうだ？
555:デフォルトの名無しさん
08/05/31 18:16:47
>>554
>fork/joinはスティールされない限り同じスレッドで実行することでデータ転送を減らすよう考慮されてる
SMT(ハイパースレッディング)が登場してから、おかしな対処をしないと性能がでなくなって必ずしもそうなっていないよ、今は。
556:デフォルトの名無しさん
08/05/31 18:24:58
>>555
そうか？tbbやjsr166yのfor/joinは>554で書いたようになってると理解してるが。
ソースｷﾎﾞﾝ
557:デフォルトの名無しさん
08/05/31 18:25:21
しかしまぁ、オペレーションズ・リサーチは情報系出身なら常識だろうと思うが、こういった基本すら知らない奴はどうしてくれるかなぁ
ゲーム理論や囚人のジレンマも知らないというのはどうかと思うんだ・・・
558:デフォルトの名無しさん
08/05/31 18:28:29
>>556
Core 2 Quadマシンと、Windows Vista 買ってきて、ひとつアプリを走らせろ
そして、タスクマネージャーなり、ガジェットからCPUメーターをダウンロードして睨めっこをするんだ
そうすれば、ソースも必要ないし説明するまでもない筈。
559:デフォルトの名無しさん
08/05/31 18:36:48
>>558
まさかProcessor affinityの話をしてるのか？
560:デフォルトの名無しさん
08/05/31 18:37:45
>>559
謎用語出す前に、基本を勉強しとけ
561:デフォルトの名無しさん
08/05/31 18:43:23
>>560
謎用語て…単なる煽りか？それなら消えてくれ
煽りじゃないなら>558とjork/joinのタスクスケジューリングの関係を説明してほしい
562:デフォルトの名無しさん
08/05/31 18:44:11
ソースだせと、なぞ用語で捲し立てるのが趣味なら消えてくれ
563:デフォルトの名無しさん
08/05/31 18:46:20
>>557
常識だと思うけど、大学卒業して10年の俺はさっぱり覚えてないw
564:デフォルトの名無しさん
08/05/31 18:46:37
頭の悪いGKがいる、絶対いるw
565:デフォルトの名無しさん
08/05/31 18:56:40
>>562
Processor affinityはWindowsでもLinuxでも商用UNIXでもAPIになってる
特定のプロセス／スレッドを特定のCPUに割り当てられやすくするもの。
fork/joinのスケジュールがスレッドのローカルなキューからタスクを
取ってくるのも新しいタスクをキューの先頭に入れるのも
他のスレッドからキューの後ろからスティールするのも
Processor affinityの元でスレッドが同じコア上で実行される場合に
キャッシュが効率的に使われることを目指していると俺は理解している。
さて、>555や>558について説明してもらえないかな
566:デフォルトの名無しさん
08/05/31 18:58:27
>>565
CPUメーターみてみなよ、OSが勝手にスケジュールを調整してこちらの意向を無視している。
567:デフォルトの名無しさん
08/05/31 19:03:08
>>566
そのアプリがSetThreadAffinityMask読んでないなけだろ
568:デフォルトの名無しさん
08/05/31 19:04:05
>>567
単に、特定アプリに依存すると障害が多いからMSが調整しただけかと
569:デフォルトの名無しさん
08/05/31 19:08:58
>>568
意味が分からない
SetThreadAffinityMaskを呼び出していないスレッドをOSが勝手に
スケジュールするのは当然のことだ
お前さんの言ってるアプリはSetThreadAffinityMaskを呼び出してるのか？
呼び出してないアプリでCPUメーター見ても全く意味がないんだが
Processor affinityを知らなかっただけじゃね？
570:デフォルトの名無しさん
08/05/31 19:10:20
そっちの言っている事こそ意味不明だわw
571:デフォルトの名無しさん
08/05/31 19:12:50
じゃあさ、>558で「ひとつアプリを走らせろ」のアプリが
SetThreadAffinityMaskを呼び出してるアプリのことかどうかだけ答えてくれ
yes/noだけでいいからさ
572:デフォルトの名無しさん
08/05/31 19:14:01
こんなの、つまらないコード書いて、パフォーマンス確認目的でパフォーマンスカウンタ見れば一発なんだが・・・
なんでこんなややこしい話が登場するのかと・・・
573:デフォルトの名無しさん
08/05/31 19:14:46
バカ相手にするのは疲れる
574:デフォルトの名無しさん
08/05/31 19:22:31
>>572
ややこしい話はしていない
そのつまらないコードでSetThreadAffinityMaskを呼んだのかどうか、それだけだ。
これもyes/noだけでいいから答えてくれ
575:デフォルトの名無しさん
08/05/31 19:31:59
SetThreadAffinityMaskじゃなくSetProcessAffinityMaskなら
タスクマネージャーから設定できる。
プロセスタブでプロセスを選んで右クリック、関係の設定でCPUを選ぶだけ
576:デフォルトの名無しさん
08/05/31 20:07:00
逃げたようだな。結局Processor affinityすら知らなかっただけだけか
何が「基本を勉強しとけ」だよｗ
きっとfork/joinも何のことかわかってないんだろうな…
577:デフォルトの名無しさん
08/05/31 20:31:28
割り込んでごめんなさい。
windows 2k serverってマルチコアに対応してますか？
windows serverは全部対応してるって記事をネットで見たけど、
記事自体、いまいち信用できないんです。
578:デフォルトの名無しさん
08/05/31 20:57:52
雑誌記事が信用できずに、誰の発言かもわからない
掲示板の話を信用するんですか？
579:デフォルトの名無しさん
08/05/31 21:16:49
>>578
どっちもどっちですが、広告だらけのブログで「対応してる。」って言われるのと比べるなら、
まだ、ここのほうが信用できます。
「ここで公式に書いてるよ！」みたいなレスがあればなぁなどと思った次第です。
580:デフォルトの名無しさん
08/05/31 21:31:15
それプログラミングと関係ないだろスレ違いだしageんな
581:デフォルトの名無しさん
08/05/31 22:21:36
>>578
P4-2.4Cで2個見えてるから、2個までは対応してると思うよ
＃手元に2コアまでしかないからそれ以上は分からんｗ
582:デフォルトの名無しさん
08/05/31 22:25:52
初心者ですまんが
Ｐｇ作るのにマルチコアなんて気にする必要アンの？
いいところスレッド処理とか流せば
しかたねえな ってかってに動いてくれそうだけど
583:デフォルトの名無しさん
08/05/31 22:35:21
そのいいところってのが難しいんじゃない？
いままでみたいな粗い粒度のスレッドの使い方じゃなくて、もっと積極的に
例えば単なるクイックソートを2～4スレッドで並列実行して高速化しようとか、
そういうのを考えるんじゃないかなたぶん
584:デフォルトの名無しさん
08/05/31 22:35:59
>>582
ここは君が来るところではないんだよ。
ここはデュアルコアならシングルコアの2倍、クアッドコアなら4倍の
パフォーマンスを目指すスレ。
今のところ有益な議論は一度もないけどな。
585:デフォルトの名無しさん
08/05/31 22:54:45
Processor affinityも知らないSoftware Transactional Memoryも知らない
wait freeやlock freeの話も出ない
有益な議論のしようがないなｗ
586:デフォルトの名無しさん
08/05/31 22:56:05
>>584
キャッシュに入るような小さな処理から頻繁にメモリアクセスが必要な処理をした際
実際のパフォーマンスを比較したものってどっかにないの？
587:デフォルトの名無しさん
08/05/31 23:03:12
マルチスレッドスレと話題かぶるからなぁ
588:デフォルトの名無しさん
08/05/31 23:17:48
>>582
俺も気になった。
winのapiには無いと思う。
２つのスレッドを２つのコアにわけるなら話も早いけど、
１つのスレッドを２つのコアにわけると、なんか、戻りとか処理のオーバーヘッドがでかそう。
win上で動くプログラムからそこを制御できるかも、よくわかんないし。
と、初心者は思うのでした。
589:デフォルトの名無しさん
08/05/31 23:52:50
初心者だと思うなら、「winのapiには無いと思う。」なんてろくろく調べもしないで
レスするなよ。
590:デフォルトの名無しさん
08/06/01 00:07:59
マルチコア対応apiはwinにはないね。未熟なOSなのかも。
591:デフォルトの名無しさん
08/06/01 00:18:47
同一ソケット上のマルチコアに特化したAPIはないわな。未熟だわなｗｗｗ
592:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/06/01 00:22:55
>>589
嫌味な上級者は、絶対何も言わないんだよな。
さっきからずっと、むかつくレスしてんのこいつだろ？
上司でたまにいるんだよ。
知ったかして、具体的に何も言わないで、誰かが言ったら便乗するやつ。
594:デフォルトの名無しさん
08/06/01 00:27:06
そりゃ、言うべきじゃない時を心得てるのが上級者というものだからなあ
595:デフォルトの名無しさん
08/06/01 00:31:12
>>592
MSDN見たなら「参照」も見るといいよ
596:デフォルトの名無しさん
08/06/01 00:43:55
>>592
あんまり調べる気無い。
何か映像関係の高速処理組むなら別だけど予定もないし。
スレッド、プロセス関連は完全に２、３継承のクラス化しちゃってるし、
いまさらOSの判断以上の速度が出るように直す気はない。
597:デフォルトの名無しさん
08/06/01 00:44:33
時代がマルチコアなのになぜ対応apiがないのか？
これはMSの怠慢ではないだろうか
高いOSライセンス代（１台につき１万～３万）を定期的（５年程度）に払っているというのに
ひどい話だ
598:デフォルトの名無しさん
08/06/01 00:51:54
>>597
マルチコア対応APIって具体的にどういうものよ？
599:デフォルトの名無しさん
08/06/01 01:06:17
>>597
だからwindowsにもあるって。
プロセッサを直接指定できるapiが。
やっぱNT系のカーネル作った連中は偉いわ。
おれもまだまだ2kで行く。
600:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/06/01 01:12:08
マルチダイもマルチコアに含めてるしな、、、思想的には
ていうか、やっぱまだ２ｋって需要あるかなー？
今新規にフリーソフト作ってるが、どこまでサポートするか悩む
602:デフォルトの名無しさん
08/06/01 01:15:22
>>599
Processor affinityはDECのVMSの時代からある。
WindowsNTと作った連中は同じだけどなｗ
603:デフォルトの名無しさん
08/06/01 01:19:14
>>601
俺、フリーソフトは、2kで作って、xpで軽く動かしてテスト終わり。
2kで動いて、xpで動かなくなったことはない。
基本、Direct X関係に気をつけるだけ。
604:デフォルトの名無しさん
08/06/01 01:22:24
CPUが別パッケージかオンダイかを気にするような場面には出くわしたことないなあ
キャッシュの奪い合いとか同期の頻度とかが問題になるのかな？
むしろhyper threadingが特別だったんじゃないかと思う
605:デフォルトの名無しさん
08/06/01 01:24:49
Win32のSetThreadAffinityMaskはaffinity maskがDWORDで32bitしかない
64/128/256のSuperdomeはOSからは256プロセッサに見えるんだがどうするんだ？ｗ
606:デフォルトの名無しさん
08/06/01 01:27:16
hyper threadingは鬼門
607:デフォルトの名無しさん
08/06/01 01:29:44
>>606
Pen4のHyper Threadingだけが鬼門？ SMT全般が鬼門？
ちょっとだけPower使ったときは何もなかったけどな
608:デフォルトの名無しさん
08/06/01 02:01:39
>>605
いずれSEtThreadAffinityMaskExが出来るだけよ
609:デフォルトの名無しさん
08/06/01 02:05:55
>>608
いずれってかSuperdomeにWindowsが乗ってから5年以上経ってないか？
Windows乗ったSuperdome俺は見たことないけどｗ
610:デフォルトの名無しさん
08/06/01 02:08:16
テキトウに仮想化でもしたほうが効率よさそうな気が
611:デフォルトの名無しさん
08/06/01 02:14:38
>>610
それは現実的すぐるｗ
とりあえずタスクマネージャーはこうなる
URLﾘﾝｸ(www.microsoft.com)
これで「関連の設定」は64CPU設定できるのか？
つかItaniumだから64bit Windowsか…
612:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/06/01 03:25:02
>>607
606じゃないけど、HTは面倒な存在じゃない？
普通のマルチプロセッサなら異なるプロセッサ間で同じキャッシュラインに
アクセスしない方が良いが、HTの場合は逆でしょ？
ベンチ取ってないんで、どのくらい影響があるのかは具体的には分からんが。
614:デフォルトの名無しさん
08/06/01 03:36:55
menndouda
615:デフォルトの名無しさん
08/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:デフォルトの名無しさん
08/06/03 13:35:38
マルチコア対策としてこんなのがあります。
URLﾘﾝｸ(www.axon7.com)
また、これも参考になります。
URLﾘﾝｸ(www.cspjapan.org)
617:デフォルトの名無しさん
08/06/03 13:45:14
>>616
>537
618:デフォルトの名無しさん
08/06/03 13:58:55
マルチプロセス、マルチスレッド、マルチコア、マルチプロセッサ、SMT、メモコン共有、キャッシュ共有、演算器共有。
これが複合的に絡んだときの最適化は複雑すぎる。
619:デフォルトの名無しさん
08/06/03 14:44:35
>>617
>549
620:デフォルトの名無しさん
08/06/03 14:47:41
間違えた、>619は>616へ。
>>618
それをコンパイラで成し遂げることが前提のItaniumは不可能に挑んだようなものだな
621:デフォルトの名無しさん
08/06/05 13:51:00
マルチコアは、今までのソフトウェア技術を台無しにしてくれる素晴らしい技術だよね。
これからはソフトウェアとハードウェアの境界が無くなって、
プログラムを作るのは、より一層大変になる。
622:デフォルトの名無しさん
08/06/05 14:08:33
ハードとソフトが緊密に絡む領域はこれまでもあったんだけどな
無停止システムとか
623:デフォルトの名無しさん
08/06/05 14:08:49
今までのマルチプロセッサ向けのソフトウェア技術の延長にあるから
台無しという事は無いよ。もう何十年も研究が続けられている分野だ。
624:デフォルトの名無しさん
08/06/05 15:54:23
何十年も研究とか、無駄の極地だねｗｗｗ
625:デフォルトの名無しさん
08/06/05 16:04:53
ロックフリーのアルゴリズムやトランザクショナルな変数アクセスが
もっと一般化してくれば、そんなに恐れる物でもない気がするけどね
626:デフォルトの名無しさん
08/06/05 17:43:57
>>621
いったい何に怯えているんだろうか
627:デフォルトの名無しさん
08/06/05 18:51:05
まあそりゃ単一スレッドで速くなるほうがありがたいけどな
628:デフォルトの名無しさん
08/06/05 19:06:01
荒い粒度の並列化や、ベクトルの並列処理はとっくに研究され尽くされてるけど、
その中間が非常に厄介。
しかし、これからは単一スレッドでは速くならないわけだから、それをやらないといけない。
629:デフォルトの名無しさん
08/06/05 19:53:53
ループを展開する自動並列化くらいはインフラとして整備して欲しいね
630:デフォルトの名無しさん
08/06/05 23:02:40
>>629
自動じゃなくてもparallel array使えばおk
631:デフォルトの名無しさん
08/06/05 23:56:43
>>628
divide and conquer
work stealing
fork/join
parallel array
632:デフォルトの名無しさん
08/06/07 23:32:29
遅レスだが
ハードウェア・ソフトウェア協調設計等は組み込みでは昔からよく見られるんじゃないか？
まあ、シミュレーター等の開発統合環境が整えられているなら最適化はむずかしくないよ。
ただ工数と時間と労力が膨大に費やされていくだけで
633:デフォルトの名無しさん
08/06/13 19:49:18
組み込みの場合は、環境のプロセッサ数やプロセス数は固定されてるから、難易度は低いんじゃないかな。
PCの場合は、対象のプロセッサ数は予想できないし、同時にどんなプロセスが動くかも分からないから、難易度が高い。
というか、PCの場合は、何らかの動的最適化メカニズムが必要になるんだよね。
URLﾘﾝｸ(pc.watch.impress.co.jp)
インテルはCを拡張してJITコンパイラで最適化する研究をしてるようだけど、
実用化はまだまだ先だよな。
634:デフォルトの名無しさん
08/07/06 06:28:11
１．マルチなんたらとか並列化とか、なにも考えずに作る。
２．あとは開発環境とOSがなんとかしてくれる。
３．下手なこと考えるより、そのほうが最終的に効率が良い。
こういうのが理想なんだけどなぁ…。
635:デフォルトの名無しさん
08/07/06 09:34:03
スレ民じゃないけどマルチコアネタがあったのでぺたぺたしていきます。
「Ruby 1.9は1.8より平均5倍速い」、YARV笹田氏 － ＠IT
URLﾘﾝｸ(www.atmarkit.co.jp)
今後のテーマは並列処理によるスケーラビリティ向上
今後の研究テーマとして笹田氏は、並列処理への対応など
スケーラビリティに取り組みたいと話す。ただ、「Rybyの言語仕様の
枠組みでスケーラビリティを上げるのは難しい」ため、マルチコア、
マルチプロセッサといった密度の高い並列化よりも、クラスターや
グリッドのようにネットワークで接続された複数ホストによる並列化を
実現していくのがいいのではないかという。
636:デフォルトの名無しさん
08/07/06 10:51:06
>>634
それ何て第五世代
>>635
むしろマルチコア関係なくね？
637:デフォルトの名無しさん
08/07/06 10:59:42
マルチコア向けの最適化はしない方向だ、という内容だな。
638:デフォルトの名無しさん
08/07/06 16:27:58
今後もRubyのスレッドはマルチコアを使いこなすようにはしない方針ということだな
639:デフォルトの名無しさん
08/07/06 16:42:50
Rubyなんて並列化のこと何も考えてないじゃん。
書いててわくわくするとか日和ったこと言ってる言語では到底無理。
640:デフォルトの名無しさん
08/07/06 20:49:23
並列化に興味をもったRuby使いはErlangあたりに移行するのだろうか
641:デフォルトの名無しさん
08/07/06 23:42:11
アルファブロガー（笑）あたりに煽ってもらえばイッパツよ
642:デフォルトの名無しさん
08/07/07 14:51:27
jruby
643:デフォルトの名無しさん
08/07/12 12:34:27
Erlangが騒がれてるのは副作用がないのとメッセージングがあるからなの?
ほかの言語でも多少見苦しくなっても同じことはできんの？教えてエロイ人。
644:デフォルトの名無しさん
08/09/06 10:33:33
>クラスターや
>グリッドのようにネットワークで接続された複数ホストによる並列化を
>実現していくのがいいのではないかという。
ハードは明らかにマルチコアに進んでいて、
サーバも集約統合が進んでいるというのに。
Rubyみたいなソフト側が手前の都合だけで
「いいのではないか」とかいって方針だしても何の意味もないわけだが。
誰もそんなハード持ってません。
今のハードにあってません。
ってなるだけ。
645:デフォルトの名無しさん
08/09/06 17:36:31
なに、寝ぼけたレスしてるんだ？
>>644 は、Ryby という新言語について語っているんだぞ。
646:デフォルトの名無しさん
08/09/06 19:45:47
>>645
誰に言ってるの?
647:デフォルトの名無しさん
08/09/06 20:28:00
なに、寝ぼけたレスしてるんだ？
>>644 は、Ruby という言語について語っているんだぞ。
648:デフォルトの名無しさん
08/09/06 20:50:57
なんだ、キ印か。
649:デフォルトの名無しさん
08/09/27 22:48:29
>>644 って、Googleのサーバーとか、AmazonのEC2とか、分散環境が流行ってるのを知らないのか。
サーバーの集約統合が進んでるのは、既存のサーバーや負荷の低いサーバーでしょ。
650:デフォルトの名無しさん
08/09/28 17:23:48
分散環境が流行ってるって…
すごい規模なんだからどっちにしても分散が必要なのは当たり前。
googleなんかは2003年の時点でこれからはマルチコアみたいなこと言ってるぞ。
651:デフォルトの名無しさん
08/09/28 17:40:39
実際流行ってるんだけどなぁ。
クラウドとかいうキーワードでぐぐってみりゃわかると思うよ。
実効性はともかくね。
652:デフォルトの名無しさん
08/09/28 17:44:47
クラウドが流行ってるってのはSOAが流行ってるってのと
どっこいどっこいだな。
ごく一部で当たり前になってるのと広く使われてるのとは
全然違ってて、どっちの話をしてるかがズレてるんだな。
653:デフォルトの名無しさん
08/09/28 17:49:52
P2P→グリッド（言い換え）→クラウド（言い換え２）
654:デフォルトの名無しさん
08/09/28 17:50:04
オフコン時代の鯖だと鯖っていえば特定の対応関係になってたのが
OOのポリモフィズムみたいな多態になっただけだ
C<->Sの関係が1:1だったのが
C<->Sの関係がN:Mになっただけだ
SOAはC<->Sの関係がN:1だったがな
たしたことない。言葉変えて変化を促そうとしている単なる言い換えだ
詐欺の一種だ
655:デフォルトの名無しさん
08/09/28 17:56:49
クラウドとマルチコアって関係ないじゃん
656:デフォルトの名無しさん
08/09/28 18:12:59
まあ関係はないね
ハードの保守性とソフトのスケーラビリティを考えて、
マルチコアのマシンを仮想化してクラウドにするみたいな
話は聴いた事あるけど
>>654
ハイプで成り立ってる所も大きいから、そんなもんかと
URLﾘﾝｸ(www.atmarkit.co.jp)
657:デフォルトの名無しさん
08/09/28 18:41:15
とりあえずクラウドはスレ違いだろ
並列化の粒度が違う。クラウドは祖粒度、こっちは細粒度
ネタがないから構わんけど
658:651
08/09/28 18:45:37
>>652
どっこいどっこいというか、いままでSOAをかついでたところが、クラウドを担ぐようになってる。
SOAのように、クラウドは流行っている。まあそういう意味だ。
この件は、これで。
659:デフォルトの名無しさん
08/09/28 18:52:32
すかしっ屁こいてクライアント騙すのがクラウドなのか？
660:デフォルトの名無しさん
08/09/28 18:59:16
そう思う奴はいつまでも足踏みしてればいいのさ
661:デフォルトの名無しさん
08/09/28 19:07:46
>>657
×祖粒度
○粗粒度
662:デフォルトの名無しさん
08/09/28 21:04:14
クラウドもSOAもわかってないやつ多すぎ。
そんなやつらがマルチコア云々なんてしょーもねー。
せいぜい単純労働者としてコキ使われてなｗ
663:デフォルトの名無しさん
08/09/28 21:08:22
どっちもバズワードなんだから分かっているという方がおかしい
664:デフォルトの名無しさん
08/09/28 21:36:35
バズワード自体がバズワードというパラノイア
665:デフォルトの名無しさん
08/09/28 21:46:40
バズワードを使ってる人間はバズワードかどうかなんて気にしていないから、
一回りして結局おk
666:デフォルトの名無しさん
08/09/29 17:24:22
>>658
SOAと普及でぐぐると
・普及が進まない
・普及促進
・普及狙う
・普及を目指す
・普及を後押しする
こんなんばっかですけど？
流行ってるけど普及しない。笛吹けど踊らずw
667:デフォルトの名無しさん
08/09/30 01:37:12
クラウドはどうかと思うが、分散は物理的な話でもあるし必要なところには普及するんじゃないかな。
CPUでの並列だと限界が低いし拡張も難しいから、>>656の言うようなマルチコアマシンの仮想化で分散ってのが現実的ではないだろうか
668:デフォルトの名無しさん
08/09/30 07:01:26
つまり金融工学みたいな
もんですね
669:デフォルトの名無しさん
08/10/01 18:54:26
「クラウド・コンピューティング」は「仮想化」以来の“乱用語大賞”
URLﾘﾝｸ(www.computerworld.jp)
670:644
08/10/01 20:30:34
644ですが普段アーキスレとかに書いている身からすると、
このスレの住人はレベルが低すぎます。
キミらが並列化について語るのはまず無理。
チップあたりの性能をあげられなくなったら、
分散処理でも同一コストで性能あげられないの。
Rubyの件はいかにもソフトしかしらない人向けの
苦しいいいわけだなあと。
671:デフォルトの名無しさん
08/10/01 20:51:50
自分以外みんなバカ症候群
672:デフォルトの名無しさん
08/10/01 23:06:07
ひんと: 賢い奴はこんなスレの住人なんて相手にしない
673:デフォルトの名無しさん
08/10/02 00:04:30
レベルが低過ぎてどこを縦読みすれば良いのか分からないや
674:デフォルトの名無しさん
08/10/02 00:21:48
アーキスレってどこ？
殴りこみかけてくる
675:デフォルトの名無しさん
08/10/02 00:59:37
残念だけど、現状ではマルチコアってサーバサイドや一部の
embarrassingly parallel な処理以外では絵に描いた餅だよね。
デスクトップ機でクアッドコア以上のプロセッサが必要な
場面は思い付かない。それこそハード寄りの知識を持っていない、
スレッド周りの実装の知識も無い様なプログラマが、難しい事を
考えずに処理性能を出せる仕組みが欲しい物だね。fork/join でも
ヘテロなマルチコアでも何でも良いけど。
676:デフォルトの名無しさん
08/10/02 01:16:48
後はトランザクショナルメモリと投機的実行も期待してるけど
なかなかこういうのは普及しないねえ…
677:デフォルトの名無しさん
08/10/02 01:20:49
ゲーム機でやってるじゃん
678:デフォルトの名無しさん
08/10/02 02:33:49
>>676
投機的実行ってRockのスカウトスレッド？
命令レベルの投機的実行と紛らわしいから用語は分けたいな
同時投機スレッド(Simultaneous Speculative Threading)とかな
トランザクショナルメモリはどうかねー
RockのHTMじゃアプリケーションレベルのトランザクション
扱うのは無理だしSTM組み合わせるとオーバーヘッドが大きすぎて
性能出ないと予想してる
つRockの出荷来年の後半とか遅れすぎだろjk
679:デフォルトの名無しさん
08/10/02 20:15:08
今普及しているデュアルコアマシンみたいな感じで
6 core のマシンが一番売れ筋のマシンになったら
プログラマはどうすればいい?
680:デフォルトの名無しさん
08/10/02 21:08:30
Vistaをお勧めする
あとセキュリティソフトを３つぐらい重ねがけ
これで万全
681:デフォルトの名無しさん
08/10/02 21:30:33
>>674
CPUアーキテクチャについて語れ Part.12
ｽﾚﾘﾝｸ(jisaku板)
最近は常駐コテの意地の張り合いばかりでつまらないくなってきてるけど
アーキテクチャスレは↑
普段は名無しだが、MACオタ(翻訳)などは漏れ。
がんばって殴り込みに言ってくれや。
682:デフォルトの名無しさん
08/10/02 21:43:42
>>681
なんでこのスレ来てるの？
683:デフォルトの名無しさん
08/10/02 22:18:05
>>681
2chらしいスレだなw
40 名前：Socket774[sage] 投稿日：2008/08/29(金) 02:47:03 ID:Yk6PbdtE
ま、MACオタよりよっぽどマシな態度なんで、いじめるのはここまでにします
とか書かれててﾜﾛﾀ
お前そんなに態度悪いのかよw
684:デフォルトの名無しさん
08/10/02 22:36:01
ダンゴさんそこでがんばってたのか
お似合いだなｗ
685:デフォルトの名無しさん
08/10/02 22:43:59
せっかく収まるところに収まってるのに煽らないでくれ。頼むから。
686:デフォルトの名無しさん
08/10/03 00:45:17
644みたいな状態って、自分の専門は知ってるんだけど他のことは知らなくて、自分の知らないことはたいしたことないって思ってるだけなんだよね。
というか、自分が他のことを知らないことを知らない。
だから、「このスレの住人はレベルが低すぎ」とか言っちゃう。
687:デフォルトの名無しさん
08/10/03 00:48:56
でもまぁ、このスレのレベルが低いのは事実だろう。
レベル高い議論って一つでもあったか？ないよな。そういうことだ
688:デフォルトの名無しさん
08/10/03 00:53:53
マルチコア用のテンプレートライブラリを活用しているという話を聞かないね
良さげなのにググっても実際に使っている例が殆ど出て来ない
C++ の人気が無いのかテンプレートが嫌われてるのか…
URLﾘﾝｸ(www.threadingbuildingblocks.org)
URLﾘﾝｸ(spc.unige.ch)
URLﾘﾝｸ(sourceforge.net)
URLﾘﾝｸ(www.extreme.indiana.edu)
689:デフォルトの名無しさん
08/10/03 01:26:23
ライブラリの話はマルチスレッドスレがあるからなあ
このスレいらない子なんじゃ…
690:デフォルトの名無しさん
08/10/03 01:39:29
>>687
「住人はレベルが低すぎ」などと書いて無用に荒らすのが一番レベル低いがな。
691:デフォルトの名無しさん
08/10/03 02:36:30
>>689
要らなかったらスレが亡くなるだけだから気にしなくておk
692:デフォルトの名無しさん
08/10/03 03:39:27
>>689
マルチスレッドとマルチコアでの並列化は違う。
693:デフォルトの名無しさん
08/10/03 04:03:36
>>692
どう違うか語ってもらおうか
694:デフォルトの名無しさん
08/10/03 04:06:23
マルチスレッドは、タイムスライスで同時に動かなくてもおけ
695:デフォルトの名無しさん
08/10/03 04:31:02
マルチスレッドが並列に動かなくていいわけないだろ
マルチコア以前からマルチプロセッサは当たり前にあるんだしよぉ
本気でレベル低いなここ…
696:デフォルトの名無しさん
08/10/03 05:34:37
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできなくてもマルチスレッドは可能ってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。
697:デフォルトの名無しさん
08/10/03 07:28:21
windowsもクラウドが標準になるんだな
URLﾘﾝｸ(japanese.engadget.com)
698:デフォルトの名無しさん
08/10/03 10:41:52
>>696
・・・この人、シングルコアのシングルプロセッサで、CPUが同時にひとつの仕事しかできない時のマルチスレッドとマルチコア/マルチプロセサでのマルチスレッドじゃ状況が違うってことわかってるのかな？
しかし、ほんと、自分の無知をしらずに、他人のレベル低いって言うのは恥ずかしいな。
>>692
そもそも、マルチコアとマルチスレッドを比較するなよ。
699:デフォルトの名無しさん
08/10/03 10:53:10
>>698
おいおい、状況は違うのは分かるが、プログラムは同じにしとかないと
まずいだろ。
どこかのエンコソフトみたいにCPUのコア数によって使うルーチンを切り替える
ようにするなら話は別だが。
700:デフォルトの名無しさん
08/10/03 11:50:27
誰もプログラムを別にするとかなんて言ってないけど？
状況が違うと言うのはシングルコア and シングルプロセサで問題ないプログラムでも
マルチコア or マルチプロセサで問題が発生するケースがあるってだけ。
種々の要件によって、その状況によってプログラムを切り替える実装はあると思うが、
それはもっと条件を限定しないと議論できない。
701:デフォルトの名無しさん
08/10/03 12:03:57
デッドロックとかレース状態とかそういう次元の事かな。
確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
マルチコアにした途端に顕在化する場合はあるね。
702:デフォルトの名無しさん
08/10/03 12:37:48
>>701
マルチスレッドプログラミングとしては単なるバグじゃん
703:デフォルトの名無しさん
08/10/03 12:38:00
> 確かにシングルコアでは問題ありとしながら問題が潜在化してたものが
> マルチコアにした途端に顕在化する場合はあるね。
そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
プロセサではあり得ない問題」のことだよ。
704:デフォルトの名無しさん
08/10/03 12:39:40
>>703
それはクリティカルセクションを入れるのが当たり前だろ
705:デフォルトの名無しさん
08/10/03 12:40:56
>そうじゃなくて、例えばメモリに対する inc 命令の実行中に他のコア/プ
>ロセサのアクセスが割り込んじゃうとかの「シングルコア and シングル
>プロセサではあり得ない問題」のことだよ。
アトミック操作でないのにロックせずに破壊した場合プログラマの責任だと思うが。
706:デフォルトの名無しさん
08/10/03 12:42:23
>>703
そんなバグ埋め込んでマルチスレッドとか恥ずかしいぞ
707:デフォルトの名無しさん
08/10/03 12:43:53
>>703
もうちょっとOS関連の本を読んでマルチプロセス/マルチスレッドに
ついて勉強してから書いた方がいいよ。恥かくだけだぞ今のままじゃ。
708:デフォルトの名無しさん
08/10/03 13:08:13
>>698
そもそもというなら、マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
「マルチスレッドが並列に動かなくていいわけないだろ」とか言っておいて逆切れせずに。
709:689
08/10/03 13:38:17
>>708
比較なんかしてないぞ
マルチスレッドがマルチコア環境で正しく並行動作するのは当然
だからライブラリの話はマルチスレッドスレの方がそれなりに議論してて
適切だろうってことだ
マルチスレッドスレを並行動作しなくていい話題に限定したら
糞スレ確定で速攻落ちるぞw
710:デフォルトの名無しさん
08/10/03 13:44:20
同じ変数を複数スレッドで更新する可能性があるなら、UP/MPに限らずバリア入れる。
更新するのが一人だけだったら、ちょっと考えてから決める。
711:デフォルトの名無しさん
08/10/03 13:44:22
そういう話は、その時点でやってくださいな。
あと出しで切れるのカコワルイ
712:711
08/10/03 13:44:54
>> 709 ね。
713:デフォルトの名無しさん
08/10/03 13:49:36
>>711
どこが後出し？w
714:デフォルトの名無しさん
08/10/03 17:59:44
>>704
そもそもクリティカルセクションをどう構成するかと言うレベルの話だから、
君には用はないので当分 ROM っててくれ。
>>705-706
シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
マルチコア/マルチプロセサではちゃんと動かないから良くないコーディングと
言うならまだわかるが。
>>707
どこがどうおかしいかちゃんと指摘してくれ。
まさか、>>705-706 の的外れの指摘のこと言ってるのか？ (w
715:デフォルトの名無しさん
08/10/03 20:19:54
>>714
アホですか
RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
物があるのでアトミックではない場合がある
716:デフォルトの名無しさん
08/10/03 20:20:58
つーか明らかな自分のミスを認められないグラマって
必要ないな。
こういう奴がいると絶対にプログラムにバグを入れてくれる。
717:デフォルトの名無しさん
08/10/03 20:28:36
そろそろダンゴさんがピシっと〆めてくれそうだ
718:デフォルトの名無しさん
08/10/03 20:32:18
つかシングルコアでも他デバイスがDMAしてきたらアトミックにならんやろ
メモリにアクセスするプロセッサがひとつだけっていつの話？
719:デフォルトの名無しさん
08/10/03 20:33:29
Java のでも GCC 組み込みのでも、OS ネイティブのでも良いけど、
アトミック命令ってみんな使ってるの?
720:デフォルトの名無しさん
08/10/03 20:53:25
排他やると暗黙的に使われるんじゃね
721:デフォルトの名無しさん
08/10/03 20:56:23
無意味な連番つけるときに AtomicInteger を使ったことはある
722:デフォルトの名無しさん
08/10/03 21:03:47
AtomicReferenceFieldUpdaterは友達
723:デフォルトの名無しさん
08/10/03 21:41:05
レベルの低いスレ/話題は伸びるのが速い。
724:デフォルトの名無しさん
08/10/03 21:49:12
レベルの低い話題に詳しそうだな
725:デフォルトの名無しさん
08/10/03 22:04:26
>>715
> RISCはロード/ストア命令とモディファイ命令を１命令で実行できない
> 物があるのでアトミックではない場合がある
そんなプロセサにメモリに対する inc 命令なんかあるのか？
あるんならそのプロセサの型名書いてくれ。
>>716
「明らかな自分のミス」ってどれのこと？
ちゃんと指摘してくれって書いてあるのに指摘できないの？
>>718
ああ、DMA はあるな。
ただ、通常の DMAC はレジスタで制御するから、メモリ上で排他なんかしないでしょ？
> メモリにアクセスするプロセッサがひとつだけっていつの話？
今でも普通にあるよ。PC しか眼中にないの？
726:デフォルトの名無しさん
08/10/03 22:07:57
また前提が増えたな。
DMA無しだとさ。
727:デフォルトの名無しさん
08/10/03 22:19:48
>>718見て、Windows 98で386のときのInterlockedIncrementは、
デバイスドライバ内で割り込み禁止してincを実行するって話を思い出した。
URLﾘﾝｸ(blogs.msdn.com)
728:デフォルトの名無しさん
08/10/03 22:22:31
>>726
また？
DMA 以外で増えた前提って何のことだ、ちゃんと書いてくれよ。
729:デフォルトの名無しさん
08/10/03 22:37:24
>>725
> そんなプロセサにメモリに対する inc 命令なんかあるのか？
> あるんならそのプロセサの型名書いてくれ。
無いからバグなんだろ。
>714 の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
に対する返信だろう。
730:デフォルトの名無しさん
08/10/03 23:00:16
>>728
きっと>714の「シングルプロセサ/シングルコアなら」のことだろうね
731:デフォルトの名無しさん
08/10/03 23:01:26
>>725
> 今でも普通にあるよ。PC しか眼中にないの？
SPARC/Power/Itaniumサーバも眼中に入ってるよ
732:デフォルトの名無しさん
08/10/03 23:05:07
>>725
> 「明らかな自分のミス」ってどれのこと？
> ちゃんと指摘してくれって書いてあるのに指摘できないの？
>714の
> シングルプロセサ/シングルコアならアトミック操作だから、バグじゃないよ。
のことだろうね
733:デフォルトの名無しさん
08/10/03 23:23:14
Itaniumなんてもうフェードアウトだろｗ
734:デフォルトの名無しさん
08/10/03 23:27:20
>>733
FNHではバリバリですよ
FはSPARCに注力した方がいいと思うけど東証決まってるからなあ
735:デフォルトの名無しさん
08/10/03 23:31:27
なんか、自分のミスはスルー、この反応みると本当に気づいてないようだ。だから自分はノーミスだと思っている。
前提をあとからつけて、人の意見を間違っているという。
まわりが全員レベル低いんじゃなくて、君ひとりがまわりの会話についていけてないんだってば。
736:デフォルトの名無しさん
08/10/03 23:42:48
>>729, >>732
> 無いからバグなんだろ。
「メモリに対する inc 命令持たないプロセサだとメモリのインクリメントは必然的に
複数命令になるからアトミックじゃないだろ？」って言ってるの？
ならすまん、inc 命令の話してる時にその命令持たないプロセサまで考慮して話せと
言う奴がいることまでは想定できなかったよ。
世の中には自力ではメモリのインクリメント自体ができないプロセサもあったりする
からそこから前提におけということかな？ (w
>>730
>>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。
>>731
> SPARC/Power/Itaniumサーバも眼中に入ってるよ
で、それしか知らないと思ってていいのか？
なら、もう少し見聞広めた方がいいんじゃね？ としか言えないけど。
>>735
「ミス」とか「間違っている」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。
737:デフォルトの名無しさん
08/10/03 23:43:57
指摘されてもスルーなのが笑える
738:デフォルトの名無しさん
08/10/03 23:44:39
これはひどい。
いくらなんでも釣りだろ？
739:デフォルトの名無しさん
08/10/03 23:52:04
itaniumはもう終わりだろｗｗｗ
と5年間言われ続けて、無事生存中
740:デフォルトの名無しさん
08/10/03 23:58:00
>>725
incはアトミックじゃない。
でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。
おまえさんはコンパイラがincに落とすのを当然と考えた上でincがバス制御しない事を忘れてる。
741:デフォルトの名無しさん
08/10/04 00:03:13
>>736
> >>703 にわざわざ「シングルコア and シングルプロセサでは」って書いてますが。
その前提を持ち出してるのが大間違いの元なんだよ。
マルチスレッドプログラミング全般としてはそんな前提はないわけ。
君にとってはシングルプロセッサかつシングルコアがデフォで
マルチプロセッサ／マルチコアが特殊なのかもしれないが、
マルチスレッドプログラミング全般としてはシングルプロセッサかつ
シングルコアはマルチプロセッサ／マルチコアの特殊ケースでしかない。
マルチプロセッサ／マルチコアでちゃんと動かないようなのはただのバグ。
742:デフォルトの名無しさん
08/10/04 00:07:03
というか、このスレ全体がひどい。
まず、議論になってない。
そして、議論以前に半分以上の書き込みが用語を並べてみているだけで技術的に意味の通る文章になっていない。
コンピュータ用語に語彙の偏った人口無脳がはき出したような文面の書き込みばかりで流れがない。
今時マルチスレッド、マルチコア、分散処理の区別もつけられない人がこんなにいるなんて信じられない。
日本のプログラマってこんなレベル低いんだ…こりゃ将来が危ぶまれるわ。
743:デフォルトの名無しさん
08/10/04 00:10:15
>>742
だってここ2chだし
744:デフォルトの名無しさん
08/10/04 00:14:50
>>742
たしかに、この発言とかひどいよね
「マルチスレッドが並列に動かなくていいわけないだろ」
745:デフォルトの名無しさん
08/10/04 00:18:26
>>744
どうひどいか語ってもらおうか
746:デフォルトの名無しさん
08/10/04 00:20:49
>>742
「このスレ全体がひどい。」とか「議論になってない。」とか威勢のいいこと書きながら具体的な内容が全く
ないのが、ちょっと笑える。
747:デフォルトの名無しさん
08/10/04 00:21:03
今このPC、 AthlonXP 1500+ で 53プロセス 562スレッド 動いてるぜー
748:デフォルトの名無しさん
08/10/04 00:21:33
>>745
マルチスレッドは並列に動かなくてもいい。
749:デフォルトの名無しさん
08/10/04 00:23:52
マルチスレットは、タイムスライスでもいいから、並列に同時に動く必要はない。
750:デフォルトの名無しさん
08/10/04 00:30:07
GreenThread
751:デフォルトの名無しさん
08/10/04 00:38:13
>>748-749
並列に「動かさなくてもいい」ならそうだが
「動かない」ってのはダメだろ
つか確かに議論になってないな
コンテキスト整理するからちょっと待ってろ
752:742
08/10/04 00:38:53
そもそも「同時に動く」ってのはどういう意味でいってるつもりなんだ?
意味わからん。
たとえば
・レジスタやメモリに結果を書くのを同時といってる?
・実行ユニットで演算されるのを同時といってる?
・前後を入れ替えても意味が変わらない処理を同時だといってる?
もう少し頭の中で整理してかいてよ。
タイムスライスってどういう意味でいってるの?
コンテキスト情報をスワップすることがよくいわれる時分割の本質的な意味でしょ?
コンテキスト情報が複数ハード上にあるのがマルチプロセッサだったりマルチコアだったり
ハードウエアマルチスレッディングがスレッドレベルで並列であることの本質なわけだけど。
CPUが実行ユニットで同時に計算しているとか同時にメモリに結果を書くとか関係ないよね?
このスレで議論している連中は用語をならべているだけで、その中身についてはよくわかってない気がする。
回路設計が本業の漏れからみてもまず基礎がひどいと思いました。
753:デフォルトの名無しさん
08/10/04 00:39:04
>>737
どこがスルー？
具体的に指摘しなよ。
>>740
> incはアトミックじゃない。
DMA の話？ それ以外にシングルコア/シングルプロセサを前提としてあるなら、具体的に
書いてくれ。
> でもそのためにバスアービトレーションを考慮したtest and set系が別にちゃんとあるんだよ。
そう言う命令がないプロセサもあるから、ちゃんと前提つけないとクレームつけられるよ。(w
> おまえさんはコンパイラがincに落とすのを当然と考えた
人の心まで読めるの？ 上級エスパーさんにはかなわないな。
>>741
前提つけたら、そんな前提が間違ってると来たか...。
そこまでしてレスしたいの？
まあ、どっちにしろそう言う文句は >>696 辺りにつけてくれ。
754:デフォルトの名無しさん
08/10/04 00:41:31
>>752
> このスレで議論している連中は用語をならべているだけで、その中身については
> よくわかってない気がする。
自己紹介乙。
755:デフォルトの名無しさん
08/10/04 00:42:44
結局、そこで議論にならなくなってるわけでね。
756:デフォルトの名無しさん
08/10/04 00:47:57
そろそろ753はコテハンつけて欲しい
757:デフォルトの名無しさん
08/10/04 00:50:19
>753は>703なんだよな？
だが>753は>696じゃないのか？
俺流れが見えてねぇw
758:デフォルトの名無しさん
08/10/04 01:04:29
元々このスレはハードウェア主体でマルチコア化が進んでいるせいで、
ソフトウェアを並列化しないといけなくなったのに不満を持った
アンチマルチコア派ｗがたてたスレだからね。本当はソフト屋さんの
ためのスレッドなんだけど、有意義な話がなかなかでない。
回路屋が何かとソフト屋を馬鹿にしているようだけど、せっかく
マルチコアの石があっても、ソフトウェア側の理論がないと意味がなく、
またソフト屋はソフト屋の理屈があるのでそこら辺勘違いしないように
お願いします。
並列化といっても必ずしもバスアービタがどうとかそういう回路よりの
話だけでなく、並列型言語とかプロセス代数とか形式手法とかそういう話を
期待ているんだけど、やっぱり並列化に対するソフトウェア技術者の
意識は弱く、そういう話をができる人はあまりいないみたいだね。
(俺も話ができない一人だが、そういう人の出現を待ってこのスレ読んでます)
759:,,・´∀｀・,,）っ-○◎●
08/10/04 01:12:53
だんごやさんだよ。
色んな意味でマルチスレッドだよ。
760:デフォルトの名無しさん
08/10/04 01:16:34
> 並列型言語とかプロセス代数とか形式手法とか
ここ強調すると住人総入れ替えじゃないか？w
もし次スレ立てるならスレタイに【Π計算】って入れようぜ
761:,,・´∀｀・,,）っ-○◎●
08/10/04 01:20:36
Π革命
762:デフォルトの名無しさん
08/10/04 01:21:23
>>757
> >753は>703なんだよな？
あたり。
> だが>753は>696じゃないのか？
>>696 じゃなくて、>>698
> 俺流れが見えてねぇw
簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
マルチプロセサ」で、状況が違う例としてメモリに対する inc 命令を取り上げ
たら、inc 命令ないプロセサでは状況が違うとか (当たり前だ)、そもそも
「シングルコアでシングルプロセサ」なんて前提がおかしいとか言う奴が出て
きて騒いでるだけ。
# 正直 DMA のこと忘れてたのは事実。
# DMAC とメモリーを排他制御したことないので、すっかり忘れてた。
まあ、流れを追う価値はないから、安心してくれ。(w
763:デフォルトの名無しさん
08/10/04 01:24:51
△ やっぱり並列化に対するソフトウェア技術者の意識は弱く
○ ソフトウェアベンダの合理的経営判断に基づいた技術者・コード屋に対する適切な仕事配分の結果
764:デフォルトの名無しさん
08/10/04 01:28:36
Cilk とか UPC とか?
765:デフォルトの名無しさん
08/10/04 01:33:11
>>762
> 簡単に言うと、「シングルコアでシングルプロセサ」と「マルチコアもしくは
> マルチプロセサ」で、状況が違う例
その状況の違いは本来不要だったんだよ
どっちもマルチスレッドスレの対象になってるんだから
発端は
>>689
> ライブラリの話はマルチスレッドスレがあるからなあ
> このスレいらない子なんじゃ…
>>692
> マルチスレッドとマルチコアでの並列化は違う。
なんだから、マルチスレッドスレでは扱わないがこのスレ(マルチコアスレ)
の対象になる違いが話題になるべきだったんだ
マルチスレッドスレが「シングルコアでシングルプロセサ」の話題限定なら
外れてないがそんなこたーないわけ
766:レトリック君
08/10/04 01:35:48
以前からあった並列計算機以上のことはできない罠
767:デフォルトの名無しさん
08/10/04 01:36:41
>>764
C++なら>688、Javaならjsr166yのfork/joinやParallelArray、C#ならTPLとか？
768:デフォルトの名無しさん
08/10/04 01:41:26
OpenMP, MPI
769:742
08/10/04 01:43:47
>>758
まあ、回路屋といっても計算機のアーキテクチャとかあんまり関係ないんだけど。
それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
このスレを読み返すと前提から大分抜け落ちているように見える。
ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
ことはできない。個人的にはマルチコアは好きではないが、
ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
770:デフォルトの名無しさん
08/10/04 01:49:43
一方グーグルはマルチプロセスを使った（クロームで）
771:デフォルトの名無しさん
08/10/04 01:57:42
> それとは関係なしに、ハードウエア主体で進んでいるマルチコアも、
> シングルコアでは容易に性能があげられないから仕方なしにそういう方向に進んでいるわけで、
仕方ないのはいいけど、マルチコアにした後にどうやって使うか回路屋
まったくノーアイデアでしょ。ソフト屋としてはめちゃくちゃケツ
ふかされている感がたっぷりなんですが...。
> CPUを設計する側が最初からマルチコアをやりたかったわけじゃないということが
> このスレを読み返すと前提から大分抜け落ちているように見える。
こういう風に好意的(というか同情的？)に思うソフト屋は少ないんじゃないの？
だって勝手に回路屋がこれからはマルチコアの時代だよねっ！て勝手に言っているんだもん。
仕方なくやっているんだったら、もうちょっとネガティブな感じでアピールして欲しい。
> ハード系だからいうわけじゃないが、ハードの性能があがらないとソフトで新しい技術を継続して出していく
> ことはできない。個人的にはマルチコアは好きではないが、
> ハードの性能が上がった部分の大半はソフト開発の生産性の向上に消費されてる今の時代にマッチしてないし。
これは結局お互いさまという当たり前の話になるので、まあ言い分としては
理解できます。
772:デフォルトの名無しさん
08/10/04 02:06:23
今までの時代がソフトウェア屋さんに優し過ぎたって事なんじゃないの
773:デフォルトの名無しさん
08/10/04 02:12:01
優しかった時代なんてない
774:デフォルトの名無しさん
08/10/04 02:16:27
布団で寝てても数ヶ月したらクロックが高いプロセッサが出てくるなんて
夢の様な時代だったじゃない。
775:デフォルトの名無しさん
08/10/04 02:17:46
相対的にはこの15年くらいはそれ以前より優しかったと言える
でなけりゃJavaがメインストリームになることはなかったはず
776:デフォルトの名無しさん
08/10/04 02:41:50
>>771
>回路屋
>まったくノーアイデアでしょ。
ノーアイディアっつー事も無いんじゃない?
あまり詳しくないけど、、、
Intel >> TBB
Sun >> JSR166y, Fortress
IBM >> X10
サーバサイドなら仮想化とか Map/Reduce とかもあるし、
マルチプロセッサの歴史が長いから、そもそもスケールする
アプリも多いよ。
777:デフォルトの名無しさん
08/10/04 03:47:55
PCIバスもバスマスタになるからメモリ書き込むよ
778:,,・´∀｀・,,）っ-○◎●
08/10/04 03:57:30
Pentium 4で3GHz到達したくらいまでが天国だったろ？
779:デフォルトの名無しさん
08/10/04 05:11:09
MapReduceはサーバーサイドじゃないけどね。
780:デフォルトの名無しさん
08/10/04 07:42:59
>>765
> その状況の違いは本来不要だったんだよ
え゛っ、今更そんな言い訳ですか...。
だったら、RISC がどうのこうのとか言ってた奴はまんまバカじゃん。
まあ、実際バカだと思うけど。(w
て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
グルコアとの違いを書いただけで、常識的なことだから普通に流され
ると思っていたんだが...。
781:デフォルトの名無しさん
08/10/04 11:49:44
>>780
今更って…>709でも同じように書いてるんだけど
言い訳とか後出し(>711)とか意味わかんないし
話が>689から始まったのを分かってないのか？
> て言うか、マルチコアスレだからこそ、シングルプロセサ and シン
> グルコアとの違いを書いただけで
繰り返しになるが、マルチスレッドスレがシングルコアスレなら
それが違いになるが、そんなこたーないわけ
この話続けてもかみ合いそうもないから俺はもう逃げるよ
782:デフォルトの名無しさん
08/10/04 15:34:42
この板の連中もたいしたことねーな
783:デフォルトの名無しさん
08/10/04 15:39:07
>>779
わざわざ説明しなくても良いと思ったんだけど、必要だった?
784:デフォルトの名無しさん
08/10/04 16:18:04
なんか不思議だよね。CPUのクロックは別にまだ上げられるだろ。
消費電力考えたら、マルチコアにいくのがいいよね～っていうだけで。
で、マルチコアのプログラム支援が言語レベルであれば理想的だが、
なくてもそこそこやれる（やれてる）でしょ？コア数が100とか
1000とかになってくると、言語レベルの支援がないと厳しく
なってくるかもしれんが。
何がいいたいか、自分でもわからｎ
785:デフォルトの名無しさん
08/10/04 16:53:06
あげられないからマルチコアになったんだよ。
786:デフォルトの名無しさん
08/10/04 17:39:15
クロックは上げられるけど、投資対効果が期待出来るスピードで
クロックを上げ続けるのは無理。それより余ったトランジスタで
コアを増やした方が取り敢えず嬉しい。
787:デフォルトの名無しさん
08/10/04 17:49:33
マルチコアの方が使っててスカスカに軽く感じるじゃん？
当面はそれでいいんじゃないかと思う。
で、ユーザーがマルチコアの潜在能力を活かしてプログラム
全体の速度を上げられないかと言い出したらそういうプログラム
を作ればいいが、そうするとシングルコアと同じく多数のプログラム
は同時に動かしにくくなる。
788:デフォルトの名無しさん
08/10/04 18:35:45
どうせみんな8つくらい同時にプログラム動かすよね。
じゃあ、クライアントアプリなら、なんも考えなくてもいいんじゃないか
789:デフォルトの名無しさん
08/10/04 18:42:25
8つくらい立ち上げてても、ほとんどのプログラムは待機状態だと思う
790:>>780
08/10/04 18:46:34
>>781
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>692 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>709 比較なんかしてないぞ
「違う」と書きながら、指摘されたら「比較してない」って言い張るわけですね。
比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。
まあ、「逃げる」とか書いてるぐらいだから、流石にもうでてこないだろう。
普通に考えても、恥ずかしくて出てこれないと思うけど。(w
791:デフォルトの名無しさん
08/10/04 19:18:44
>>790
>692と>709は別人ね。
792:デフォルトの名無しさん
08/10/04 19:54:15
マルチコアに対応と言っても並列化したいのはほんの一部分だし、
スレッドプールとタスクキューを作れば何とかなりそうな気が…
793:デフォルトの名無しさん
08/10/04 20:00:29
つまり「ミニOS」みたいな構造にしてCPUにさせる仕事を細かく分解し
やらせる仕事は片っ端からキューに叩き込んで行き仕事を終えたコア
が次の仕事を取りに来る、とか
794:デフォルトの名無しさん
08/10/04 20:13:07
並列化したい部分なんてのは単純に並列化すればいいだけで何の問題もなく、
特に並列化したいわけでもない普通の部分をいかに並列化してパフォーマンスアップに繋げようかってのが難しいんじゃない？
795:デフォルトの名無しさん
08/10/04 20:40:47
>>790
>>692の中のアンカー読めるか？>>692は>>689へのレスだぞ
そして>>709の名前欄読めるか？>>709は>>689だぞ
>>692と>>689=709は別人、流れはこうだろう
>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ
比較して違うと言ったのは>>692
比較してないと言ったのは>>689
> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。
謎なのはお前の読解力だw
796:デフォルトの名無しさん
08/10/04 20:50:19
長文ウゼ(´Α｀)
797:デフォルトの名無しさん
08/10/04 20:50:26
よくしらんがコンカレントCとかadaとかか？
798:>>780
08/10/04 21:11:32
>>795
まあレス番素直に読めばそうだな。
そうすると、>>708 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w
799:>>780
08/10/04 21:13:34
すまん、レス番間違えた。
そうすると、>>709 は話の流れに関係なく唐突に「比較なんかしてないぞ」と
喚きだすちょっと危ない人になるけど、それでいいんだよね。(w
800:,,・´∀｀・,,）っ-○◎●
08/10/04 21:34:04
>>784
パイプラインを細分化してもレイテンシが大きくなりすぎて効率が上がらないし
配線間隔が狭くなりすぎてリーク電流を抑えるのに神経使う時代が到来した今
シングルコアでクロックをひたすら上げるアプローチなんてどこもやらないよ。
強いて言えばPOWER6くらいか。
5年で5～10倍なんてペースで進化する時代はもう終わった。
コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
一番有効な手段だったりする。
801:デフォルトの名無しさん
08/10/04 21:37:24
>>799
> そうすると、>>709 は話の流れに関係なく唐突に
もう一回書くぞw
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ
AがBに「比較するな」と言い、BがそれはCに言えと言い、
それでCが「比較してない」ってのは「話の流れに関係なく」でも
「唐突に」でもないだろ
>>709=689 (俺は)比較なんかしてないぞ
の方がよかったかもしれんけどな
突っ込むなら比較して違うと書いたくせにCに振ったB(>>708=692)だろ
802:>>780
08/10/04 22:23:09
だったら、おまえら二人で相談でも何でもして解決してくれよ。
俺は、>>692 に「比較するのはおかしい」と指摘しただけで、
お前ら二人が別人かどうかなんてわからんのだし。
803:デフォルトの名無しさん
08/10/04 22:48:07
>>802
> お前ら二人が別人かどうかなんてわからんのだし。
誤読しといて開き直るなよw
804:デフォルトの名無しさん
08/10/05 00:01:55
ここ住人は行った人結構いそうだな
URLﾘﾝｸ(d.hatena.ne.jp)
805:デフォルトの名無しさん
08/10/05 00:59:13
＞一般企業での並列化は遅々として進んでいない。某 Ad○be 社に
＞並列化コンサルティングに行ったところ、「○○処理の部分はプログラマが
＞だいぶ前に死んだのでそれ以降誰も触っていない・触れない」「え、リコンパイル？
＞そんなことしたらもう動かなくなったりしないかなあ」などと言われた。
＞（だからあの会社の製品はあんなに重いのだろうか？）
ワロタと同時にゾッとした
806:デフォルトの名無しさん
08/10/05 01:03:11
シングルコアとクロック数の話で 「周波数と消費電力が2乗の関係」
ということが論じられていない件について
807:デフォルトの名無しさん
08/10/05 01:05:48
ああ、CPUなんて1Hzでいいよ
808:デフォルトの名無しさん
08/10/05 01:07:59
>>806
fは1乗
CMOSデジタル回路の消費電力
P = Na×C×V^2×f + Nt×Il×V
P:消費電力
Na:動作ノード数
Nt:全ノード数
C:ノード容量
V:電源電圧
f:周波数
Il:ノード当たりのリーク電流
809:,,・´∀｀・,,）っ-○◎●
08/10/05 01:33:10
>>806
同じアーキテクチャで同一電圧での話なら2乗だけど
ある程度以上はクロックを上げるのに電圧盛らないといけないので3乗になるんじゃなかったっけ
810:デフォルトの名無しさん
08/10/05 01:57:03
>>806
ここはソフトウェアの板だから、そっち方面の話題の需要は無いと思われ
811:デフォルトの名無しさん
08/10/05 02:22:54
ソフトオンリーの人がハードを含む話をすると悲惨たからな。
>>50->>57あたりにソフトウエアの板のマルチコアCPUに対する理解度があらわれているよ。
812:デフォルトの名無しさん
08/10/05 02:24:48
ソフトウエア板住人の
813:デフォルトの名無しさん
08/10/05 03:28:52
生活に直結していないから不要な知識なんじゃないの。
多分 >>803 みたいな話がむしろ当然な世界でしょ。
食い扶持に影響する様になったらガッと動くけど、
手を抜ける所は手を抜くのも仕事では重要だし、
コア数が一桁のうちは今のままでも困らないかと。
秘伝のソースを書き換えたりアーキテクチャを一から
変更したりするとテストだ互換性だと色々面倒だし。
814:デフォルトの名無しさん
08/10/05 03:30:01
ｽﾏｿ。レス番間違えた。
× >>803
◎ >>805
815:デフォルトの名無しさん
08/10/05 04:24:03
レンダラーとかゲームの思考エンジンとか、並列処理に向いてるソフトウェアでも
売り物じゃないオープンソースのは並列化されていない事が殆どだね。やっぱり
一手間加えるのがマンドクサイのかな。
816:デフォルトの名無しさん
08/10/05 04:44:56
>>800
> コア数分プロセス立ち上げて並列処理するのはダサい利用手段と思うかも知れないが
> 一番有効な手段だったりする。
いやだから、そんなことは当たり前であって。2個とか4個とかなら、その
CPUをフルに活用するようなプログラム作れるかもしれないが。
100個とか1000個とかになったときには言語レベルで支援がないと
きつくなるのじゃないかな？っていう話。まぁ100個とかになる前に、
バスネックになると思うが。
817:デフォルトの名無しさん
08/10/05 05:05:58
100 CPU 越えのマシンは既にあるよ。
1 socket で 64 並列の CPU もあるし。
818:>>780
08/10/05 10:06:49
>>803
おまえらが別人かどうかもわからんのに誤読とか言われても知らんがな。
にちゃん初心者か？
819:デフォルトの名無しさん
08/10/05 11:26:23
>>816
なるほろ
確かに、これから先コア数がガンガン増えていったとして
デクストップアプリケーション、例えばExcelなんかが
その性能に比例して進化していけるのか
今までのアプローチでそれが可能なのか
不安が残るな
820:デフォルトの名無しさん
08/10/05 16:06:29
今のスペックでそこそこ動いているものを挙げたって仕方ないだろ。
コア数が増えるならそれに適応したシステムになるのは当然。
コア数が増えて初めて恩恵を得るようなものを作っていかないといけない。
821:デフォルトの名無しさん
08/10/05 17:31:58
マシンがすでにあることなど関係ない
822:デフォルトの名無しさん
08/10/05 17:33:14
>>811
どうみてもまじめにつっこむとことちゃうだろ
823:デフォルトの名無しさん
08/10/05 18:08:55
>>818
くやしいのうwwwwwくやしいのうwwwwww
「レス番素直に読めば」別人ってわかるだろうがw開き直んなw
もう一回書いてやるよ。こぴぺだけどな
>>692の中のアンカー読めるか？>>692は>>689へのレスだぞ
そして>>709の名前欄読めるか？>>709は>>689だぞ
>>692と>>689=709は別人、流れはこうだろう
>>689 このスレいらない子なんじゃ…
>>692 マルチスレッドとマルチコアでの並列化は違う。
>>698 そもそも、マルチコアとマルチスレッドを比較するなよ。
>>708=692 マルチスレッドとマルチコアの話は、 >>689に言ってくださいな
>>709=689 比較なんかしてないぞ
比較して違うと言ったのは>>692
比較してないと言ったのは>>689
> 比較もしてないのになんで「違う」なんて断言できるのか俺には謎だが。
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
謎なのはお前の読解力だw
824:デフォルトの名無しさん
08/10/05 18:17:26
オマイ等そろそろ他所でやれよな。
2ch だからって何書いても良いという訳じゃないんだぜ。
825:デフォルトの名無しさん
08/10/05 18:50:17
ああそろそろ規制議論板に報告して芋掘りしてもらう頃合いだな
826:>>780
08/10/05 21:00:25
>>823
> 別人ってわかるだろうが
そもそもお前が誰かもわからんのに、何を言ってるんだろうこの人。(w
827:デフォルトの名無しさん
08/10/05 21:47:07
>>826
そうだね、君の読解力じゃ無理だよねw
笑えるよなぁ、コテハン付けて勝利宣言(>790)のつもりが墓穴だもんなwww
そのコテハンそろそろ捨てた方がいいんじゃないの？他の人に迷惑だしさ
普通に考えても、恥ずかしくて出てこれないと思うけど。(w
828:デフォルトの名無しさん
08/10/05 22:09:02
私のために争うのはやめて！
てのはさておき、いい加減にしたらどうなんだ。
元の話でいえば、シングルコアのCPU上のマルチスレッドプログラム
が、マルチコアのCPU上で動作しなくなることなんて、バグじゃなく
ても当然ありうる。タイムスライス限定とかいうなよ？自分の
知ってる範囲だけがマルチスレッドじゃないのだから。
優先度に基づいたマルチスレッドもあるし、そういう環境で無駄な
排他を排除することは当然ありうる。マルチスレッドじゃないが、
割り込み禁止で排他する場合も、マルチコアじゃぁ別のCPUで
割り込みハンドラが動くこともある。
829:デフォルトの名無しさん
08/10/05 22:13:16
最初からシングルコアっていうかその環境専用に作ってるならバグじゃないし
マルチコアは想定外と最初から言ってないなら普通はバグと判断される
それだけのこと
830:デフォルトの名無しさん
08/10/05 22:19:23
>>829
何をいいたいのかわからんが。そのプログラムがどんな
システム向けに作られたかしだいでしょ。最初から
「マルチコアを想定して作ることを求められたプログラム」
ならバグであるし、そうでないならバグではない。
30年前のシングルコアしかなかった時代のプログラム
は全部バグっているというのかい？
831:デフォルトの名無しさん
08/10/05 22:19:45
折角の週末を無駄にして、君たちは一体何と戦っているんだい？
832:デフォルトの名無しさん
08/10/05 22:33:00
>>830
俺は>829に同意。
デフォでマルチプロセッサをサポートしてるのが当然な環境が今は多い。
PCでもWindowsNTWSは最初から2プロセッサをサポートしてたよな。
動作環境にNTが含まれていたら、対象外と明示していない限り、
マルチプロセッサ／マルチコアで動かなければそれはバグ。
前提の環境がマルチプロセッサを含まないことが明白な場合は別。
833:デフォルトの名無しさん
08/10/05 22:39:15
>>832
だから、なんのプログラムに対してバグっているといっているのだ？
仮にあなたが発注元で要求仕様に「マルチコアでも動作すること」
という条件を含めていなかったら、それはバグではなくて仕様。
その変のフリーでころがってるプログラムがマルチコアで動作しな
いとしたら、それは＊あなたが＊バグであるかどうかを判断する
立場にはないよ。作者がマルチコアに対応するつもりでプログラム
作っているなら＊作者＊はバグであるというかもしれないし、
シングルコアのみに対応するつもりなら、＊作者＊は仕様だと
いうだろう。
前提が不明なのだよ。
834:デフォルトの名無しさん
08/10/05 22:52:05
それはない。逆。
このソフトはマルチコア環境では動作しません。
とうたっていない限り、バグ。
835:デフォルトの名無しさん
08/10/05 22:55:17
>>833
仮に動作環境がWindows2000やXPだったら、「マルチコアで動作しない」
と書いてない限り、動かなかったらバグだよ。
OSがサポートしている環境ではマルチコアもその範囲内だから。
それは明白だよ。不明じゃない。
はっきり書いてない場合にマルチコアで動いて当然の環境があるんだよ。
作者がマルチコアを想定してなくて動かなかったなら、コードを直すか
ドキュメントの動作環境を直すかのどちらかは必要だろう。
つまりコードのバグか、ドキュメントのバグかのどちらかになる。
836:デフォルトの名無しさん
08/10/05 22:58:00
極端な話、3GHz以上のCPUでは動きませんと明記していないかぎり、
3.2GHzだろうが5GHzだろうが暗黙の了解でソフトは動いて当然。
動かなかったらバグだろ。それと同じだよ。
837:デフォルトの名無しさん
08/10/06 01:31:30
特殊なソフトじゃない限り、「シングルコアのCPUじゃないと動きません」なんて、許されんな。
838:デフォルトの名無しさん
08/10/06 02:40:38
『動く』と書いてあるのに動かないのはバグ。
書いてなくて動かないなら、動かなくてもおｋ
839:デフォルトの名無しさん
08/10/06 02:51:16
『動かない』と書いてないのに動かないのはバグ。
書いてあって動かないなら、動かなくてもおｋ
840:デフォルトの名無しさん
08/10/06 03:01:12
>>835
Windozeとか、べつにタイムスライスしかないのだから、ドライバで
ないかぎりマルチスレッドプログラムは、普通にマルチコアでも動く
だろ。何をいってるんだ？
841:デフォルトの名無しさん
08/10/06 03:07:14
>>840
上のほう読んでよ。アトミック操作を適切に行っていないプログラムは、
マルチコアで動かないけどシングルコアでマルチスレッドなら動くって眉唾なこと言っている奴がいたんだ。
842:デフォルトの名無しさん
08/10/06 03:56:07
>>838
そう思ってるのは開発側だけだな。
843:デフォルトの名無しさん
08/10/06 04:13:35
そういや昔、マルチスレッドのプログラムがちゃんと動くかどうかテストするのに
マルチプロセッサのPC組み立てたっけ。
90MHzのPentiumでDaytonaだった。
844:は@携帯 ◆cplnFO9T0I
08/10/06 09:53:26
高速なCPUで動かないｿﾌﾄといったらWindows95だろ
たかだかK6-2の350MHzでｺｹるってどんだけだよと
845:デフォルトの名無しさん
08/10/06 10:29:44
コア数が増えてoccam復権しねぇかなぁ
846:デフォルトの名無しさん
08/10/06 11:09:06
>>843
マヌケだなｗ
847:デフォルトの名無しさん
08/10/06 15:08:16
>>840-841
二人とも0点
848:デフォルトの名無しさん
08/10/06 16:37:47
一般的なソフトウェア開発の観点では、プロセッサもしくはランタイム環境の、主にメモリモデルに起因する問題が多い
849:デフォルトの名無しさん
08/10/06 21:15:49
>>864
理解できない時は素直に認めた方がいいぞ。
850:デフォルトの名無しさん
08/10/06 21:22:16
スルーパス出ました
851:>>780
08/10/06 22:02:03
>>827
>>826
852:デフォルトの名無しさん
08/10/19 13:24:40
このスレ絶望的にレベルが低いですね。
853:デフォルトの名無しさん
08/10/19 13:33:32
今日はそうみたいだな。
854:デフォルトの名無しさん
08/10/19 13:36:45
ダンゴさんが最近発言していないからな