ブログパーツマイリスト

無料ブログはココログ

« CPUロードマップ Core iシリーズは危機的状況【ココロ版】 | トップページ | 手塚治虫さんの命日 (今日のテーマ) »

2010年2月 8日 (月)

CPU ロードマップ Bulldozerはマルチスレッド時代のアーキテクチャ

2010年代、コンピュータにおける並列処理は、ハードウェアからソフトウェアへ移り、マルチスレッド時代になる。
Bulldozerは、マルチスレッド時代のスループット向上にあわせたアーキテクチャだ。

まず、コンピュータにおける並列処理は、大きく以下の3点。

  1. マルチタスク
  2. プロセス単位でマルチプロセッサ、マルチコアに割り当てる、OSが行う並列処理

  3. マルチスレッド
  4. プログラマーとコンパイラで用意しアプリケーションが行う並列処理

  5. out of order
  6. 複数の命令を同時実行する、CPUが行う並列処理

今までは、マルチタスク、out of orderが主体だったが、ようやく、アプリケーションがスケジューリングされた複数のスレッドをCPUに渡す、マルチスレッドの時代になった。
それにともない、CPUに求められる要素も変わる。

  • シングルスレッド時代
  • スレッドをout of orderで分解し、命令の同時実行数を向上させる

  • マルチスレッド時代
  • スレッドを高速に処理するためのクロック、メモリ帯域、コア数の向上

※POWER6は、in orderかつ高クロック化という極端な例で、さすがにPOWER7からout of orderに戻った
※Itaniumは、コンパイラで並列処理を行う極端な例だが、方向性は正しい。C++ではなく、Fortran90(77ではない)を使えばよかった。

そして、 Bulldozerはマルチスレッド時代のアーキテクチャであり、シングルスレッド時代に重要であった、命令の同時実行数とスケジューラとロード/ストアユニットのウェイトが下がった。

  • Alpha伝統のALUとAGUのペアから、AGUをスケジューラに移行して、out of orderを簡略化(トマスロ方式に毛が生えたレベル)
  • パイプライン構成をALU(I-pipe)を2本、ロード(Ld-pipe)、ストア(St-pipe)を各1本に変更し、ロード/ストアユニットを簡略化
  • スケジューラとロード/ストアユニットの簡略化に伴い、2命令の同時実行に変更

Itaniumは極端な例だが、Bulldozerも方向性は同じで、ユニット構成をみると、BulldozerとItanium2の構成比は似ている。

コアあたりユニット構成
K10 Bulldozer Itanium2 Itanium
ALU 3 2 6 4
Ld/St 3組 1組 2組 1組
FPU 3 1 2 2

蛇足だが、アプリケーション内部のスレッドは、プログラムしない限り、マルチスレッドにはならない。一つのコアの上で動くシングルスレッドになる。
そして、Windowsでマルチスレッドなプログラムを書くことは、2005年までかなり大変だった。
まず、VisualBasicは非対応、VisualC++でもMFCはほぼ使えず、Win32APIを使い、プログラマーがスレッド間の動きを制御しなければならない。
マルチスレッドの開発が容易になるのは、2005年、BackgroundWorker等が実装された、.Net framework、VisualStudio2005から。
また、SQL Serverのマルチスレッド化も2008年からと、2000年代後半にマルチスレッド化が進み2010年代に本格化する。

« CPUロードマップ Core iシリーズは危機的状況【ココロ版】 | トップページ | 手塚治虫さんの命日 (今日のテーマ) »

AMD」カテゴリの記事

コメント

http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=10

で、40エントリーのスケジューラだったと。
やはりスケジューラー強化に走りましたとさ。

今までが、8エントリー*3の合計24エントリーだったから1.66倍の増加になる。
それも40エントリーの大型スケジューラーだから、トランジスタ数は2倍くらい増えるかもしれない。

ALUを2本に減らしたのは、無駄だから無くしただけで、省電力とかコンパクト化を狙ったわけではないんだね。

そもそもbulldozerの構造はフロントエンドの4デコーダーで、整数2コアに4命令+FPUに4命令送り込まないと、全ての実行パイプが埋まらない。
つまり整数パイプを2本に減らすのは必然だったわけだ。

だが、AMDはIntel式に4本のALUを2スレッドで共有する手もあったわけだが、やらなかったね。

