[この記事は書きかけです]
とりあえず、多分、AnandTechの解説が今のところ一番詳しいと思われる。でも、あまり新発見はなかった。解説も無難だし。
[AnandTech] Intel's Atom Architecture: The Journey Begins
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3276とりあえず、page 6〜9まで見て、わかったこと
(1) 1 for 1はNehalemからではなくAtomからだった。
(2) Atomは初めsingle issueとして開発が開始されたが、直ぐに2 issueへとwide化された。
(3) Atomのdecoderには、slow pathとfast pathがある。slow pathは3 cycleにつき1命令しか生成できない。fast pathは1 cycleにつき2命令生成できる。命令は一度Slow pathで実行されるとtagをつけられ、次回からfast pathで扱うことができるようになるらしい。また、fast pathでは投機的なdecodeも一部supportしている。
(4) Safe Instruction Recognition (SIR, 安全な命令認識)のalgorithmによって依存関係を判別し、大きなlatencyを実行中に、続く短いlatencyの命令を先行して実行できる。これで無駄なstallを抑制している。
/*
AtomのSMTって+20%〜30%の性能向上で、実際+20% TDPがあがってるから、ほんと1 for 1だね。ただし、multi-thread限定。
Atomはin-orderだが、未来永劫このsegmentのIntel processorがin-orderだとは思わない。でも、あと5年でOOOはないだろう。…っていうAnandTech(の記者)の意見には同意です。
Atomでよく言われるLoad-op-Storeのpipelineっていうのは、命令を実行するのに、memからdataをLoadして、実行unitでOperationして、WB stageで結果をmemにstoreするという直列的な構成のことを言っているわけ。これは、RISC以前の昔、大型computerやVector型computerの時代ではよく見られたもので、Atomのblock図ではその通りL1Dへのaccessと実行unitが直列的になっている。RISC以降の近代的なpipelineでは、interlockを避けるためにLoad/Storeが実行unitに並列に配置されていて命令も専用化されるようになった。MIPSが、Microprocessor without Interlock Pipeline Stagesの略だったことを思いだそう。RISCの発想が主流になって久しいので、Atomのblock図にはものすごい違和感を感じてしまう。もちろん、P5などでも同じようになっているはずだがAtomの場合pipeline stage数が多いからこういう絵になるのだろう。
*/
//以下、page 6〜9のしょぼ要約の垂れ流し
Intel's Atom: Changing Intel from the Inside
---------------------------------------------------------
長年、Intelでは電力vs性能の経験則はこれだった: 1%のperformance増加のために2%の電力増加ならば設計者はそのfeatureをmicroprocessorへ追加することができる。残念なことに、これはPentium 4やその派生製品で使われたNetBurst architectureをもたらした。
Intel Atomは、この経験則の要求を1%の性能増加に対して、1%の電力増加に再定義して設計された最初のIntel processorである。これは革新的な変更であるし、他のIntel architecture(Nehalemなどが思いつく)でも観られるものだが、Atomが最初である。
Atomはsingle-issue, in-order microprocessorとしてstartしたが、Austin teamは直ぐにdual-issueのcoreへと設計をwide化した。しかしながら、in-orderの決定は変えられなかった。
今日のx86 processorは命令をprogram orderから外れて操作できる。(中略)。OOOE(Out of Order Execution)の能力があるProcessorは、cache上にdataが利用可能でないときに、data待ちでidle状態になる代わりに、他のreadyな命令達をmemoryからdataがfetchされている間に実行することができる。
これらout of order processorの問題は、この命令のreorderingが、追加のdie spaceと電力消費の増加を要することである。Performanceは向上するが、Intelのここでの目標はfastestではなく、fast enoughである。従ってAtomはin-order CPUのままであり、original Pentium processor以来ではIntelの初のin-order x86 coreとなっている。In-order化の決定は、複雑性と電力食いの回路の必要性を解消した。Out-of-order実行からは良好なperformanceが得られるが、それに対応したschedulingの複雑さの増加が単純に45nm Atomには大きすぎたのである。Intel CPUでout-of-order実行がPentium Proまでは相応しくなかったように、transistor sizeが十分に小さくなり、OOOの実装がAtomでも相応しくなるときがくるかもしれないことを覚えておこう。しかしながら、私は次の5年間のうちにそのOOO化の変更が見られるとは思わない。
2-Issue and In-Order: Intel's Version of the Cell's PPE
---------------------------------------------------------
Austin設計teamは、single-issueのin-order coreとして、設計をstartしたが、直ぐにsuperscalarの2-issueな設計へと拡張した。つまり、最大2命令をpipeline中で同時に発送できる。比較すると、殆どのdesktop x86 microprocessorは3または4-issueの設計になっている。
2-issue を供給するためにIntelはAtomに2つのdecoderを設けている。Decoderは命令をL1I cacheからfetchし、1/0の並びを解析して命令がCPUに何をさせるか明らかにする。これらDecoderは命令をdecodeする能力において等価である一方で、命令によって選ばれるかもないslowとfastの2つのpathを持っている。
x86 ISAは以前から、可変長命令をsupportすることに関して多くの批判をされてきた。もし10秒に2個のオレンジが渡すと言われれば、あなたの仕事は10秒に1〜3個のオレンジを渡されるよりも遙かに簡単になるだろう。前者は固定長命令の例であり、後者は可変長命令の例である。残念ながらx86は後者の分類に該当する。
Atomのslow decoding pathは、投機的なdecodeは何もできない。命令は手動で順序され、各bitは(時間をかけて)調べられるが、命令は正確にdecodeされることが保証される。また、命令は次回からはfast pathに送ることができるようにtagをつけられる。
Fast pathは、明らかに投機的なdecodeを複数採用しており、それはslow pathを通った後にsetされるtag bitに助けられている。Slow pathは、3 clockにつき1命令を生成する。一方、fast pathは、1 clockで2命令を生成できる。
IntelがBanias (Pentium M)で学んだように、不正確な投機による電力penaltyは、batteryで駆動するdeviceでは歓迎できない。Atom Processorでは、投機的な性能上の仕掛けが、低電力動作を維持するために犠牲にされる、多くのtradeoffがみられるだろう。
Instructions Gone Wild: Safe Instruction Recognition
---------------------------------------------------------
従来のin-order architectureで最も恐ろしいのは、cache上にないdataを要求する高latencyの命令である。
In-order microprocessorでは命令をin orderに実行しなければならないので、CPUがmain memoryからdataを取ってくる(100 cycles以上)まで実行unitがidleのままになる。問題なのは、このcyclesの間、何も働いていないにもかかわらず電力が浪費されることである。これは超低電力なuPが欲しいということに反している。
OOO processorでは、単純にこの問題を依存命令のschedulingによって逃れている。Schedulerは単純に実行に対してreadyかつmain memory上のdataを他の命令が待っていても仕事ができる命令を選択する。既に完全OOOE coreはAtomには電力を食い過ぎることを確認した。しかし、純粋なin-order設計をあてにすることもまた非効率になる可能性をもっている。Intel Austin teamは、賢い中間解を見つけた。
それは、Safe Instruction Recognition (SIR) algorithmと呼ばれているもので、以下のように働く。Atomが長いlatencyのFP演算を実行している時、続く短いlatencyの整数演算は、伝統的にはFP演算がcompleteするまでstallすることになる。SIR algorithmでは2つの命令を調べ、data依存があるかどうか判別する。もし依存がなければ、Atomはより新しい短いlatencyの演算を、より長いFP演算に先行して開始することができる。
SIRは、極限られた場合についてではあるが、OOOの利点の一部をAtomの完全なin order設計へちりばめる。私はもし将来のAtomで、このようなOOO風のtrickを採用する状況が拡大しても驚かないだろう。
Return of the CISC: Macro-op Execution
---------------------------------------------------------
Pentium Proは、1990年代初頭のRISC vs. CISC論争をついに終わらせた最初のIntel CPUである。ProgrammerにとってみればPentium Proは、それまでのIntel processorのようにまだx86 CISC machineである。しかし、内部的にはx86命令を受け取ったあと、単純で、速く、効率的なRISC coreで実行できるように、より小さなuopへとdecodeしている。
(中略… その後Pentium Mのuop fusionで効率の観点からCISC風のtrendが復活 …のような話 )
Atomは、Pentium Mからさらに一歩推し進めて、殆どのx86命令を分解すらしない。AtomはOOO coreではないため、大量のuopをin-flightに持つことは適切ではない。さらに殆どの命令を単一の操作に保つことによってIntelは、Atomの”width”を効率的に増加させている。
Load-op-storeやload-opの命令formatは、Atomのdecoderでは単一のuopとして扱われる。つまり、dataをloadし、演算し、結果をstoreするある命令は、今、3つのuopに分解される代わりに単一のuopとして扱われる。Pipelineを下るuopは1つだけになる。Atomは、2-issueのarchitectureに過ぎないかもしれないが、ある状況では、はるかにwiderなmachineとして振る舞うのである。
Intelは、RISCのようなより小さい操作にx86命令を分解する機能を完成させて、これらのatomicな操作に対処するcoreを非常に高い性能に構成することに過去の10年間の多くを費やした。しかし、Intelは現在、これらx86命令を多くの場合分解せず、正反対のことをしているのである。
[この記事は書きかけです]
| 
| 
| 
