アカウント名:
パスワード:
3. 現行のTr密度なら安定して量産できるが、4GHzというcoreで9割程度の確率で達成できるMIPSに追いつくためにはcacheを増やさなければならない。cache sizeは大抵Tr密度にboundするが、現行の技術ではTr密度が増やせないので商品としては意味がない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
4G over... (スコア:2, 参考になる)
2.8G@4GはOC率にして42%程度なのでいわゆる"OC向け"CPUなら普通に出せなくはないと思いますけど……何より凄いのは2.4G@4.1Gに成功している人たち。OC率70%over(笑
Re:4G over... (スコア:2, 興味深い)
1.実は製造過程では4Gクラスは作れるけど、安定した量産がまだできない。
2.実は安定して量産できるけど、価格の暴落を恐れて、あえて4Gクラスとして出荷したくない。
だったりするのかぁ…と、考えてしまったりする。
蛇足だが、15年ほど昔、某#製セカンドソースのZ80Bではち
/* Kachou Utumi
I'm Not Rich... */
Re:4G over... (スコア:1)
3. 現行のTr密度なら安定して量産できるが、4GHzというcoreで9割程度の確率で達成できるMIPSに追いつくためにはcacheを増やさなければならない。cache sizeは大抵Tr密度にboundするが、現行の技術ではTr密度が増やせないので商品としては意味がない。
Re:4G over... (スコア:2, 参考になる)
「3. 現行のTr密度なら安定して量産できるが、4GHz 版を出してもキャッシュやメモリシステムが同じならクロック当たりの平均命令実行数(Instruction Per Cycle; IPC)は
落ちるので、全体として有意な性能向上に結び付かない。
この場合、プロセッサアーキテクチャを大きく変えずに IPC を回復するにはキャッシュサイズを大きくすることが有効だが、『cache sizeは大抵Tr密度にboundするので、現行の技術ではTr密度が増やせないので』商品としては意味がない。」
ということが言いたいのだと思うのですが、違いますか?
ゲスな勘ぐりかもしれませんが
Intel は高クロックが安定して実現できるのなら、クロック数の増加に比した性能向上がなくても製品を投入してくるのではないか思われます。
あと 技術的な点ですが、キャッシュサイズが Tr密度によって究極的な制限を受けるのは本当ですが、それ以上にプロセッサのアーキテクチャによって決めたファクターの方が大きいと思われます。親コメントの鍵括弧部分は大雑把すぎると思うのですが...。
i486 時代には「プロセスルールがシュリンクしたので、ダイ上にクロックダブラーやキャッシュを載せる余裕ができたのですよ」みたいな話がありました。こういう時代なら、ダイ上の空いている部分を全部キャッシュに投入していたかもしれません。
でも、現在のプロセッサはもっと微妙なバランスの上に設計されていますよね。
キャッシュサイズを大きくするとレイテンシも大きくなるので、無闇に増やせない。。
実際、今回のターゲットとなった P4は、L2 キャッシュこそ 512K バイトですが、L1データキャッシュはたった 8K バイトしかない。P3 と比べても少ないです。
このサイズの減少は P4 を設計者がバランスを取りながら選択したものでしょう。
# P4 には L2 キャッシュサイズが異なるタイプが存在するので、L2 の容量の変更は
# 可能かもしれません。しかし、512K バイトのキャッシュはデスクトップ向けアプリケ
# ーションでは割と多いほうだと思われますので、ここから増やして IPC の向上に結
# びつくかどうかは謎です。
コンタミは発見の母