また、Intelと違って整数、ベクタ整数、FPUを統合した発行ポート&スケジューラーじゃないから、無駄が多い(頻度が少ないスケジューラを用意する必要がある)、AMD自身FPUは99%の時間使われていないと告白しちゃったからね。
99%使われないスケジューラーを持っていては無駄が多い。

その点Intelは整数、ベクタ整数、FPUを統合した発行ポートスケジューラだから無駄が少ない。

コンパクト化と言えばbulldozerは思ったより大きいようで、4モジュール8コアでリアノの1.5倍以上ありそうだ。
リアノは200mm2以上だから、300mm2以上となる。

45nm6コアのK10で360mm2だから、32nmで作って300mm2以上は大きすぎないか。
単純計算で、360mm2/6で1コア当たり60mm2
300mm2/4で1moduleあたり75mm2以上。
プロセス縮小を加味すると1moduleあたり130mm2位になるだろうか。

ちなみにSundaybridgeは230mm2程度として1コア当たり57mm2
GPU込みの数字だから実際はもう少しコンパクトだろう。

全然コンパクト化、省トランジスタ化を狙ってないねw

だが、アーキテクチャとしては省電力対策をいろいろやってるらしい。
逆に言えばそうしないと、省電力にならないのでしょう。

したがってBulldozerをトランジスタを減らして省電力を狙ったコアなどとは、現状では思っていません。


私も、今のところコア単位の統合RSを支持しています。大原氏はALU、AGU独立のRSを想定しているようですが。

>RSをパイプラインごとに分けると、一方のパイプラインが空いた場合に、命令を送り込めない

仰るとおりです、無論K10でも前段階で、各RSに極力うまく振り分けているのだと思いますが、L1にヒットしなかった場合、L2に行くだけでも5-10サイクル以上のロスが発生して、空きサイクルを8エントリーの少ないRSでやり繰りする羽目になり空回りしやすいのですが、K10では3本ありましたから、その他2本で回して何とかしていたのだと思います。
実際、シングルスレッドでCore2/i7より不得意だった理由の一つに、この分散RSの影響はあったと思います。

AMDとしては、先代のK7のライバルであったPen3は、Core2より貧弱なアーキテクチャだったので、これでも十分だと思っていたのでしょう。
まさか、これほど長くK7アーキテクチャを使いまわす予定ではなかったはずですし。

Bulldozerは2本なのでそのようなやり方は、取りにくいでしょう(IPCが結構下がっても良いというなら別ですが)。
従って、ALU*2 、L/S*2一括管理の大型RSにするほうが効率的と考えます。
どの程度のRSエントリーになるかわかりませんが、同じようなALU*2、Load*1、Store*1だったPenMの場合で統合RSは24エントリーでした。
おそらくこれに近いレベルかもしれません。

>パイプラインを減らした時点で、シングルスレッド性能のピークは、K10より落ちることを許容している

ただ、SandaybridgeはCorei7よりもIPCはさらに向上すると見られ、K10より落とすのは冒険でしょうね。
Intelは少しづつでもIPCをあげて行く方向であり保守的ですが、AMDはシングルスレッドを落としででもマルチスレッドの効率を取ったので、マルチスレッドに急速に進まない限り不利なアーキテクチャでしょう。

つまり、何度も言ってるように、AMDはリャノのK10の正統進化系と、bobcatのIPIA対抗、Bulldozerのサーバー向けアーキテクチャを、数世代に渡って並存させて、しかるべきタイミングでBulldozerに全面移行させると思います。

私は、管理人さんの言うような、今すぐモバイルに展開させるべくTDPを下げる必要は感じませんし、モバイルに展開させるにしてもアプリケーションのマルチスレッド化が進んでからだと思います。

とても詳しいですね。
さらに面白いのは、私はまったく逆のことを予測しています。
私は、ROB、AGUを含めRSも、ALUのパイプラインごとではなく、コアごとだと予測しています。
POWERのBranchのようなスケジューリング、アドレス生成、out of orderの命令キュー発行といった前段階と、実行段階のパイプラインを切り離すと考えています。

理由は、以下の3点です。

・RSをパイプラインごとに分けると、一方のパイプラインが空いた場合に、命令を送り込めない
・SMTを使わないBulldozerは、処理できるスレッド数を増やすためコアを小さくして増やす必要がある
・パイプラインを減らした時点で、シングルスレッド性能のピークは、K10より落ちることを許容している

