アカウント名:
パスワード:
1.ムーアの法則でも20-30年だけど、今騒がなきゃならん程近い将来に1024個入るようになると思う？
2.仮に入ったとしてI/O考えたらマトモに1024個動くと思う？
3.Atom
4.IA64
5.Transmeta
6.Intel
なるでしょ。大昔、富士通が「1シリコンダイ=1CPU」というとんでもないものを作ってきたぐらいだもの。『1つのパッケージの大きさの上限』は、マザーボードの方さえ耐えられれば何ぼでもでかくなるものだよ。
それにだ。1024個のコアを入れるために必要なのは、「4コア」が入る2cm角のチップを4x4で並べて(この段階で2^6)それを16段縦に並べてこれで冷却すればよい。動作速度を100MHz程度にまで落とせば、発熱量は全体で10倍以内に収まる。
例えば64個のメモリと、ばらばらに通信できるシリアル線をプロセッサ側に用意する。16個のコアがL3キャッシュを介して1つのシリアル線に繋がる。他のメモリと通信するときは、他のコアを経由する必要があるので遅くなる、と言うデザインにすれば動くだろ。kernel屋さんは泣きを見るかもしれないが、そのためのマイクロカーネルだ。
従来のx86と市場を衝突させないため、に決まってるじゃないか。
初期顧客がつかなかったから。改善コストが掛けられなかっただけだよ。
128bit VLIW命令セットを公開しなかったからさ。IA32互換能力になんて誰も期待していなかっただけだよ。で、皆が買い控えている間にひっくり返っただけさ。
プロセッサが売れるためには「それだけの仕事」が無くちゃいけない。1スレッドデザインならびにそれを大前提とするアルゴリズムでは、マルチコアは使い切れない。
しかしながら一般的なマルチコアはシングルコアの最大2倍の性能を発揮するのに対し、HyperThreadingはせいぜい1.3倍です。これは一般的なマルチコアがパイプラインそのものを2つ備えるのに対し、HyperThreadingは1つのパイプラインを使いまわすに過ぎないためです。たしかに回路規模あたりの性能はSMTによって改善されますが、パイプラインの数そのものを増やさないと高が知れています。だからこそパイプラインの数（すなわちコアの数）が問題になるのであり、マルチコアとSMTを区別しなければならないゆえんです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
何かメニーコアを理解してない人が多い気がする。 (スコア:2, 興味深い)
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
# まー初期の2コアで「そのまま2つ入れた」ってーのもあったけど。
納得できないなら...いくつか質問するね。
1.ムーアの法則でも20-30年だけど、今騒がなきゃならん程近い将来に1024個入るようになると思う？
2.仮に入ったとしてI/O考えたらマトモに1024個動くと思う？
3.Atomがin-orderなのはなぜ？
4.IA64が期待外れだった理由は？
5.トランスメタがパッとしなかった理由は？
6.インテルがしきりに「メニーコア前提＞ソフト屋」って唱えてる理由は？
このへん考えるとメニーコアはSMTの親玉だとしか思えんのだよ。
俺の答えは、
1.ならない。
2.動かない
3.SMTにおいてというよりメニーコアにおいて、命令を待たせることのペナルティはない。なのでout-of-orderで苦労することに価値はないから。
4.一つのコンテキストにおいて同時実行できる要素はそんなに多くなく、VLIWのスロットが全然埋まらなかったから。
5.4と同じ。4も5もナンバークランチ用途ならそこそこ速かったんじゃなかろうか。GPGPUする方が速そうだけど。
6.4や5の裏返しで、単一コンテキストの性能向上はもう難しいがメニーコア前提なソフトならまだまだ性能を伸ばせるから。
こんなところ。おそらくメニーコア化に伴って投機実行は捨てられるだろうな。投機実行はメニーコア環境にとって有害でしかないから。それと、互換性がなくなるからひょっとすると程度だけど、64bits化でメモリ空間が大きくなったのでプロセスモデルも捨てられるかも知れない。あれも結構パフォーマンスの邪魔なんだ。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:2, 興味深い)
なるでしょ。大昔、富士通が「1シリコンダイ=1CPU」というとんでもないものを作ってきたぐらいだもの。『1つのパッケージの大きさの上限』は、マザーボードの方さえ耐えられれば何ぼでもでかくなるものだよ。
それにだ。1024個のコアを入れるために必要なのは、「4コア」が入る2cm角のチップを4x4で並べて(この段階で2^6)それを16段縦に並べてこれ [cnet.com]で冷却すればよい。動作速度を100MHz程度にまで落とせば、発熱量は全体で10倍以内に収まる。
メモリシステムのデザインしだいだろう、そんなの。
そもそも、メモリとの通信が今のように「パラレル通信」で行われると言う保証はない。メモリの速度をこれ以上あげようとしたらまず持って無理だろう。
例えば64個のメモリと、ばらばらに通信できるシリアル線をプロセッサ側に用意する。16個のコアがL3キャッシュを介して1つのシリアル線に繋がる。他のメモリと通信するときは、他のコアを経由する必要があるので遅くなる、と言うデザインにすれば動くだろ。kernel屋さんは泣きを見るかもしれないが、そのためのマイクロカーネルだ。従来のx86と市場を衝突させないため、に決まってるじゃないか。初期顧客がつかなかったから。改善コストが掛けられなかっただけだよ。128bit VLIW命令セットを公開しなかったからさ。IA32互換能力になんて誰も期待していなかっただけだよ。で、皆が買い控えている間にひっくり返っただけさ。
IA64の二の舞になりたくないからさ。
プロセッサが売れるためには「それだけの仕事」が無くちゃいけない。1スレッドデザインならびにそれを大前提とするアルゴリズムでは、マルチコアは使い切れない。
IA64の場合、可変長VLIWのせいで「一体どこでプログラムが止まったのか、その時実行していた命令はどれか」サッパリ判らなかった。チップデザイン中のバグも多かった。おかげで、バグがハード由来かソフト由来かもよく判らなかった。
ようするに「並列&パイプライン&OoO」を本気でやられた場合に、ソフト的にはハードウェアに何を期待するべきなのか、というコンセンサスが取れなかったし、Intelもまさか…と言うぐらい機能不足だった。
そして、機能不足を補正するだけの予算が無かった。
だから「20年あげるから、研究してちょ」と言ってるんだよ。
.
もう少し、まじめにハードウェアを勉強するべきだと思うぞ。
ちょっと、なめてかかりすぎ。
fjの教祖様
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:2, 興味深い)
作れるかどうかという話じゃないんだがな。
インテルはそんなものを作るだろうかという話だよ。仮に作ったとしても一般に普及させるつもりでなければ、大前提である「メニーコア前提＞ソフト屋」が意味を為さなくなる。その話が本当なら、インテルは「ホールウエハだの、16積層だの、発熱10倍だの」が今それをしつこく言う必要があるくらい近い未来に今それをしつこく言う必要があるくらい普及すると考えてるということになるけど、そう思ってるわけね。
# というか、そもそも「とんでもないもの」なんだよね、それ。
発熱10倍とか、積層とか、100MHz動作とかが何を意味するのかわかってないんじゃない？
ところで、「これで冷却」の「これ」って何？
2.1024個動くか
さっきも云ったように、動けばいいっていう話じゃないんだがな、というかさっきから発生する無駄をことごとく無視してるように思えるんだが。もしそんな無駄を放置しておけるならプロセッサ屋ってずいぶん気楽な商売だねー。
3.Atom
つまり、あれは「メニーコア」には繋がっていない。というわけね？
# あれが一番メニーコアに繋がってると思うけどな。何と云うか観測気球的な面も含めて。
4.IA64
初期顧客がつかなかった理由を考えてみて？
5.Transmeta
それもあるだろうね。でもVLIW自体に問題はない？「期待外れ」は何を期待してたと思う？これは4も同じ。
6.メニーコア前提を唱える理由
マルチコアありきではマルチコアな理由にはならんよ。当然それを唱える理由にもならんよな？
--
日記の方で質問したのにそっちには答えずこっちに答えた理由は何だろう。一週間以内に回答があると嬉しいな。いい回答を期待してるよ。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
SMTベースのメニーコアという話を寡聞にしてはじめて聞いたので、あたかもコンセンサスの取れた定義であるかのような書き方に反応してしまいました。
現在の技術トレンドでは、SMTとマルチコアは厳密に区別されると思うのですが、メニーコアがSMTベースだというソースが何かありますでしょうか？
将来的に両者の中間的なものが出てくる可能性は否定しませんが。
Wikipediaによると [wikipedia.org]、マスマーケットのPCのコア数を越えるものをメニーコアというとか書いてます。この文脈でも、「コア」は独立して動作可能なコアですね。
あなたの言うような意味では、Niagara 3 [srad.jp]で数年後に2048コアが実現しますね。マルチプロセッサではありますが。
> 互換性がなくなるからひょっとすると程度だけど、64bits化でメモリ空間が大きくなったのでプロセスモデルも捨てられるかも知れない。あれも結構パフォーマンスの邪魔なんだ。
これには同意します。.NETのマネージセーフな世界とかではプロセス空間を分割しなくても、AppDomain分割だけでメモリ保護が保障できますし。試みとして.NETでOSの基礎から作ろうとしているようなものもあるそうです。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
ソースと言えるようなのは出せないなぁ...でもそういうのにそんなに遠くない仕事でなんとなく得た知識がベースではある(直接やってるのは違う分野だし推測も少なからず入ってるけど)。でも理由にはさっきの質問だけで十分だと思う。メニーコアは無駄を省いていくとSMTベースになるしかないよ。たとえ一つのチップにプロセッサが1024個入るとしても32768コアをSMTベースで作る方がいいという具合に。
＞「コア」は独立して動作可能なコアですね。
そ、ソフト的に全く独立して見えるというのでも十分コア。インテルのプロセッサだとソフトから見たHTとSMPの違いはそれぞれのコンテキストで独立にプロセスを扱えるかどうかくらいなもんで、よく似てるんだ。
＞Niagara 3で数年後に2048コアが実現しますね。マルチプロセッサではありますが。
同時にハンドルできるプロセスは(16*8=)128だけだから8ソケット全部使って128コアだね。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
> 同時にハンドルできるプロセスは(16*8=)128だけだから8ソケット全部使って128コアだね。
16 コア× 16 スレッド× 8 ソケットって書いてるじゃないですか。16スレッドはどこに行ったんですか？
あなたの主張ではSMPとSMTは同一視できるということなのですが、それを考えなくても、同時にハンドルできるスレッドは2048です。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
あなたのいう「プロセス」とは何のことですか？
スレッドではなくて？
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
# なのでプロセスモデルのシステムでSMTのスレッド使うとプロセスを切り替える時にスレッドも全部切り替える必要がある。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
これは少なくともHyperThreadingに関してはうそですね。
「Magic MP3 Maker GoldでMP3のリッピングを行いながら、同時にXMPEG with DivXで動画のエンコードを行う場合、HTを利用する事で処理時間が22%短縮される」(マイコミ [mycom.co.jp])
あなたの言うようなプロセス排他がかかるとすると、このような複数プロセス同時実行でのパフォーマンス向上は、ありえません。
たしかに、キャッシュの共有などの観点からは同じプロセスのスレッドを実行するのが望ましい場合もありますが、これはそうでなければできないということではないようです。
また、SMTのキャッシュミスを隠蔽するという性質を考えると、メモリの使い方が異なるようなスレッド（プロセスが違っていてもいい）を同時に実行した方がいいという場合もあります。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
＞また、SMTのキャッシュミスを隠蔽するという性質を考えると、メモリの使い方が異なるようなスレッド（プロセスが違っていてもいい）を同時に実行した方がいいという場合もあります。
SMTは同時に十分な数の命令を受け付けていれば命令のストールを隠蔽できるというもので、同時に複数の命令を受け付けていないと全く効果がない。ところが別のプロセスの命令は同時には見えないので同時には取得できない。だからそのパターンでは全く効果がない。カーネルが共有であればカーネルとユーザ空間という組合せも可能だが。
# だから共有部分が少ないマイクロカーネルとSMTはそれほど相性が良くない。
SMTベースのマルチコア(要するにSMTのスレッドにMMUも含めたもの)であればそれができ、同時に実行可能な命令が増える事で単なるSMTよりパイプライン充填率が改善されて回路規模あたりの性能が良くなる。システムがプロセスモデルである限りは。あるいは逆に主要OSがSIPするなりハード側でページ保護機構を持つなりでプロセスモデルを捨てて、全部SMTになるという予想もあり得る。こっちの方が理想的ではあるな。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
その部分は1プロセス時の記述のようですが。
> ところが別のプロセスの命令は同時には見えないので同時には取得できない。だからそのパターンでは全く効果がない。
> SMTベースのマルチコア(要するにSMTのスレッドにMMUも含めたもの)であればそれができ、同時に実行可能な命令が増える事で単なるSMTよりパイプライン充填率が改善されて回路規模あたりの性能が良くなる
仮想メモリの変換を担当するのはMMUの中でもTLBと呼ばれる部分であり、HyperThreadingの場合は仮想プロセッサごとに1つずつ用意されています。(PC Watch [impress.co.jp])
プロセスの切替時にはTLBがクリアされますが(Linuxの場合 [wikiwiki.jp])、TLBが2つあるので2つの仮想プロセッサは別のプロセスのスレッドを実行することができます。
つまり現状のHyperThreadingであってもあなたの言う「SMTベースのマルチコア」の要件を満たしているわけです。
しかしながら一般的なマルチコアはシングルコアの最大2倍の性能を発揮するのに対し、HyperThreadingはせいぜい1.3倍です。
これは一般的なマルチコアがパイプラインそのものを2つ備えるのに対し、HyperThreadingは1つのパイプラインを使いまわすに過ぎないためです。
たしかに回路規模あたりの性能はSMTによって改善されますが、パイプラインの数そのものを増やさないと高が知れています。
だからこそパイプラインの数（すなわちコアの数）が問題になるのであり、マルチコアとSMTを区別しなければならないゆえんです。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
ぺんちに関して言えばパイプラインはもっと多かったハズ。スーパースケーラだし。さらにSMTでパイプライン増やすと複数、でも整数個ではない「コア」の融合になる。なので、そういう構成の場合ハードウェアの数で「コア数」を測るのは無意味なんじゃない？
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
ではパイプラインをやめてIPC（1クロックあたりの実行命令数）にしましょうか。以下、定性的な議論とするので数字はいい加減です。
最近のCPUは1コアあたり最大3IPCの能力があります。しかしながら、1スレッドでは命令間の依存やらメモリアクセスやらでそこまではいかずせいぜい2IPCしか出ません。SMTを入れて2スレッドにすると2.5IPCぐらいはいくかな？もっとスレッドを増やせばどんどん3IPCに近づくでしょう。しかし3を超えることはありません。これは演算器の数に限りがあるからです。
マルチコアでコアを増やすと演算器も含めてほぼ全ての数が増えますので、2コアで最大6IPC、4コアで最大12IPC。SMTなしでそれぞれ実効4IPC,実効8IPC。SMTでスレッドを増やすよりコアを増やした方が性能向上は大きくなります。
。。。というのが今のCPUのコアの数え方です。
将来の話として10IPCの能力のあるでっかいコアを作って、SMTで10スレッドくらいぶち込んで見ましょうというのはありですが、それは将来の話として現在の話とは区別しましょうねという話です。
「コア」という用語を使うなら、デフォルトで「現在存在するものと同タイプのコア」の意味で皆さん解釈されます。
自分の考える将来のコアの姿という意味で使うなら、何らかの前置きや説明を少なくともしてくださいね。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
そもそも「マルチコア前提」はその「将来の話」じゃなかったっけか？
今あるものだけを前提にして考えてたら、将来なんか見えるはずないじゃないか。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
比較するためにも用語を区別することは必要です。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
すでに4コアは実現しているので1024/4=256倍=2^8倍
1.5年で2倍として、1.5*8=12年ではないですか？
Re: (スコア:0)
コア数が増えることの話とそれがひとつのプロセッサに入ることは全く別だけどね。
ソフト開発のレイヤーとハードのレイヤーをごっちゃにしてはいかんな。
後半の話は多数コアの弊害だが、前半の話は全くの勘違い。
Re:何かメニーコアを理解してない人が多い気がする。 (スコア:1)
Atomレベルのコアなら１つのウェハから2500コア取れるそうですが。(PC World [digitalworldonline.com])
もちろんcore 2とかは無理でしょうし、他の問題もあるでしょうけどね。