2007年09月21日
Update!!(9/21 19:00) Nehalemについて 
Nehalemについての話です
・IntelがNehalemの概要を発表、実働デモも公開 by PC Watch
・Nehalem uses the same 775 socket by Fudzilla
・Intel won't support AMD's SSE5 by INQ
今回のIDFでは残念ながらNehalemのアーキテクチャやキャッシュ構造について明らかにされなかったそうです
PC WatchにはNehalemの様々な構成例が挙げられていますのでご覧になってください
メモリについては前回の記事の内容の通りとなりますが、GelsingerさんはデュアルチャンネルDDR2に比べて帯域が3倍となると言っていたそうで、DDR3-1600もサポートされる可能性が高いとのこと
さらにBoBなしでも拡張規格のDDR3-2133もサポートすることを検討しているそうです
DDR3-1600でも厳しそうですので、これはなかなか難しそうですね
NehalemのCPUコアはCoreMAと同じく4命令発行/サイクルとなるそうですが、CoreMAの拡張ではなく完全新設計だとのこと
SMTについては4〜5%のサイズ増加で、0〜30、40％程度のパフォーマンスアップが見込めるといっています
それからCoreMAは64bitに弱かったのですが、Nehalemは最初から64bitを考慮しているとのこと
勿論32bitもサポートされますが、64bitでパフォーマンスが低下することは無くなりそうですね
その他SSE4.2として7命令などさまざまな命令がサポートされるそうです
SSE5についてはINQによるとサポートされないようです
SSE5はAMDに頑張ってもらいたいところですね
Nehalemのクアッドコアのダイサイズはウエハから計算すると約270平方mmとなるそうです
Nehalemと同じ45nmプロセスであるPenrynのクアッドコア(L2 6MB)はデュアルコアで107平方mm、MCMでクアッドコアとすると214平方mmでありまから、ダイサイズは大きいですね
メモコン内蔵やQPIなどでトランジスタを食われるので妥当なところでしょうかね
ちなみにNehalemのキャッシュサイズは8MBと言われており、クアッドコアPenrynの6MB*2より少ないですね
4コアで約270平方mmならば、モノリシックな8コアにしたら恐ろしいことになりますね…
軽く400平方mmを超え、下手すると500平方mmをも超えてしまいますね
流石のIntelでもこのダイサイズは厳しいのではないでしょうか？
チップセットのTylersburgのダイサイズは約140平方mmとのことでこちらも巨大ですね…
Fudzillaによるとデスクトップ向けNehalemのソケットはLGA 775のままだそうです
しかしメモコン内蔵やQPIにより既存のマザーでは動作しないとのこと
サポートできないならソケットを継続する意味が不明ですね
Nehalemも既存マザーで動いたらいいのですがどうなんでしょう
メモコンは内蔵されないとかいう話がありますし
Update(9/21 19:00):
記事を修正・変更しました
◆HP、9月27日まで！！Opteron 1210搭載サーバーが送料・税込みで31500円から◆
◆ソフマップ、ASUS P5Kが16800円 - ポイント1680円分還元◆
◆ドスパラ、Acer製UXGA対応20インチ液晶が24980円◆
・IntelがNehalemの概要を発表、実働デモも公開 by PC Watch
・Nehalem uses the same 775 socket by Fudzilla
・Intel won't support AMD's SSE5 by INQ
今回のIDFでは残念ながらNehalemのアーキテクチャやキャッシュ構造について明らかにされなかったそうです
PC WatchにはNehalemの様々な構成例が挙げられていますのでご覧になってください
メモリについては前回の記事の内容の通りとなりますが、GelsingerさんはデュアルチャンネルDDR2に比べて帯域が3倍となると言っていたそうで、DDR3-1600もサポートされる可能性が高いとのこと
さらにBoBなしでも拡張規格のDDR3-2133もサポートすることを検討しているそうです
DDR3-1600でも厳しそうですので、これはなかなか難しそうですね
NehalemのCPUコアはCoreMAと同じく4命令発行/サイクルとなるそうですが、CoreMAの拡張ではなく完全新設計だとのこと
SMTについては4〜5%のサイズ増加で、0〜30、40％程度のパフォーマンスアップが見込めるといっています
それからCoreMAは64bitに弱かったのですが、Nehalemは最初から64bitを考慮しているとのこと
勿論32bitもサポートされますが、64bitでパフォーマンスが低下することは無くなりそうですね
その他SSE4.2として7命令などさまざまな命令がサポートされるそうです
SSE5についてはINQによるとサポートされないようです
SSE5はAMDに頑張ってもらいたいところですね
Nehalemのクアッドコアのダイサイズはウエハから計算すると約270平方mmとなるそうです
Nehalemと同じ45nmプロセスであるPenrynのクアッドコア(L2 6MB)はデュアルコアで107平方mm、MCMでクアッドコアとすると214平方mmでありまから、ダイサイズは大きいですね
メモコン内蔵やQPIなどでトランジスタを食われるので妥当なところでしょうかね
ちなみにNehalemのキャッシュサイズは8MBと言われており、クアッドコアPenrynの6MB*2より少ないですね
4コアで約270平方mmならば、モノリシックな8コアにしたら恐ろしいことになりますね…
軽く400平方mmを超え、下手すると500平方mmをも超えてしまいますね
流石のIntelでもこのダイサイズは厳しいのではないでしょうか？
チップセットのTylersburgのダイサイズは約140平方mmとのことでこちらも巨大ですね…
Fudzillaによるとデスクトップ向けNehalemのソケットはLGA 775のままだそうです
しかしメモコン内蔵やQPIにより既存のマザーでは動作しないとのこと
サポートできないならソケットを継続する意味が不明ですね
Nehalemも既存マザーで動いたらいいのですがどうなんでしょう
メモコンは内蔵されないとかいう話がありますし
Update(9/21 19:00):
記事を修正・変更しました
トラックバックURL
コメント一欄
1. Posted by PE 2007年09月21日 04:01
後藤さんの記事では、DDR3-2133はBoBを使わないと書いてありませんか。
Nehalemは予想以上に大きいですね。特にコアが。
かなり拡張しているかもしれません。
ただ、これだけ大きいと8コアは大変な事になりますね。
デスクトップ向けがLGA 775であるならば、やはりメモコンは内蔵されないのでしょうね。
Fudzilla情報は全く信用していないのですが、これはありえそう。
Nehalemは予想以上に大きいですね。特にコアが。
かなり拡張しているかもしれません。
ただ、これだけ大きいと8コアは大変な事になりますね。
デスクトップ向けがLGA 775であるならば、やはりメモコンは内蔵されないのでしょうね。
Fudzilla情報は全く信用していないのですが、これはありえそう。
2. Posted by ひろき 2007年09月21日 18:58
>>PEさん
指摘ありがとうございます
修正しました
Nehalemのコアの大きさはハンパないですよね
コアがかなり大きいですし
これで1ダイの8コアを持ってきたら・・・
でもAMDも45nmで8コアを出すと言っていましたし、こちらも下手するとかなり大きなダイになってしまいますね
どちらもMCMにした方がいいと思うのですが…
デスクトップ向けがLGA 775ならばメモコンは内蔵されないかと思います
既存マザーで動いたらいいですね
指摘ありがとうございます
修正しました
Nehalemのコアの大きさはハンパないですよね
コアがかなり大きいですし
これで1ダイの8コアを持ってきたら・・・
でもAMDも45nmで8コアを出すと言っていましたし、こちらも下手するとかなり大きなダイになってしまいますね
どちらもMCMにした方がいいと思うのですが…
デスクトップ向けがLGA 775ならばメモコンは内蔵されないかと思います
既存マザーで動いたらいいですね
3. Posted by PE 2007年09月21日 20:25
モノリシックな8コアは当然ないでしょうが、MCMでもかなり高コストになりますよね。
8コアがサーバ向けだけなのであれば、かまわないのかもしれませんが、デスクトップで出だすには、かなり大きいと思います。
CSIとFSBは大きく違うので、現在のLGA 775でNehalemは動かないと思います。
8コアがサーバ向けだけなのであれば、かまわないのかもしれませんが、デスクトップで出だすには、かなり大きいと思います。
CSIとFSBは大きく違うので、現在のLGA 775でNehalemは動かないと思います。
4. Posted by 野良猫 2007年09月21日 21:16
ボクもPEさんと同じくモノリシックで8コアというのは聞き間違いじゃないか
と思ってたんですが、
http://download.intel.com/pressroom/kits/events/idffall_2007/TranscriptOtelliniKeynote.pdf
Paul Otellini氏のkeynoteに
＞Eight core on one die
って書いてあったので、多分あるんじゃないですかね。
実際に8コアとなるとMP向けかDPでも上位のかなり高い製品となるんじゃないでしょうか。
ちなみに、
http://journal.mycom.co.jp/articles/2005/02/11/isscc2/index.html
Intelは最近だとMontecitoで596平方mm、
http://pc.watch.impress.co.jp/docs/2006/0224/kaigai244.htm
Tulsaで435平方mmとかなり大きなのを作っています。
両者ともキャッシュ容量のため大きいので、ロジック部分が大きい
Nehalem8コアとは事情は違いますが、8コアは製品として売れるダイサイズで
作れると考えているんじゃないでしょうか。
と思ってたんですが、
http://download.intel.com/pressroom/kits/events/idffall_2007/TranscriptOtelliniKeynote.pdf
Paul Otellini氏のkeynoteに
＞Eight core on one die
って書いてあったので、多分あるんじゃないですかね。
実際に8コアとなるとMP向けかDPでも上位のかなり高い製品となるんじゃないでしょうか。
ちなみに、
http://journal.mycom.co.jp/articles/2005/02/11/isscc2/index.html
Intelは最近だとMontecitoで596平方mm、
http://pc.watch.impress.co.jp/docs/2006/0224/kaigai244.htm
Tulsaで435平方mmとかなり大きなのを作っています。
両者ともキャッシュ容量のため大きいので、ロジック部分が大きい
Nehalem8コアとは事情は違いますが、8コアは製品として売れるダイサイズで
作れると考えているんじゃないでしょうか。
5. Posted by TOKU 2007年09月22日 02:34
あくまでダイ写真を見た感じの雑感なので、話半分以下で聞いてほしいのですが、Nehalemのコアサイズはラフにいって（後藤風）Penryn比30%UP位。
ただし、Penrynまでは、2コアで共有だったバスロジックはNehaleｍはコア単位で持つようになったと思われ、コアあたりのバスロジックの面積は増加していると思われます。
ただ、Penrynは実行ユニットをConroeより大型化したもの、ほかの部分のレイアウトは変更していないため、DCU,分岐予測ユニットのレイアウトが、間延びしてまっており、Nehalemの再設計で密度が上がっていると思われ、面積比以上のトランジスタ増加が行われている可能性があります。
ただし、Penrynまでは、2コアで共有だったバスロジックはNehaleｍはコア単位で持つようになったと思われ、コアあたりのバスロジックの面積は増加していると思われます。
ただ、Penrynは実行ユニットをConroeより大型化したもの、ほかの部分のレイアウトは変更していないため、DCU,分岐予測ユニットのレイアウトが、間延びしてまっており、Nehalemの再設計で密度が上がっていると思われ、面積比以上のトランジスタ増加が行われている可能性があります。
6. Posted by TOKU 2007年09月22日 02:52
コア全体のレイアウトはCore2とさほど変わっていないと思われます。
Nehalemのダイ写真一番左側のコアを6分割すると
右下が、バスロジック、
左下が、ICU、分岐予測ユニット、
左中が、デコーダー
左上が、RAT、ROB、RS
右上が、FPU,IEU
右中が、MOB、DCU
と並んでいると思います。
キャッシュ構造はコア単位のL1と、共有のL2という構成だと推測されます。
デコーダー周りのレイアウトを見ると、大きな変更はなさそうで、たとえばトレースキャッシュのようなものは導入していないと推測します。
デコーダー部はコンプレックスデコーダの増加が考えられます。4本のパイプラインに常時命令を供給するために、シンプルデコーダが削られ、コンプレックスデコーダを増やしていると思われます。
Nehalemのダイ写真一番左側のコアを6分割すると
右下が、バスロジック、
左下が、ICU、分岐予測ユニット、
左中が、デコーダー
左上が、RAT、ROB、RS
右上が、FPU,IEU
右中が、MOB、DCU
と並んでいると思います。
キャッシュ構造はコア単位のL1と、共有のL2という構成だと推測されます。
デコーダー周りのレイアウトを見ると、大きな変更はなさそうで、たとえばトレースキャッシュのようなものは導入していないと推測します。
デコーダー部はコンプレックスデコーダの増加が考えられます。4本のパイプラインに常時命令を供給するために、シンプルデコーダが削られ、コンプレックスデコーダを増やしていると思われます。
7. Posted by TOKU 2007年09月22日 03:03
ROB,RS、物理レジスタなどの、エントリ数も増やされていると予想。
実行ユニットはALU、SSE命令発行ポートが3、ロードストア命令発行ポート3で変更なしと予想。
で、推測をすると、
命令、データキャッシュはそれぞれ、32KB。
64Bit命令を考慮しているということで、64Bitマクロフュージョン、フェッチ帯域拡張がなされている。
デコーダーは、最低でコンプレックスデコーダ2、シンプルデコーダ2。
ROB,RS、実行ユニット等は改良は加えるものの大きくは変わってない。
その他、諸々の改良はされている。
実行ユニットはALU、SSE命令発行ポートが3、ロードストア命令発行ポート3で変更なしと予想。
で、推測をすると、
命令、データキャッシュはそれぞれ、32KB。
64Bit命令を考慮しているということで、64Bitマクロフュージョン、フェッチ帯域拡張がなされている。
デコーダーは、最低でコンプレックスデコーダ2、シンプルデコーダ2。
ROB,RS、実行ユニット等は改良は加えるものの大きくは変わってない。
その他、諸々の改良はされている。
8. Posted by PE 2007年09月22日 04:12
>>野良猫 さん
書いてありますね。
そうだとしたら、Smithfield方式のようにするのですかね。
http://journal.mycom.co.jp/special/2005/dualcore/001.html
L2キャッシュを共有するのであれば、調停機能を8コア向けにしなくてはいけないと思われるので、簡単ではない気がします。
もしShanghai世代で8コアを出してきた場合、200平方mm程度を2個になるかと思われますが、これに対抗するのに、500平方mm程度のサイズでは厳しいと思います。
>>TOKUさん
別の写真を見ているのかもしれませんが、私は逆に密度は下がっているように思います。
モジュラー化しているように見えるのですが、そうなると密度は下がると思います。
Core MAは、ロード/ストアは2ポートではないですか。
書いてありますね。
そうだとしたら、Smithfield方式のようにするのですかね。
http://journal.mycom.co.jp/special/2005/dualcore/001.html
L2キャッシュを共有するのであれば、調停機能を8コア向けにしなくてはいけないと思われるので、簡単ではない気がします。
もしShanghai世代で8コアを出してきた場合、200平方mm程度を2個になるかと思われますが、これに対抗するのに、500平方mm程度のサイズでは厳しいと思います。
>>TOKUさん
別の写真を見ているのかもしれませんが、私は逆に密度は下がっているように思います。
モジュラー化しているように見えるのですが、そうなると密度は下がると思います。
Core MAは、ロード/ストアは2ポートではないですか。
9. Posted by PE 2007年09月22日 06:46
訂正します。
ストアはアドレスとデータがあるから、3ポートですね。
余計な事を書いて、すみませんでした。
ストアはアドレスとデータがあるから、3ポートですね。
余計な事を書いて、すみませんでした。
10. Posted by TK 2007年09月27日 19:21
http://pc.watch.impress.co.jp/docs/2007/0927/kaigai389.htm
後藤さんの記事が、興味深いので上げてみようと思います。
この記事の冒頭ではNehalemはPenrynの1.5倍としていますが、共有Bus部分をカットしちゃだめでしょ(笑
カットしない場合、前に述べたとおりラフに言って1.3倍程度の拡張だと思います。
そのBusユニットはNehalemでは、コア拡張の容易にするためか、共有方式をとらなかったと思われますが、この場合1コアあたりで、従来の共有バス部分の50％以上を各コアが持つと思われます。
また、4コア（最大で8コアまで）までの共有キャッシュ調停を行えば、2コアの比ではない調停機構が必要でしょうから、各コアあたりでもBusユニットはPenrynより大きいと思います。
後藤さんの記事が、興味深いので上げてみようと思います。
この記事の冒頭ではNehalemはPenrynの1.5倍としていますが、共有Bus部分をカットしちゃだめでしょ(笑
カットしない場合、前に述べたとおりラフに言って1.3倍程度の拡張だと思います。
そのBusユニットはNehalemでは、コア拡張の容易にするためか、共有方式をとらなかったと思われますが、この場合1コアあたりで、従来の共有バス部分の50％以上を各コアが持つと思われます。
また、4コア（最大で8コアまで）までの共有キャッシュ調停を行えば、2コアの比ではない調停機構が必要でしょうから、各コアあたりでもBusユニットはPenrynより大きいと思います。
11. Posted by PE 2007年09月29日 07:37
Nehalemの8コアはモノリシックではないようです。
http://techon.nikkeibp.co.jp/article/NEWS/20070928/139872/?ST=device
登録しないと見れないと思いますので、抜粋しますが、「8コア製品は4コアのダイを2個並べた形状になる。」と書いてあります。
>>TKさん
共有Bus部分はどこのことを言っているのか良くわからないのですが、コアとL2キャッシュの間のI/O部分のことでしょうか。
この部分を共有しないと、調停できないのではないでしょうか。
http://techon.nikkeibp.co.jp/article/NEWS/20070928/139872/?ST=device
登録しないと見れないと思いますので、抜粋しますが、「8コア製品は4コアのダイを2個並べた形状になる。」と書いてあります。
>>TKさん
共有Bus部分はどこのことを言っているのか良くわからないのですが、コアとL2キャッシュの間のI/O部分のことでしょうか。
この部分を共有しないと、調停できないのではないでしょうか。
12. Posted by 野良猫 2007年09月29日 14:06
これは新しい情報ですね。
Smithfield形式の1ダイだけど事実上MCMへの布石ってことなんでしょうか。
そうだとすると、QPIでのMCMのパッケージ技術が確立するまでの
場つなぎ的な8コアって感じがしますね。
この流れをつきつめれば、チップ間の接続が違いますが、32コアのKaiferへの道も開けそうです。
Smithfield形式の1ダイだけど事実上MCMへの布石ってことなんでしょうか。
そうだとすると、QPIでのMCMのパッケージ技術が確立するまでの
場つなぎ的な8コアって感じがしますね。
この流れをつきつめれば、チップ間の接続が違いますが、32コアのKaiferへの道も開けそうです。
13. Posted by uk 2007年10月01日 02:40
またSMTが搭載されますが、これによるサイズ増加がダイで4-5%なら、最大で12.8mm2がSMT分の増加と思われ、SMT拡張の大半がコアに集中するなら、各コア3.2mm2程度であり、実にNehalemのコア面積増加の13％がSMT関連で食われるでしょう。
つまり、30％の増加のうち、SMT分13％＋Busユニット拡張分が食われ、17％以下がそれ以外の拡張に使える面積になります。
で、話はトレースキャッシュが採用されているか否かの核心部分に進みますが、netburstのトレースキャッシュは物理キャッシュ容量として80KB相当積んでおきながら、通常型キャッシュの8-16KB程度のヒット率しかなかったと言われています。つまり、1/10-1/5程度のトランジスタ効率しかない。
つまり、30％の増加のうち、SMT分13％＋Busユニット拡張分が食われ、17％以下がそれ以外の拡張に使える面積になります。
で、話はトレースキャッシュが採用されているか否かの核心部分に進みますが、netburstのトレースキャッシュは物理キャッシュ容量として80KB相当積んでおきながら、通常型キャッシュの8-16KB程度のヒット率しかなかったと言われています。つまり、1/10-1/5程度のトランジスタ効率しかない。
14. Posted by uk 2007年10月03日 18:56
よって、素直にトレースキャッシュを採用するかな？というのはあります。
とわいえ、フロントエンドにコア面積の10％分以上の拡張が含まれているのは、単にCoreMAがフロントエンドが弱点と言うことだけではないでしょう。
ダイの10％程度とはいえ、フロントエンドのだけで言えば、1.5倍程度の拡張に相当するので、かなり大掛かりな拡張になるでしょう。
ホットスポットと呼ばれるデコーダをそれだけの拡張を施したとしても、ペイになるスループットを見込んでいると考えられます。つまり目的が弱点の解消だけではないと言うこと。
とわいえ、フロントエンドにコア面積の10％分以上の拡張が含まれているのは、単にCoreMAがフロントエンドが弱点と言うことだけではないでしょう。
ダイの10％程度とはいえ、フロントエンドのだけで言えば、1.5倍程度の拡張に相当するので、かなり大掛かりな拡張になるでしょう。
ホットスポットと呼ばれるデコーダをそれだけの拡張を施したとしても、ペイになるスループットを見込んでいると考えられます。つまり目的が弱点の解消だけではないと言うこと。
15. Posted by uk 2007年10月03日 18:58
おそらく、弱点の解消もさることながら、SMTの為。
SMTによって、実行ユニットのスループットが上がることによって起こる、ROB等後段への命令供給能力を強化する為、と思われます。
CoreMAが、元から4本のパイプラインを装備したのも、最初からSMTを見据えてでしょう。
そして、その4本のパイプラインにさらに多くの命令を同時供給できるように、FusedμOPを行える組み合わせをさらに増やすかもしれません。
また、μOPバッファに於いて、融合可能な他命令とのFusedμOPを可能にするかもしれません。
SMTによって、実行ユニットのスループットが上がることによって起こる、ROB等後段への命令供給能力を強化する為、と思われます。
CoreMAが、元から4本のパイプラインを装備したのも、最初からSMTを見据えてでしょう。
そして、その4本のパイプラインにさらに多くの命令を同時供給できるように、FusedμOPを行える組み合わせをさらに増やすかもしれません。
また、μOPバッファに於いて、融合可能な他命令とのFusedμOPを可能にするかもしれません。
16. Posted by uk 2007年10月03日 19:01
簡単に組み合わせが増やせないとしたら、もっと積極的な施策が必要でしょう。
たとえば、μOPバッファ（K8ではパックと呼ばれる部分）に於いて、融合可能な他命令とのFusedμOPを可能にするかもしれません。
これはAthlon64と同じ方式で、一度命令を分解した上で、最適なμOP同士を組み合わせて、microOPSを作る方法。
CoreMAのFusedμOPは、x86命令を分解しない技術なので、Athlon64方式のほうがより多くのFusedμOPを生み出せると思います。CoreMAがAthlon64方式をとらないのは、MicroOP fusionが、命令を分解しないことで、コンプレックスデコーダの負荷を減らす事を目的にしているからでしょう。
たとえば、μOPバッファ（K8ではパックと呼ばれる部分）に於いて、融合可能な他命令とのFusedμOPを可能にするかもしれません。
これはAthlon64と同じ方式で、一度命令を分解した上で、最適なμOP同士を組み合わせて、microOPSを作る方法。
CoreMAのFusedμOPは、x86命令を分解しない技術なので、Athlon64方式のほうがより多くのFusedμOPを生み出せると思います。CoreMAがAthlon64方式をとらないのは、MicroOP fusionが、命令を分解しないことで、コンプレックスデコーダの負荷を減らす事を目的にしているからでしょう。
17. Posted by uk 2007年10月03日 19:01
恐らく、PenMの開発時に、P6アーキテクチャのIPCを更に上げようとしたら、コンプレックスデコーダを数的に強化する必要があったが、出来るだけやりたくなかったので、命令そのものを分解しないことで、デコーダを強化したのと同じ効果を得ようとしたのでしょう。
ただ、Athlon64方式のmicroOPSだと、一度分解する必要がある為、コンプレックスデコーダの数的増強は必要でしょう。ひょっとしたら、4基ともコンプレックスデコーダかも。まあ、後半は完全な想像ですが。
ただ、Athlon64方式のmicroOPSだと、一度分解する必要がある為、コンプレックスデコーダの数的増強は必要でしょう。ひょっとしたら、4基ともコンプレックスデコーダかも。まあ、後半は完全な想像ですが。