ただ、ROBやRSを、パイプラインごとではなく、コアごとにすると、おっしゃるとおり、エントリー数によっては逆に大型化する可能性があるということですね。

しかも、確かにトランジスタの稼働率があがれば、消費電力も上がりますね。AMDはACPを提唱していることを忘れていました。

おっしゃるとおり、サーバなら、パフォーマンスが上がれば高いTDPも許容されます。
ただ、AMDがBulldozerをモバイルからサーバまで展開させるなら、TDPやダイサイズを減らすはずですが。

Bulldozerが出てくるのが楽しみです。

Bulldozerの話題をひとつ。

http://ascii.jp/elem/000/000/489/489200/index-2.html

ここで大原氏が言ってるようなスケジューラーだと従来よりは複雑な構造になるだろう。

今までは、デコーダーとパックでMacroOPに変換した後、ICUでプールし、RSに発行、RSでMicroOPに分離して別々に実行ユニットに発行って感じだったが、BulldozerはMacroOPに変換した後、ICUでプールし、2つの実行ユニット群それぞれで命令をMicroOP分離、バラバラのMicroOPを再び第二ICUともいえるユニットに再びプールし、MicroOP単位で実行ユニット別に別れたRSに発行、タイミング調整し実行ユニットに発行って流れになるらしい。

大原氏推測ではRSはALU*2、L/S*2用に合計4つのRSと推測している。
K8はALU/AGU*3用に合計3つのRSです。

大原氏の推測が必ずしも当たるとは言えないが、私も従来のK8よりも一手間二手間掛けるだろうと見ている。

つまり、2つに減った実行ユニットを、如何に効率よく回すか、が重要であり、逆に言うと、減ったために
手間掛けて効率よく回す必要が生じたと言える。
したがって、2issueに減らしたから、スケジューラーが楽にになるとは、まあ、考えにくいでしょう。

単純に消費電力が単純に減らないというのは、トランジスタの稼動率の話で、K10はかなりリッチなALUだった分遊んでいるトランジスタも多い。
一方、BulldozerはAMD自らトランジスタ効率の向上を掲げているくらいだから、k10よりは稼動率が高いのだろう。

稼働率が高いということは、BulldozerのトランジスタがK10より少ないとしても、単純にその分低消費電力とはいえないと言うという事。
Corei7がHTの有効時に無効時より消費電力が上がるのも、トランジスタがサボれなくなった為。


>Bulldozerは、out of order 2wayにあわせて、スケジューラもシンプルに縮小均衡させるでしょうから、Bulldozerの1モジュールはデュアルコアよりトランジスタ数とTDPは減ると思います。

スケジューラはすでに述べたようにシンプルか出来ない。

トランジスタは減るかもしれないが、トランジスタの稼働率となると話は別。
したがってTDPが下がるとは言い切れないでしょう。

>BulldozerのTDPが、K10より高かったら、失敗作です。

そうでもないですよ。
たぶん、サーバー向けのスループット重視の設計なんでしょう、
マルチコア、マルチスレッド前提なら、Bulldozerのほうがコンパクトにコアを増やせるでしょう。
その意味で失敗作とは言えないでしょう。


次はALU編

ALUは3本から2本に減ったので66%に減らせたと考えがちですが、汎用ALU3本+乗算器+除算器と考えると、ALUを1本を減らしても、それほど減らない。多分80%位か。
ALU全体で乗算器と除算器の占める割合は大きく、4割くらいとすると、汎用ALUは6割程度、内2割削減として、8割程度と考えられる。

一方、フロントエンドに目を向けると、デコーダは3本→4本に増えるし、これに伴いプリデコードも強化されるだろう。
しかも、SMTという新たな複雑な機構も加わる。
こちらは単純に考えてもK10よりかなりトランジスタが増えるだろう。

また全体のパイプラインも、ICUまでが4本に増えK10の3本より増える。
FPUは単純に倍増されるだろう。


まとめると、フロントエンドはK10シングルコアよりずっと大きいだろう。
スケジューラーも大して簡素化できない、ALUも思ったほど減らない。
FPUは倍増。
全体のパイプラインは4本。
すでに述べたようにパイプラインも増えるかもしれない。


