Sun、UltraSPARCのスループットを3年後には30倍に 35
ストーリー by Oliver
バスというボトルネック 部門より
バスというボトルネック 部門より
dseg 曰く、 "Sunは2月25日、同社のUltraSPARCの今後のロードマップを発表した。
マルチスレッド化アーキテクチャの採用によりアプリケーションのスループットを2005年に15倍、2006年には30倍向上させるとしている。ムーアの法則越えの大胆な数字だが、ポイントはCPUの能力そのものではなくUltraSPARC上で動作するアプリの"スループットを"向上させる、という表現だろうか。何度もデータシートを読み返してみたものの、ハードウェアに不得手なタレコミ子には明確に把握できませんでした。"
本心では (スコア:2, すばらしい洞察)
Re:本心では (スコア:0)
スループット・コンピューティング (スコア:2, 参考になる)
すっごくシンプルに言うと、インテルのハイパースレッディングを2重より増やして（4重くらい？）、メモリのレイテンシを埋めるに充分なスレッドを1プロセッサ・コア上でコンカレントに実行する。
それに加えて、1チップ上にコアを複数集積して、スレッドを並列に実行する。
...メモリのレイテンシを隠すのがキモって感じですかね。
最近のネットワークアプリケーションは元々がスレッド並列なんだから、プロセッサもそれに合わせればええやん、と。
そういえば、スレッドをいっぱい作るようなプログラミングモデルって、つい最近どこかで聞いたような気がするなぁ。
=^..^=
Enjoy Computing, Skiing, as much as Horse Racing.
Re:スループット・コンピューティング (スコア:3, すばらしい洞察)
こちらの文書 [sun.co.jp]などを読むと、キャッシュラインの状態にもかなり気をつかっているようではありますから問題ないのかな。
/*
インテルはスーパースケーラ的なアイディアを押し進めて「自動スレッド生成」なんつーウルトラ C で行くようですが…。これはイマイチ理解出来ないんだよなー。必要なメモリをプリフェッチするには (アドレスを知るために) ロジックを実行する必要があり、だったらその先行スレッドを本スレッドとしてしまえばより早く処理出来るような気がしてしまふ。何か勘違いしてる？
*/
Only Jav^Hpanese available :-)
Re:スループット・コンピューティング (スコア:2, 参考になる)
そそ、そのとおり。メモリのクロックが遅いということはリード制御自体も遅いということで、効果的にノンブロッキングアクセスができるのかとても疑問。まぁメモリバスの数を増やすという力技もあることはあるが。
> だったらその先行スレッドを本スレッドとしてしまえば
そんなに詳しくないですが、本スレッドにおけるデータアクセスや命令をかなり先までプリフェッチして、使用するしないに関わらず、正確なアドレスかどうかにも関わらず構わず投機的に実行してしまうという感じでしょうね。
サブスレッドで正確に実行はせずに大まかに実行して必要なデータや命令をさっさとL1に入れておいて、本スレッドで正確に実行すると。
わかりやすいのは分岐命令です。分岐でスレッドを2つにして、双方の命令をプリフェッチ、ついでに2つのスレッドに存在するデータアクセス命令も実行するわけです。んで、本スレッドで正確に実行すると。
Re: オフトピ: 日本語訳 のリンク (スコア:1)
日本語訳、私がチェックした時は無かったんですが...。サブミット寸前にもチェックする様今後気を付けます。
詳細が掴めない (スコア:1)
日本語訳を読むと、 1つのプロセッサで1度に数十を実行できるというのが 文字通りの意味だとしたら、 既存のものとは異なる革新的な技術だと思われます。
まあ、 データシート [sun.com]の図を見ても、 1 つの CMT プロセッサが 4 つのスレッドしか実行していないようなので、ただの SMT(Simultaneous Multi-Threading) だと思うのですけどね。
p.s.
SUN は自社の CPU 設計能力に見切りをつけて、 富士通の SPARC64 V を買って使えばよかったのにね。
SPARC64 V には out-of-order excecution もあるしさ。
コンタミは発見の母
Re: 詳細が掴めない (スコア:1)
Microprocessor Information の記事 [geocities.co.jp]によると、 Ultra Sparc 2 のコアを 4 スレッド並列可能にし、それを 1 つのチップ上に 8 つ実装する計画のようです。 また、マルチコアと SMT を一括りにして、 CMT と呼んでいるようです。
このような実装では、一つのスレッドあたりの処理能力は低下しますが、高い並列度でトータルの性能を稼ぐのでしょう。スループットの向上という表現は、ここから来ていると思われます。
Throughput computing をうたう以上は (スコア:1)
これが本当だとすると、CMT は技術用語と言うよりは
マーケティング用語なのですね...
SUN が今回の発表した throughput computing が、少なくとも今回
発表した範囲では SMT×CMP 以上のことを言っていないというのは
分かるのですが、心のどこかにはまだ隠し玉がありそうな気がして
深読みをするのです。
なぜなら、昨今のプロセッサアーキテクチャはすでに単なる SMT や CMP よりもアグレッシブな形でマルチスレッド対応を行ったり、行おうとしていたりします。
例えば speculative threading による逐次プログラムを高速化や、スレッド生成や同期処理を hardware-support による高速化です。
現に Intel の Prescott は、スレッド間の同期ロック処理を hardware-supportする MONITOR/MWAIT 命令などを追加してきました(詳しくはここ [intel.com])。
それを考えると "Throughput computing" なんて大仰のキーワードを述べられるて、その正体が単なる SMT×CMP なら、そんなの他所でもやているよ、と言いたくなるのですが、、、
コンタミは発見の母
Re:詳細が掴めない (スコア:1)
UltraSPARCが out-of-order じゃないのは、そういう方針なのでしょうか？ それとも作れないのでしょうか？
out-of-order も作れないところが、「一度に数十のスレッドを実行することができ」るとは思えないんですけど。
> SUN は自社の CPU 設計能力に見切りをつけて、富士通の SPARC64 V を買って使えばよかったのにね。
US-IIIの出荷が遅れに遅れたときにもそんな意見がありましたね。(ZDNetだったかな？)
でも、本家のプライドが許さないだろうな。
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
UltraSPARC と SPARC64 (スコア:3, 参考になる)
> UltraSPARCが out-of-order じゃないのは、そういう方針なのでしょうか？ それとも
> 作れないのでしょうか？
> out-of-order も作れないところが、「一度に数十のスレッドを実行することができ」
> るとは思えないんですけど。
まずは解説。
SPARC は他の RISC 系の石(MIPS/PA-RISC/Alpha/POWER) と事情が少し違います。ぐるぐる回る register window があるからです。
register window は、中華テーブルのように物理レジスタが(イメージ的に)環になっていて、これを特定命令によってシフトする機構です。プログラムから見ると手前の24本だけが論理レジスタとしてアクセス可能です。
かつてはこの機構は非常に重宝したのですが、スーパースカラーが主流の時代になると、CPU の設計を困難にする鬼っことなりました。無論、register-window と out-of-order execution を併用することは可能です。ただ SUN としては out-of-order execution を捨てて、クロック周波数を上げる道を選んだと聞いています。
しかし現在 Ultra SPARC III は (out-of-order execution を実装した) SPARC64 V に、IPC でもクロック周波数でも負けています。
話を戻して、SPARC 命令セットで CMT、特に SMT の部分を実装できるか？という問題ですが、ご指摘の通り SMT を実装する場合も register window はネックとなります。
register window + out-of-order execution と、register window + SMT のどちらが難しいかは私にはわかりません。
無論、がんばれば実現可能です。
> > SUN は自社の CPU 設計能力に見切りをつけて、富士通の SPARC64 V を買って使えばよかったのにね。
> US-IIIの出荷が遅れに遅れたときにもそんな意見がありましたね。(ZDNetだったかな？)
> でも、本家のプライドが許さないだろうな。
以下は伝聞の話です。
最初の予定では HAL 研の SPARC64 は SPARC9 系の最初の石として、今の UltraSPARC よりも前に出てくる予定でした。SUN は SPARC64 を採用してそれに UltraSPARC という名前を付けて売る予定だったと聞きます。
HAL 研の開発が難航して、御覧の通りの採用状況です。
＃ そして、今では HAL 研もなくなってしまいましたとさ。
コンタミは発見の母
Re:UltraSPARC と SPARC64 (スコア:1)
> register window はネックとなります。
これに関して、チップ内にマルチスレッド用のコンテキストメモリを持つんではないかという推測 [geocities.co.jp]をしている人がいます。どうなんでしょうね。
> 以下は伝聞の話です。
> 最初の予定では HAL 研の SPARC64 は SPARC9 系の最初の石として、今の UltraSPARC よりも前に出てくる予定でした。SUN は
> SPARC64 を採用してそれに UltraSPARC という名前を付けて売る予定だったと聞きます。
初代USにHAL設計の石を使うつもりがあったという話ははじめて聞きました。驚きました。
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:詳細が掴めない (スコア:0)
Re:詳細が掴めない (スコア:0)
他にそういう製品出てないよね？論文では読んだことあるけど。
またムーアの経験則ですか・・・。 (スコア:2, すばらしい洞察)
技術の推移を眺めた(単なるトレンドの推移の)予測を技術の話に絡めても
意味なんてまったくないんだからさ。
＃そもそも半導体製品なんて、CPUみたいに、システムの性能を
＃内部演算の処理性能で一意に測れるものばかりではないんだし。
それに、この場合、性能に絡めて考えるのって意味ないんじゃないの？
すでにもう、集積度を向上すれば性能が必ず上がるってわけじゃないから。
＃そもそも元々は集積度の向上にしか触れてない気がするのだけど、
＃いつのまにこんな経験則が性能指標になったの？
---- redbrick
本当に技術屋が書いた or チェックした文章？ (スコア:2, すばらしい洞察)
今回 発表された資料を読む限りではプロセッサアーキテクチャの設計に関わった技術屋が書いたものではないように読める。
なんか技術の肝になる部分がちっとも伝わってこない。
なにかマーケティング担当者が、きちんと打ち合わせせずに、急いで書いたという印象を受けるのだが、、、
なんかそこら辺にある資料を漁って書いたような...
コンタミは発見の母
Re:本当に技術屋が書いた or チェックした文章？ (スコア:1)
>設計に関わった技術屋が書いたものではないように読める。
>なんか技術の肝になる部分がちっとも伝わってこない。
プレスリリース読んでみましたが、同感です。
構想レベル、会社の開発方針とかのレベルの話だし、技術的詳細は
確かに必要ないとは思うのだけど、基盤としたい部分が何にも見えて
こない、もしくはけっこう使い古された概念しか書いてないので、
なんだかなぁ、って感じに見えますね。
＃メモリアクセスに時間かかるのは、ある意味、今の半導体製品に
＃かかわってる人のほとんどは知ってることだし、いまさら
＃着目したという風なことを大々的に言い出すのは、なんか滑稽(汗)。
＃あと、CPUコアを多数実装しても、I/Oまわりを共通で持ったら
＃IntelのHTと同じ欠点を抱えるだけだと思うのだけど。
＃かといって、全てのコアのデータバスやアドレス線を独自に引き出すには、
＃現在のパッケージってコスト面で限界がある、というか、昔だって
＃コスト度外視ならいくらでも出来た話だし・・・。
＃おまけにそういう対策しても、基板側の配線引き回しで地獄を
＃見ることになるし(汗)。
＃ホントに、今更なにをやりたいのが見えないんだよなぁ・・(汗)。
＃それとも、多数のコアの実装と駆動方法と、システムの組み方に関して、
＃今まで以上の性能を出せるような新規の手法でも編み出したんだろうか？
＃・・・・それとも、同期設計で無理矢理4つのCPUコアを
＃タイミングずらして動かすだけの力技？？
＃CPUコアを4つ載せて、一つ当たり25%程度しかない演算処理時間を
＃4回続けて実行するから演算処理時間が100%になるってこと？
＃・・・chip作ってる立場からすると、CPUのテストに4倍の時間が
＃かかる気がするんで、逆に高コストになると思うんだけどなぁ(汗)。
まぁ、出来てもいない事、実現しようとしている事は、普通は
完全に出来て特許とかとってから詳細を出すものですからね。
その辺りは仕方ないと思うが・・・プレスリリースとか見ると、
ムーアの経験則が、なんでかCPUとメモリーの性能の増加率予測、
しかもそれぞれ2年ごとに倍、6年ごとに倍になる、ってことに
なってる・・・(汗)。
＃Sunの広報関係者って、こんなに馬鹿だったっけか？？
まぁ、Intelとは全く関係なくアーキテクチャの変更や改良が行える
数少ない会社ですからね。
色々と挑戦してくれるのはありがたいことではあります。
＃SunのWSは仕事でもかなり使ってるし。
＃ま、もっとも、最近はLinuxって話もちらほら聞こえてるけどなぁ ・・・。
---- redbrick
Re:本当に技術屋が書いた or チェックした文章？ (スコア:1)
1:1 モデルのスレッドサポートを前提に、 オンチップマルチコアなプロセッサを投入し、プロセス技術向上によるクロック向上と物理多重によるスループット向上の相乗効果でムーアの法則(技術のトレンド係数)を超えるトータル性能を実現しよう、 という目標でしょう。 これまでの SUN の実績や持っている技術を考えると容易ではないけど風呂敷を広げたようには思えないです。
「スループット コンピューティング」って名称も考えると狙いどころは、高度に多重化されたプログラムの大幅な高速化でしょう。従来のプログラムをそのまま速く実行する、と言うアプローチのからの脱却しアーキテクチャの適化を考えていると思えば結構合点いきます。
まあ、15倍とか30倍性能向上と言ってもツボにはまった場合のことで、ワーストケースがムーアの法則になるんでしょうけど。
の
Re:本当に技術屋が書いた or チェックした文章？ (スコア:1)
話を出してくるのは間違ってるっていってるんですけど(汗)。
なんなんですか、その「技術のトレンド係数」って？？
＃少なくとも、アプリケーションの性能や実行効率に言及する際に、
＃半導体のシリコン側、物理的なchipの製造時の集積度の推移の傾向の予測を
＃引き合いに出して、何を説明したいの？
＃SUNがやりたいのは、シリコン(chip)の性能を上げることを含めるけど、
＃結局はそれに縛られにくいソフト側、回路実装側の性能を上げる
＃(ちなみに、回路の構成とchipの集積度は、大枠では関連はあるけど別々の要素)
＃って事なのに、なんでそんな部分で、いくら同じ業界の大先輩とはいえ、
＃chipのプロセスの技術が市場や世情によってこう推移するだろうという
＃個人的経験からくる予測を引き合いに出すことで、なにかを説明できる気に
＃なるわけですか？
＃実際に作ってる側からしてみれば、技術そのものに全く触れていないので
＃それは、なんにも説明してないのと同じです。
つーか、あんなもの、誤解する連中が増えるばかりなんで、
「法則」なんて呼んで欲しくないです(汗)。
＃法則だって言うなら、その中に述べられている技術的根拠、実際に
＃そうなっているってだけでなくて、その根本原因や理屈を説明してくださいよ(泣)。
＃少なくとも、この「法則」とやらに関連して、わたしは理屈や理由の
＃詳しい説明は聞いたことないのですが、あなたは、物理法則のような、
＃市場の推移なんていう時流に即しても人為的にでも変えられるし、どう変わるかも
＃その時代時代で変わっていくような状況に関わらない、しっかりした根拠を
＃知ってらっしゃいますか？？
>プロセス技術向上によるクロック向上と物理多重によるスループット向上の
>相乗効果でムーアの法則(技術のトレンド係数)を超えるトータル性能を実現しよう
ムーアの経験則は集積度に関する予測なので、トータル性能に関して
適用するのは明らかに間違いだと思います。
＃以前の、あまり複雑な影響が見えなかった時代のCMOS回路だけの
＃単純な回路では、スイッチング速度が即、演算性能と読み替えられましたから、
＃そんな無茶な適用も出来ましたけど、今はもう無理ですよ。
＃DDRのようなデータアクセスタイミング変更によるメモリーの駆動効率アップが
＃ムーアの経験則で説明できますか？
＃ちなみに、あれは回路側での工夫で性能を上げているわけで、メモリーchip
＃単体の性能が劇的に上がったから実現できたものではないですよね。
>15倍とか30倍性能向上と言ってもツボにはまった場合のことで、
>ワーストケースがムーアの法則になるんでしょうけど。
ムーアの経験則は、性能の指標じゃないので、この用法も間違ってると思います。
＃トレンドなんて、流行の推移に関わる事を具体的な製品の一例に還元して
＃適用することができるなんてのは、おかしいとは思いませんか？
＃抽象化のレベルが高い概念に関連する事柄を低いレベルにまで全部適用できる
＃わけではないでしょ？
＃・・・例えば、最近殺人を犯す人間が増えたからって、即、近隣にいる不審者が
＃殺人者だ、とは言えないように。
＃それとも、あなたはこのような曲解や誤解をなさる方なんでしょうか(汗)？
>従来のプログラムをそのまま速く実行する、と言うアプローチのからの
>脱却しアーキテクチャの適化を考えていると思えば結構合点いきます。
アーキテクチャの最適化、chip側の動作効率アップ、というのは同意見で、
方策の具体的内容はともかく、それを否定するものではないですが・・・、
従来のアプリケーションプログラムとの互換性は、プレスリリースを見る
限りでは、SUN自身は捨てるつもりはないようですよ。
＃まぁ、OS側の対処で、できる限り吸収するのでしょうけど。
＃ちなみに、こんな最適化もムーアの経験則の適用範囲外
＃(だって、実装する回路の改良やOS、アプリケーションの改良だから)
＃なので、それに絡めて言及するってのは、間違いだとわかりませんか(汗)？
>これまでの SUN の実績や持っている技術を考えると容易ではないけど
>風呂敷を広げたようには思えないです。
わたしが知る限り、SUNの持ってるCPUや回路のアーキテクチャ、論理設計の技術は
確かに高いですが、製造側で解決しなければならない課題に関しては、
あまり高くはないです。
パッケージ側、chip製造側なんかは、はっきり言って製造メーカーに
ほと
---- redbrick
Re:本当に技術屋が書いた or チェックした文章？ (スコア:2, 興味深い)
まあ、社会学的な法則ですから、裏付や理論背景はないのは当り前ですが、ビジネス競争の指標として採用される(これ自体が目標になる)ため、現実が法則に近付いてしまうような性質のものでしょう(これはこれで面白い現象と思う)。
今回の発表は、Sun はこのトレンドを超えていくぞー、という市場に向けた決意表明でしょうから、技術詳細が無いのは仕方ないところでしょう。ただ、以前の発表をまとめてみるとそれなりにどこをどうするつもりか想像はできるかなぁと。
ところで、今回の発表を、単純に15～30倍を達成する、と解釈するのは行き過ぎでしょう。「スループット」と言ってるとこがミソと思うけど、物理的な性能向上で 4倍(これは従来トレンド)、多重度で 4倍(現在でも SMP がある) を達成すれば全体で16倍になりますから、方向を定めて資本投下すれば実現できると思います。ただ、目標を達成したとしても、その間他のメーカも進歩するので発表時の印象ほど速く感じられない、と予想しますが。(ってか、IBM とか既にインコアのマルチプロセッサ作ってるし)
の
Re:本当に技術屋が書いた or チェックした文章？ (スコア:0)
一言二言ならともかくだらだらと長文かかれても読みづらいだけ。表に書くなら読みやすく纏めてくれ。
大体、ムーアの法則はムーア自身、 っていってるじゃん。
Re:本当に技術屋が書いた or チェックした文章？ (スコア:0)
一言二言ならともかくだらだらと長文かかれても読みづらいだけ。表に書くなら読みやすく纏めてくれ。
大体、ムーアの法則はムーア自身、
「集積度があがるといっただけで演算性能のことは言った覚えもないし、明確な年数を提示した覚えもない」
っていってるじゃん。
Re:本当に技術屋が書いた or チェックした文章？ (スコア:1)
次に長くなりそうなときは、も少し考えます(汗)。
>一言二言ならともかくだらだらと長文かかれても読みづらいだけ。
>表に書くなら読みやすく纏めてくれ。
・・・確かに(汗)。反省してます(汗)。
---- redbrick
Re:本当に技術屋が書いた or チェックした文章？ (スコア:0)
> つーか、あんなもの、誤解する連中が増えるばかりなんで、
> 「法則」なんて呼んで欲しくないです(汗)。
個人的には「マーフィの法則」と同レベルだと思っとります。はい。
＊＊＊
新しい SPARC については、「非同期」なんてキーワードがちらほら書かれていたりもする点にピクピク反応してます。誇大妄想？
追記 (スコア:2, 参考になる)
SDRAMスループットの最適化 (スコア:2, 興味深い)
のような原因なのかなあ。メモリにも技術革新を。
種別 MHz-bits 実効[GB/s] 効率
DDR266 266-128 2.40 0.56
PC1066 1066-32 2.08 0.49
PC800 800-32 1.60 0.50
DDR266 266-64 1.60 0.75
DDR200 200-128 1.60 0.50
SDR133 133-64 0.98 0.92
アクセスレイテンシ (スコア:0)
Solaris9 (スコア:1)
IBM/Toshiba/SCEI の Cell やこの新しい SPARC など、これまでとは一味違う石がどんどん出てきてバリバリ競争してほしいですね！アーキテクチャは IA32、ARM で決まり、なんて世界はツマンナイですもんね。
Only Jav^Hpanese available :-)
Re:Solaris9 (スコア:2, 参考になる)
MxNを止めたのは、理想と現実の乖離が大きくて、実際のパフォーマンスが上がらなかったからではないかと。
Re:Solaris9 (スコア:1)
最近やったIA32じゃ無いのは PA-RISC だったなぁ。しばらく前だけど……
＃Cとかのコンパイラ使うから、アーキティクチャの差違なんてあんまり関係ないんだけどね。
Re:Solaris9 (スコア:1)
この OS から MxN スレッドモデルが引退したのも、こういったハードウェアレベルでの並列化を押し進めるための布石だったのかな？
この事実を初めて知りました(^^; この辺のスレッドモデルについての議論、Linux界隈でも一時期ホットだったと記憶してますが、そぉかぁ、Solaris止めちゃったのかMxN...
trueOne
Re:Solaris9 (スコア:0)
ユーザレベルのスケジューラがボトルネックになってたようですね。
個人的にはFreeBSDやNetBSDがそのへんをどうやるのかが見物です。
Re:Solaris9 (スコア:0)
そんなあなたにはゲーム業界。
SPARCこそありませんが、IA32とARM以外にもMIPS、PowerPC、なんでしたらSHも取り揃えてございます。
マシンアーキテクチャも個性的で楽しいですよ、ええ。
# プラットフォームジプシーなのでAC
Re:Solaris9 (スコア:0)
SH頑張れ！！
2005年には15倍 (スコア:0)