nob's Weblog
Bigger is better?
ダイ上での集積度と性能についてもう少し
ダイに占めるコアサイズとスレッドごとの相対的な性能値を調べたところ
100%を占有した場合を1とすると、約半分を占有した場合には性能は90%程度になります。そして、ダイ面積の10%を占有した場合でも50%の性能を
発揮できる、という結果になりました。（もちろん、現実にはそれぞれのプロセッサが、いろんな考えに基づいて設計されるので、必ずこうなるというわけでは
ありませんけれど）
つまり、一つのコアで目一杯ダイを使ってしまうのではなく、複数のコアを実装した方が全体の性能を引き出せると言うことになるのです。
Posted at 02:23午後 7 30, 2005 by nob in SPARC | 投稿されたコメント[0]
Niagara on the web
先日、報道関係者向けの技術説明会を行い、その中でNiagaraについて、少々お話をさせてもらいました。
そのときの説明会を元にしていただいた記事がいくつかWeb上で掲載されていますので、お知らせします。
「消費電力あたり処理性能に自信、サンのNiagaraプロセッサ」
ITmedia Enterprise 2005年7月26日
「Niagaraのリリースで効果測定の指標を変えるサン」
ASCII24 2005年7月27日
「サン・マイクロシステムズ、次世代SPARCプロセッサー“Niagara”の技術説明
会を開催——省電力/省スペースの実現と処理性能の向上を両立」
MYCOM PC WEB 2005年7月27日
「最新CMT SPARCプロセッサ「Niagara」は新世代の「エコ・プロセッサ」」
Enterprise Watch 2005年7月27日
「「業界に敵なし」次世代SPARC系CPUの低消費電力をアピールするサン」
でも、まだ詳しいベンチマークの値などを公開できないので、話す方もちと欲求不満でしたが、もうしばらくしたらドーーンとお話しいたしますので、ご期待を。
Posted at 12:22午後 7 27, 2005 by nob in SPARC | 投稿されたコメント[0]
full capacity?
詰め込めばいいのか？
ダイ（シリコンのチップですね）の上にはどのくらいのトランジスタを埋め込めるのか？というのが、動作速度とともに、今までの集積回路の進歩の指標の一つでした。
当然、一つ一つのトランジスタのサイズが小さくなればなるほど、一定の面積に配置できるトランジスタは増えるのですが、その使い道は、問題ではないのでしょうか？
プロセッサの世界で考えると、より賢く処理をさせようと言うことから、
- キャッシュの大型化
- スーパースケーラ化
- Out-of-order 処理の実現
- 周波数の高速化
- より深く、複雑なパイプライン
- 分岐予測に基づくプリフェッチ
Posted at 02:11午後 7 10, 2005 by nob in SPARC | 投稿されたコメント[0]
Memory doesn't catch up
記憶が追いついてこない
コンピュータの高速化の歴史の中でも、おなじみの問題の一つがメモリ・ボトルネックというもの。
非常に大ざっぱに言うと、処理速度にメモリのアクセスが追いつかないという問題です。今回のプロセッサの例でいえば、命令を処理する部分が高速化されても、メモリへのアクセスによって発生する遅延が短くならない。
もちろん、メモリだって進歩はしているんですが、こちらの方はI/Oのプロトコルの問題や、データ幅の問題などもあって高速化は、せいぜい6年で2倍程度になっています。そうすると、2年で2倍ペースで高速化されている処理との差がどんどん開いてしまう訳です。
このギャップをいかに隠してあげるか、というのが腕の見せ所になる訳です。
一般的には、どうしているのか？
メイン・メモリにアクセスすると遅い訳ですから、一つの手として、なるべくメイン・メモリへアクセスをしない、ということが考えられます。これを実現する
ための仕掛けの一つがキャッシュ・メモリの採用です。つまり、速度の遅いメイン・メモリの内容を高速のキャッシュ・メモリにコピーしておくことによって見
掛け上のアクセスを高速化してあげるのです。
この方法が進んでくると、より高速、大量のキャッシュを置くようになり、その結果キャッシュ・メモリも2段3段と階層化され、容量自体も数kバイト程度
だったものが数Mバイトを優に越えるようになってきました。でも、このまま大きくして行っても、どうやら見返りはどんどん目減りをして行くようです。
しかも、今回考えているような、比較的小さくて、しかも寿命の短いデータ、たとえば認証が済めば捨てられるあるいは転送・処理されたらそれでおしまいのヘッダ情報などを大きなキャッシュにため込んでもあまり意味はないのです。
そこで、出て来たのが、ある処理の単位でメモリ待ちになったときに、次の処理に資源を明け渡してしまうという考えです。そうすることによって、パイプライン、レジスタなどの資源を有効活用しながらメモリ待ちの時間を見えなくすることが可能になるのです。
でも、そんな風にして良いアプリケーションは一杯あるのでしょうか？それはまた次回。
Posted at 09:25午前 6 20, 2005 by nob in SPARC | 投稿されたコメント[0]
give simple tasks simple guys
単純なことは単純なやつに
ここで問題にしているのは、比較的単純な処理を数多くこなす必要があるということです。
実は、今までの大概のプロセッサの高速化では比較的複雑というか、パイプラインをいかに動かし続けるか、というような点に力が注がれてきました。つまり、
命令レベルでの並列化という点に力点を置いて、深いパイプラインを形成する傾向にあったのです。（いわゆる科学技術計算の分野での応用です）
つまり、今考えていることとは根本的に矛盾するんですね。
そこで、大きな発想の転換。
このアイデアを初めて聞いたとき、「本当にそんな簡単なことで良いのか？」というのが私の感想でした。そりゃぁそういうタイプの問題もあるだろうけど、それは汎用プロセッサとして成立するのかい？
それに、問題はそれだけじゃないよなぁ……
Posted at 02:15午後 6 19, 2005 by nob in SPARC | 投稿されたコメント[0]
Niagara
Open Solaris もおもしろいのですが、個人的にはやはり Niagara のデビューが近づいていることでわくわくしています。
32bit時代からSPARCと付き合ってきていますが、今回の進化には正直驚かされています。
CMTつまり、Chip MultiThreading というコンセプトを、とてもシンプルなパイプラインを使って実装することによって予想以上の（自分の予想が甘かっただけですが）性能を引き出せる、というのがうれしい喜びです。
今の時点ではあまり詳しい性能値をお話しできないのですが、現在日本語での資料を作成準備中です。
# 早く話したくてしょうがない……
Posted at 01:45午後 6 16, 2005 by nob in SPARC | 投稿されたコメント[0]
Improve processor performance?
プロセッサの性能を上げるということ
大抵の人にとって、いままでプロセッサの性能を上げると言うことは、クロック周波数を上げると言うことと同義でした。また、ある人にとっては、キャッシュの肥大化だったり、場合によってはパイプラインの深さであったりしました。
そのような背景にはいわゆるムーアの法則に裏打ちされる（ある意味強要されている）半導体プロセスの進化があります。
いままでは（Sunを含めて）増加したトランジスタをキャッシュの大型化やより複雑なアルゴリズムを持つパイプライン制御などに使ってきました。でも、残 念ながら使ったトランジスタ数ほど処理速度は上がらないんですね。（もちろん、それなりに向上しますが、努力には見合っていないと言わざるを得ません）
しかも、処理すべきものはどんどん増えてきています。たとえば、身の回りにたくさんの認証を必要とするものがありませんか？キャッシュカードやクレジット カードなどは以前からたくさんありますが、それ以外にもコンビニなどで使える非接触型のカード、電車に乗るときに使うカード、社員証や学生証にもICカー ドの機能が入っていることもありますね。そのような個人が持つものに加えて、スーパーなどに行くとそれぞれの商品に無線タグがついていることも増えてきま した。有料道路などでETCを使っている方もいらっしゃるでしょう。
このようなデバイスは、今非常な勢いで増えています。そして、これからも当分の間は爆発的な勢いで増えて行くはずです。
さて、このようなデバイスからのデータは誰が処理するのでしょうか？そのデータの処理量は2年で2倍どころではないはずです。では、コンピュータの数を爆 発的に増やす？まぁ、私たちのボーナスが増えそうでうれしいですが、残念ながらそうはいかないですね。となると、コンピュータ当たりの処理量を増やす必要 があります。さて、どうすればいいのでしょうか？
Posted at 09:09午前 6 16, 2005 by nob in SPARC | 投稿されたコメント[0]