とすると”bulldozer1モジュール1コア”は”K10シングルコア”より恐らくトランジスタは使っているかもしれない。

じゃあ、”bulldozer1モジュール2コア”と、”K10デュアルコア”はどうなの?って事ですが、

AMDの言う50%増加で80%のスループットというのは、bulldozer1モジュール1コアからbulldozer1モジュール2コアに拡張した場合の話ではないかと考えている。

したがって、bulldozer1モジュール2コアとK10デュアルコアの比較は、bulldozerはフロントエンドを共有している分、K10デュアルコアよりは小さいのかもしれない、したがってbulldozerのトランジスタ数はK10デュアルコアの75%以上100%未満とあたりだろうか。

ただし、消費電力が単純に減るかというとそれも別な話でしょうね。

>Bulldozerは、out of order 2wayにあわせて、スケジューラもシンプルに縮小均衡させるでしょうから、Bulldozerの1モジュールはデュアルコアよりトランジスタ数とTDPは減ると思います。

いいフリをしてくれましたね。
私もその点に関しては、考察があります。
実は、2way化はスケジューラーは大してトランジスタの削減に繋がらないと考えています。何故か?
K10までのCPUは実行ユニットに余裕を持たせることで、スケジューラーを簡素な構造にしても、性能が出せる構造にしていた。
ぶっちゃけいうと、エイヤパーでALUに放り込んでも、ある程度の性能が出せるということ。
これは、等価の機能を持つリッチなALUを3本使うことで、楽なスケジュールを組めた。
しかし、2本にALUを減らしても、K10に近い性能を維持しようとすれば、ALU1本あたりの負荷は上がり、よりスケジュールを密に組む必要がある。

現在、K10のRSは、24エントリーですが、実は8エントリー*3の構造になっています。
ALU1本あたり1つのRSを持つ構造です。

じゃあ、たとえばbulldozerは2本だからといって、8エントリー*2の合計16エントリーに減らせるかといえば、恐らく無理だろう。
なぜなら、16エントリーでは16命令分の並び替えしか出来ないから。
これはOOOでの並列度の抽出に制限が出てくるだろう。

しかも、減ったALUで、ある程度の性能を稼ごうとすれば、よりALUを効率よくまわす必要があり、必然的にスケジューラーの負荷が上がる。

たとえば、12エントリー*2になるとか、場合によっては2ALUを一括でスケジュールを組めるように、24エントリーの大型スケジューラーにするとか考えられますね。
こうなるとスケジューラーを簡素化できるという話では無くなる。


無論シングルスレッド性能が”K10の80%以下”で良いってことなら、スケジューラーも簡素化できるでしょうが、Pen4みたいなCPUつくる方が、現実で気ではない気がします。
ただでさえL1キャッシュが16KBに減って、IPC下がるのにスケジューラーで簡素化させる事は出来ないでしょう。

>BulldozerのTDPがK10より低いとも言い切れませんけどね。
BulldozerのTDPが、K10より高かったら、失敗作です。
AMDはかなり危険な状態になります。

Bulldozerは、out of order 2wayにあわせて、スケジューラもシンプルに縮小均衡させるでしょうから、Bulldozerの1モジュールはデュアルコアよりトランジスタ数とTDPは減ると思います。

ただ、どれくらい減るのか、それが問題です。モバイルへの展開を鑑みると、1モジュール+GPUでArrandaleの25Wが、最低限クリアすべきターゲットになると思います。

パイプラインのステージ数が増えると、クロックは上げやすくなりますが、TDPも増えるので、バランスが難しいですね。

>ただ、K10はTDPが高いので、1モジュールのBulldozerをモバイルに載せると思います。

BulldozerのTDPがK10より低いとも言い切れませんけどね。
AMDは50%のトランジスタ追加で80%のスループット向上と言っているが、これはトランジスタ効率を言ってるだけで、絶対的にトランジスタが少ないとは言ってないし、消費電力が少ないとも言っていませんけどね。

その80%だって、DualCoreなら100%のトランジスタ追加で、100%の性能向上という理論上の話であって、実際は40-60%程度のスループット向上が関の山って感じもするんですが。
ま、HTが最大40%性能が上がるってのと似た話でしょう。

