アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
もともとALUは (スコア:5, 興味深い)
…冷やしたり、あたり玉でなんとかなりそうですな。
(E64T対応になっている時点で64bitは当たり前でしょうし)
niagaraがシンプルなコアなのにクロックがあがらない部分については、やっぱりキャッシュコーヒーレントなのかなぁ。
そんな感じでちょこちょこ気になる部分はありますね。
kusanagi shin
Re:もともとALUは (スコア:4, 興味深い)
だから、32bitの演算では、
・下位16bitの演算(0.5サイクル)
・上位16bitの演算(0.5サイクル)
・フラグのセット(0.5サイクル?)
と完了まで1.5サイクルかかるわけで・・・。
http://www.intel.com/technology/itj/q12001/pdf/art_2.pdf [intel.com] (9ページ目参照)
まあ、下位16bitの演算結果を使って、
後続命令の演算(下位16bit)を開始することにより、
データ依存関係にある命令を0.5サイクル刻みで実行できますけど、
演算器間のラッチを抜けば、フラグのセットまで1サイクルでできそうですし、
その設計の方が性能が上がるプログラムも多そうな気がするのですが・・・。
今回の9GHzのALUはどのような刻みで実行しているのでしょうかね。
16bit演算器x4で実行しているならば、
90nm->65nmのプロセスの微細化だけで十分達成できそうな気がします。
今でも7.6GHz(3.8GHzx2)では動いているのですし。
これが、32bit演算器x2で実行しているならば、
何か新しい設計を導入しているかもしれません。
とりあえず、論文が公開されるのを楽しみにしています。
Re:もともとALUは (スコア:2, 興味深い)
> ・下位16bitの演算(0.5サイクル)
> ・上位16bitの演算(0.5サイクル)
> ・フラグのセット(0.5サイクル?)
上位16bitの演算と同時にフラグの演算は終わってますよ。
んで、後続のJcc・SETcc・MOVccとかに特定bitだけ渡せればそれでいいわけで。
# だから何、って話もありますが。
Re:もともとALUは (スコア:1)
本当に実装してたかどうかちょっと自信なくなってきた。論文は斜め読みした。
Re:もともとALUは (スコア:1, おもしろおかしい)
Re:もともとALUは (スコア:1)
> 全部ROMにしちまえば、もっと早く<ぉぃぉぃ
ROMは資源を浪費するうえに、アクセス速度が遅いのであまり速い演算器にはなりませんよ。
16bit同士の加算でも17ビット×4Gアドレス=68Gビットのメモリが必要です。
掛け算だと結果は32ビットだから128Gビット。
8bit同士なら9ビット×64Kアドレス=576Kビットのメモリでできますが、
そんな演算器をマスクROMとかで用意するぐらいなら、
専用ロジックとして論理圧縮した方が小さくて高速です。
#昔、Z80時代にEPROMで掛け算器を作ったことがあるのでID
Re:もともとALUは (スコア:1)
使うテーブルの値が間違っていたというアレ。SRT Algorithm [intel.com]
Re:もともとALUは (スコア:2, すばらしい洞察)
Re:もともとALUは (スコア:1, 参考になる)
ですね。
パイプラインも 6段しかない [itmedia.co.jp] し、
消費電力を下げることを重視して、もともと高クロックは
狙わない設計なんでしょう。
今でも4.26GHz (スコア:0)
Pentium Extreme Edition 955でも4.26GHzで動かしている
商品があるのでシングルコアならさくっといくでしょう。
まぁ、Prescottでさえ2-3年前のロードマップだと
とっくに5GHzとかで動いていたはずのコアですので‥
http://pc.watch.impress.co.jp/docs/2002/0430/kaigai01.htm
今頃は6-7GHzだったはずですよねぇ(笑)