話が少し逸れましたが、管理人さんの”だったら良いな”予想では、LIanoは1年程度でBulldozerに取って代わるらしいですが、実際はそうならないでしょう。


>パイプラインのステージ数が増えるとは聞かないので

今の段階で、パイプライン段数などの突っ込んだ話はしないでしょうがね。

一応、FPパイプラインは最低でも2段増える。
レイテンシーが6になっているので。
整数、FPスケジューラーはどうなるか知りませんが、個人的な予想で言えば、今までより高度なスケジュールを行う分1-2段は増える可能性があるかも知れない。
フロントエンドも、パイプラインが4本に増え、SMPなどの複雑度も考えると、数段増える可能性がありますけどね。

パイプラインの合計で整数で14-16段、FPで21-24段程度には増えるかもしれない。

おっしゃるとおりBulldozerは、多重度の高い整数のスカラ演算を強化したCPUですから、普通のコンシューマには、K10の方が快適に感じる場合が多いかもしれません。
ただ、K10はTDPが高いので、1モジュールのBulldozerをモバイルに載せると思います。

XOPは256bit版3DNow!ですね。AMDは、ベクタ演算はGPUにやらせたいでしょうから、XOPはAMDもちゃんとやっているという宣伝と、Intelとのクロスライセンスの材料で十分だと思います。

将来的には、Intelと互換ではなく、3DNow!のようにひっそり忘れ去られていくような気がします。

>AMDのメインターゲットはサーバ市場なので、マルチスレッド優先なのでしょう。

たぶん、サーバー用なのでしょうね。多数のスレッドが常時走っているような状況を想定しているのかもしれません。

>コンシューマで4コアは使い切れていないと思いますので、高クロック2コアが、TDPとのバランスを考えても、有益と思います。

私はbulldozerは当面、下のランクまでは入ってこないと思います。
bulldozer1モジュール2コアだと、K10DualCoreやSandaybridgeDualCoreの方が有利な戦いが出来ると思います。
つまり、bulldozerには、このクラスでの戦いの場は与えられないのではないかと思います。


>コンシューマでは負けるなんてことは勘弁してほしいです。
ただ、コンシューマはLIanoなので、しばらくK10ですね。

コンシューマでは厳しいと思います。したがってLIanoがいるんだと思います。

LIanoは開発の遅れのため、間に合わせで為出てきたとか思われていますが、実際は、Bulldozerが活躍できる状況はすぐは来ない、下手すると数年先?なので、AMDは初めからBulldozerはサーバー向け、下がってもハイエンドデスクトップまでを想定していたのかも知れません。

暫くコンシューマのミドルレンジ以下は、LIanoが受け持つ形が続くと思います。

実際、K10の発展型+GPUのほうが、Bulldozerより喜ばれるんじゃないかと思いますしね。

気になるのはXOPの扱われ方ですね。

Bulldozerがハイエンドしか登場できないなら、XOPをサポートするCPUが極めて限られます。
したがって、将来的にLIanoの後継K10コアにもAVXサポートされ、また、FMAなどの一部のXOP固有命令は、Intel版FMAと合流するんじゃないかと想像します。
また、Intelもベクター整数を256Bitに広げる可能性もあるので、さらなる将来には、ほぼ全部のXOPがIntelの拡張命令と互換がとられるんじゃないかと想像します。

コメントありがとうございます。
AMDのメインターゲットはサーバ市場なので、マルチスレッド優先なのでしょう。
サーバはマルチスレッド化されていますが、コンシューマではシングルスレッド、せいぜい2スレッドです。

コンシューマで4コアは使い切れていないと思いますので、高クロック2コアが、TDPとのバランスを考えても、有益と思います。

BulldozerのL1がコアあたり16KBというのは、ALUが2本、ロード/ストアも2本にあわせたとしても、K10は、ALU、ロード/ストアが3本で64KBので、計算があいませんね。
ボトルネックを作ってどうするのか。

おっしゃるとおり、Intelと同じような設計思想なのかも知れません。
L2キャッシュも、Core2と同じ共有ですから、2つのスレッドが扱うデータがL2に収まる限り、L1を減らしてもL2へのアクセス速度が速ければ、パフォーマンスは向上するのでしょうが、ちょっと皮算用のような気がします。
キャッシュをはずしたり、あふれたときの影響が大きいですが、確率的に少ないと見込んでいるようですね。

Bulldozerは、2命令同時実行にあわせて、パイプラインやキャッシュをバランスさせているのでしょうが、やや極端な感じがします。
それとも、K10が過剰だったのか、リリースが楽しみです。

それに、Bulldozerはどこまでクロックがあがるのか、気になります。
パイプラインのステージ数が増えるとは聞かないので、アーキテクチャとしてクロックを上げるには限界があるので、32nmのプロセス頼みでしょう。
おっしゃるとおり、ローンチ当初は、K10から1割から2割のアップだと思います。

Bulldozerには期待しているので、サーバでは勝てても、コンシューマでは負けるなんてことは勘弁してほしいです。
ただ、コンシューマはLIanoなので、しばらくK10ですね。

噂レベルで出ている話だと、BulldozerのL1データキャッシュはCoreあたり16KBでモジュール合計で32KBらいしいですね。
スレッドあたりだと16KBな訳で、K10の64KBに比べると1/4、Corei7と比べても1/2ですね。
L1命令キャッシュは判りませんが、後に述べる設計思想からすると、フロントエンドも同じ32KBなのかもしれません。
これも、現行K10の1/2、Corei7と同じ容量になります。

AMDのアーキテクチャは、L1にヒットした時の性能を特に重視する設計で、事実フェッチウインドウはCorei7と同じ32Byte、データアクセスは128bit*2のロードが可能。
これは128Bitのロードと128Bitのストアが可能なCorei7よりも、トータル256Bit帯域は同じでも、柔軟性はK10の方が上です。

可能性として考えられるのは、L1→L2以降のアクセス速度を強化して、ぶっちゃけいえばIntelみたいな設計になるのでしょうか。

しかし、このL1の変更は実行ユニットを3→2に減らす以上に大きな性能低下になりはしないか?
特に片側のコアしか動かないシングルスレッド時において。

目指すところは、コアをコンパクトにして、且つ高速化の足かせになりそうなL1を1/4に減らす。
IPCは下がってしまうが、高クロック(K10より1-2割)にして下がった分をカバーしようということなのでしょうか。

幾らマルチスレッド時代っても、整数演算機がクラスター辺り2つのというのはどうなんでしょうね。
なんだかんだいっていまだにシングルスレッドアプリケーションが圧倒的に多いですし、エンコードでさえシングルスレッド、2スレッド程度のもかなりあります。
従来の1.5倍くらいのアーキテクチャで、2倍程度のコアを積めるのがメリットなんだと思いますが、実際8スレッドアプリでもそんなに多くない現状では、当面コアを持て余す。

また、整数演算はベストケースでもK8と同程度、平均的にはたぶん下回るなんてオチも。
それをAMD版ターボブーストの類でカバーするんだろうか。
逆にSandaybridgeは、シングルスレッド性能を少しであるが上げていくようだ。

俺はAMDは賭けに出たな。と思いますね、
Sandaybridgeと比べて得意不得意がはっきりしたアーキテクチャで、AMDが思い描く方向に思い描く速度で進めば良いけど、思惑を外すと不得意部分が仇になるんではないだろうか。

コメントありがとうございます。
ロード/ストアは、各々1本という意味でしたので、ALUやFPUと単位が違いました。修正しました。
実は、アバウトな比較でして、ItaniumとItanium2には、他に、SIMD用のFPUのパイプラインが2本、分岐処理用パイプラインが3本あったりします。
どれくらい役に立っているか、わからないのと、比較しようが無いので、はしょりました。

BulldozerのFPUは、1モジュールで2本を、2コアが共有している上、128bitでは2本、256bitでは1本なので、難しいです。
私は各コア1本づつと思っていましたが、そうでもないようで、実際どうなるか楽しみです。

はじめまして
Bulldozer関係のブログを調べていて此処にたどり着きました
ユニット構成について勘違いがあります
Bulldozerの整数演算のパイプライン構成はALU*2/LdSt*2の計4本で、
FPUも128bitが2本です。(256bitとしては1本ですが)

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/217868/47517451

この記事へのトラックバック一覧です: CPU ロードマップ Bulldozerはマルチスレッド時代のアーキテクチャ:

« CPUロードマップ Core iシリーズは危機的状況【ココロ版】 | トップページ | 手塚治虫さんの命日 (今日のテーマ) »