できるXeonPhi！
はじめに
XeonPhiハッカソンがあまりにも人が集まらないと嘆いていたら、
「そもそもXeonPhiに対する事前情報がなさ過ぎてプログラム書けるかどうかすら疑問」
という話をいろんな所から聞いたので、じゃあチュートリアル的なもの書きますねというのが今回の趣旨です
公式資料
Intelさんからの公式資料は以下にあります
http://software.intel.com/en-us/mic-developer
XeonPhiについて
Intelの開発したメニーコアアクセラレータボードのことです。
正式にはブランド名。現在のは第二世代MIC, Knights Cornerというもの。
PCIExpress Gen 2.0 x16スロットに接続し、PCIe経由でホストCPUとやり取りを行います
XeonPhiはいくつか種類がありますが、5110Pでは内部では60コア / 240スレッドが動作しています
次世代は既にいくつか情報が出ており、名称はKnights Landing。現在のようにPCIe経由での動作するカードに加え、
現在のXeonの代替、つまりLGAソケットに刺さるモデルも出るようです
アーキテクチャ
詳細はPCWatchの後藤さんの記事に詳しいです
http://pc.watch.impress.co.jp/docs/column/kaigai/20120910_558566.html
http://pc.watch.impress.co.jp/docs/column/kaigai/20120911_558738.html
言葉でさらっと言ってしまうと
プログラミングモデル
XeonPhiでコードを実行する基本的なモデルというのは3種類あります
- XeonPhiのみでコードを実行する
- ホストの特定の部位をXeonPhiにオフロードする
- XeonPhiとホストを協調動作させる
XeonPhiではLinuxが走っているため、1の場合はそのままログインしてXeonPhi上でプログラムを実行します
対して2では、CUDAやOpenCLのように特定の場所だけをXeonPhiに渡して実行してもらうことになります
最後の3は、XeonPhiの1スレッドを1プロセスのように扱うMPIのプログラミングモデルです
また、現時点では開発にICCが必要です。
現時点では、開発にICC、またはMPSS(Intel Manycore Platform Software Stack) を導入したgccが必要です。
ただし、gccの場合、XeonPhiの組み込み関数はサポートしていません
0710 修正
この記事では1,2について解説します
XeonPhiでのみコードを実行する
ここで重要なことは、XeonPhi上でのみコードを実行する場合、基本的にはコンパイルし直すだけで動作する、ということにあります
取り出したるは何の変哲もないただのHello world.
// hello_world_mic.cpp #include <iostream> int main() { std::cout << "Hello world" << std::endl; return 0; }
これを、
$ icpc hello_world_mic.cpp -mmic -o hello_world
とコンパイルすると、hello_worldというバイナリが出来るのはいつも通りですが、これはXeonPhi用のバイナリになっています
先に指定した-mmicオプションがXeonPhi用のオプションで、このコードを使って生成されたバイナリはXeonPhiで実行可能なものになります
出来上がったバイナリを
$ scp hello_world mic0:~/
とかやると、XeonPhiに転送されます
したら続いて
$ ssh mic0
でXeonPhiにログインしてからの
$ ./hello_world
でXeonPhiのHello worldが実行できました。はい
これだけだと味気ないんで、並列化して240のHello worldにしましょう
// hello_world_mic.cpp #include <iostream> int main() { #pragma omp parallel { std::cout << "Hello world" << std::endl; } return 0; }
変更点は、並列にしたいところをブロック化してOpenMPプラグマを突っ込んだぐらいです
$ icpc hello_world_mic.cpp -mmic -openmp -o hello_world
同様に、こちらの変更点もOpenMPをEnableにするオプションを追加したぐらいです
先ほどと同様に、hello_worldバイナリをXeonPhiに転送して実行するとアホっぽいぐらい画面が埋め尽くされたかと思います
XeonPhiのみでのコード実行は大体こんな感じ
ホストの特定の部位をXeonPhiにオフロードする
ここで重要なことは、ホストの特定の部位をオフロードする場合は、そのオフロードしたい場所をプラグマでくくってあげるだけでオフロードが可能、ということです
続いて取り出したのはこんな感じのvecAdd.cpp。ただ単に要素分足しているだけのコード。
// vecAdd.cpp #include <iostream> int main() { const size_t num = 1024; float* A = new float[num]; float* B = new float[num]; float* C = new float[num]; for(size_t i = 0; i < num; ++i) { A[i] = static_cast<float>(i); B[i] = static_cast<float>(i); C[i] = 0.0f; } // vector add for(size_t i = 0; i < num; ++i) { C[i] = A[i] + B[i]; } delete []A; delete []B; delete []C; }
vector add部分をXeonPhiに乗せたいと考えます
オフロードしたい箇所をプラグマで指定します
// vector add #pragma offload target(mic) \ in(A:length(num)) \ in(B:length(num)) \ out(C:length(num)) { for(size_t i = 0; i < num; ++i) { C[i] = A[i] + B[i]; } }
このようにすることによって、プラグマ以下のブロックがXeonPhi上で実行されます
また、target(mic)行ですが、target(mic:n)でXeonPhiの番号が指定できます。複数枚積んでいるケースではXeonPhiの指定が出来るのでそれなりに便利
その下にあるin, outは、それぞれデータの入力、出力を制御しています
in, outのみならず様々に制御構文があるのですが、それはIntelさんのドキュメントを参照してください
http://software.intel.com/sites/default/files/Beginning%20Intel%20Xeon%20Phi%20Coprocessor%20Workshop%20Offload%20Compiling%20Part%201.pdf
これです
このときのコンパイルは
$ icpc vecAdd.cpp -o vecAdd
です。先ほどまであった-mmicオプションは、今回はつけません
前節でもありましたが、XeonPhi上では最大240スレッドが動作します
手っ取り早くそのスレッドを扱うには、OpenMPを使用することが挙げられます
つまり、先ほどのコードはさらにOpenMP対応も加えて
// vector add #pragma offload target(mic) \ in(A:length(num)) \ in(B:length(num)) \ out(C:length(num)) { #pragma omp parallel for for(size_t i = 0; i < num; ++i) { C[i] = A[i] + B[i]; } }
のようになります
これでホストからXeonPhiに対して並列処理をさせることが出来るようになりました
それがHaswellの実力だとしても
Haswellの発売から10日――
どうも。山田です。
関東GPGPU勉強会 #2にご参加いただきました皆さま、どうもお疲れ様でした。そしてありがとうございました。
大変楽しい会になりましたことにお礼を申し上げます。
Twitterのほうではなんかいろいろ呟いてますが、GPGPUもやるならXeon Phiもってことで、Xeon Phiハッカソンをやろうってことが決定しました
いかんせん、Xeon Phiに関しては情報もコードも少ないので、今回は勉強会形式ではなく、ハッカソン形式にして実際にコードを書いてもらい、それをオープンにしていくことで、Xeon Phiの実際のコードは、性能は、書きやすさは、性能の出しやすさは、なんていうことを考える一因になれば、と思っています
さて、何書こうかなーとかのんびりと書き書きとあれこれ益体のないコードを量産しておりましたら、先日こんな記事がガジェ通さんから出てまいりまして
Haswellは “失敗作” なのか？ ‐炎上騒ぎに見るCPU性能の検証と考察
なかなか刺激的なタイトルだと思います
まぁ、GT2の時点でGPU側の性能を論ずるのであれば少なくともEU分を倍とかしてかんがえてあげてくれよという感じがありますね
というわけでGPU側については、GT3eが出てくるまでしばらく保留します
さて、CPUの性能はどんなもんなんでしょうか
折しもFXシリーズの新作が投入された本日、FXシリーズとHaswellの対決を噛ましてみたいと思います
NAS Parallel Benchmarkの話
一応、このベンチマークには何があるかというのを記載します。
| EP | 乗算合同法による一様乱数、正規乱数の生成 |
| MG | 簡略化されたマルチグリッド法のカーネル |
| CG | 正値対称な大規模疎行列の最小固有値を求めるための共役勾配法 |
| FT | FFTを用いた３次元偏微分方程式の解法 |
| IS | 大規模整数ソート |
| LU | Synmetric SOR iterationによるCFDアプリケーション |
| SP | Scalar ADI iterationによるCFDアプリケーション |
| BT | 5x5 block size ADI iterationによるCFDアプリケーション |
http://mikilab.doshisha.ac.jp/dia/smpp/01_bench/naspara.html
クラスはAを使用しました。ただし、AだとISが小さすぎるのか0なので、今度はデカいのでやろうと思います
Time in seconds.
| Thread | FX-4100 1Thread | FX-4100 4Thread | i7 4770K 1Thread | i7 4770K 4Thread |
| EP | 40.79 | 13.73 | 21.47 | 3.24 |
| MG | 2.10 | 1.44 | 0.88 | 0.74 |
| CG | 1.68 | 1.04 | 0.82 | 0.49 |
| FT | 6.78 | 3.20 | 3.23 | 1.27 |
| LU | 64.44 | 25.19 | 36.68 | 9.83 |
| SP | 93.06 | 65.97 | 36.20 | 26.44 |
| BT | 123.01 | 86.33 | 65.00 | 36.84 |
Mop/s
| Thread | FX-4100 1Thread | FX-4100 4Thread | i7 4770K 1Thread | i7 4770K 4Thread |
| EP | 13.16 | 39.09 | 25.00 | 165.69 |
| MG | 1849.33 | 2700.14 | 4421.16 | 5256.33 |
| CG | 890.96 | 1444.51 | 1829.20 | 3032.36 |
| FT | 1052.43 | 2232.62 | 2210.37 | 5611.27 |
| LU | 1851.26 | 4736.25 | 3252.15 | 12131.55 |
| SP | 913.51 | 1288.60 | 2348.05 | 3215.27 |
| BT | 1368.02 | 1949.31 | 2588.84 | 4568.09 |
お、おう……
まぁこの戦いフェアじゃない。アンフェアだめっちゃアンフェアだという指摘は、なるほど確かにすいませんでしたとしか言えない。
なんでFX-4100なんだよ！せめてPiledriverのFX-8350ぐらい呼んでこいよ！！
……というお叱りはごもっともなので、Piledriverの8350を持ち出そうと思います
いや、稼働状態ではあるんですが、ちょうど別のことやっててベンチが取れないタイミング…
Haswellを使おう
山田です
家帰ってきてから五分後にこうしてブログを書いているわけですが、さっそくHaswellを使おうとあれこれ頑張ろうと思います。
その前にまずはless /proc/cpuinfoの結果を
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 60 model name : Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz stepping : 3 microcode : 0x7 cpu MHz : 800.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid bogomips : 6995.72 clflush size : 64 cache_alignment : 64 address sizes : 39 bits physical, 48 bits virtual power management:
燦然と輝くavx2の文字がアツい！
しかし目玉の一つであるTSXが使えない…ということに気づいたのは先輩のツイートを見てからでした
TSXの使えるHaswellを買うフラグというのが経っているように見えるのですが、そんな事はないと信じたい山田です
関東GPGPU勉強会#2開催しました
お疲れ様です。山田です
去る6/1、表題のとおり、関東GPGPU勉強会#2開催しました！
当日にはたくさんの方々に会場に足をお運びいただいて、主宰としてこれほどまでにうれしいことはありません。
ご協力いただいたアンケートもありがたく目を通させていただいています。意外にも山田の発表がそれなりに評価をいただいているのが大変驚くやら恥ずかしいやら……
それでは、謝辞を。
発表を快くお引き受けいただいた、@dandelion1124さん、@_likrさん、@ksakiyama134さん、@kalab1998さん、@aokomoriutaさん、@lindenhutさん、@tanakmuraさん。本当にありがとうございました。皆様のおかげで大変有意義な会になりました
また、会場をご提供いただいたさくらインターネット株式会社様にも、この場を借りて厚くお礼をもうしあげます。ありがとうございました。
さらには自分のネタにかかりきりで運営のほうを全くやっていなかった山田にかわって細々としたことをすべて引き受けてくださった@OmochiStrikeさん。あなたがいなければこの会は第二回を迎えなかった可能性が高いです。本当にありがとうございました
そして、ご来場いただいたすべての方へ。楽しんでいただけたようでなによりです。僕も楽しかったです。またやりたいですね！ありがとうございました。
当日のまとめは以下のtogetterを見られるとよくわかるかと思います
http://togetter.com/li/511911
@tomoaki_teshimaさんありがとうございます
というわけで適当に第三回の妄想でも連ねることにします
最近、GPGPUのネタとか本気でないわけですよ
なので、GPGPUを使って開発をしている人ではなく、GPGPUを純粋にテクノロジーとして使用している人々の話から、もっとこうできるんじゃないかというような話に結び付けていきたいと考えています。
時代は折しも4Kレンダリングの話も漏れ聞こえてくるようになってまいりました
http://ascii.jp/elem/000/000/771/771053/
こんな感じになりつつあるわけです。ミクさんはフォトリアリスティックになっているわけです
@uimacさんの作られたMMDBridgeを使えば、レンダラをMMDのものから外部のGPGPUレンダラにフックさせて、フォトリアリスティックなミクさんを描いたりできるわけです
そういうような応用事例っていうのは世の中にいっぱいあるはずで、そういうのを観たいなぁとちょっと思っていたりします。第二回でも同じこと言いましたけど
とはいえ、第三回がどうなるかはまだ未定です。
今はひとまず、ヒアリングをしていきたいと思っています。
それでは皆様、重ねてになりますが本当にありがとうございました。
HaswellにFedora18をインストールする作業に戻ります！
関東GPGPU勉強会#2開催します
誰だよAdC2012延長戦とか言ったの…
舌の根も乾いていませんが3月の末日に関西GPGPU勉強会に行ってきた……んですけどあれからもう一か月もたつんですね(遠い目
という言葉通り、関東GPGPU勉強会#2やります
ATNDはこちら
http://atnd.org/events/39073
今回はさくらインターネット様にいろいろご協力いただいて、会場を提供していただけることになりました。ありがたやー
新宿方面には足を向けて寝れませんね。俺今どっち向いて寝てたっけ…
そしてさらには今回はGeForce GTX Titanをお借りしています
Keplerのベンチとるぞ！という方は貸していただける(のかな？)
というわけで、毎度のことながら発表していただける方を募集しています。お題は自由！ 発表していただけるとURESHI!
しかしながら、GPGPUというのも去年から比べると非常に一般化してきており、CUDA/OpenCLプログラマ以外にも
「GPUを使ったこういうアプリケーションがあるでしょう！使うと便利でしょう！」というのをアピールしていただけると大変面白いと思います
なので、今回はこういった「GPUの恩恵を受けているユーザーの方」にも発表していただけたらなーと思っています
ぜひ、これをご覧の皆様、ご検討のほどお願いいたします
GPGPU Advent Calendar 2012延長戦のおしらせ
何勘違いしているんだ。俺のAdvent Calendarはまだ終了してないZE!!
この記事はGPGPU Advent Calendarの12月25日分の記事のはずです
まずはお礼を申し上げます。
GPGPU Advent Calendar 2012にご参加いただいた皆様、誠にありがとうございました。
当初は僕が泣きながらRadeonについて語ることになるのかと思ったら、意外にも10名の方にご協力いただけることになりまして、大変うれしく思っています。
GPGPUというものもだいぶメジャーになってきた感じがなくはなく、OpenCLが出たときにはGPGPU?なにそれ、食える？みたいな感じだったのも、今となってはなかなか面白げないい思い出といえるのではないでしょうか。
先日発売されましたwiiUでは、GPUにRadeonの5000番台が採用され、GPGPUに特化した性能になっているということですが、こないだの僕の記事ではありませんが、キックに100usecかかってちゃあGPUに処理をオフロードするとか割と非現実的なのでは、とか思うので、各社は真似をしないようにお願いします。特にSONYさん。
……とはいえ、SONYさんもなんかPS4のアーキテクチャをAMDのAPUのカスタムとして使うとかそういう話も聞こえてきていますので、x86を採用したゲーム機に未来はあるのか、いや、Powerを採用したから未来があるかどうかは知らないけど、という話とかしたいような気がしないでもないですが、これGPGPU AdCの記事なんでやめておきます。
で、なんでここまでこの記事を引っ張ったかというと、
「もう落ちるところまで落ちたしいっそ書初めってことでウケを取ろう」
というのが根底にあります。さぁ山田を罵倒するがよい！！
さて、なんでここまでネタをひっぱったかという言い訳を一つさせていただきたく思います
もともとGPGPU AdCはRadeonの性能をいかにして引っ張り出すかという話をしたいがために始めたのにもかかわらずArrayFireはまだOpenCL版ないしよぉーみたいなところがなきにしもあらず。
だったので、ArrayFireのOpenCL版を座して待つことにしたのであります。ところがどっこい。2013年1月13日公開だっていうので引っ張りまくるか、という風に思ったりしつつ、12月25日の時点ではお茶を濁してViennaCLで7970の性能を確認しようかとしたところ、すでにその数字があってどうしようかなイマココみたいな気持ちです
――というわけで。
宣誓！
やまだは2013年1月は、Radeon HD7970についてあれこれ触るGPGPU AdC(一人)延長戦を行うことをここに誓います！
週に2回更新目指します！(やれよ)
やります。
AMD FXシリーズに関するブロガー勉強会 2.22 YOU CAN (NOT) ADVANCE
お前Advanceって言いたかっただけだろ？(AMDなだけに)
と突っ込まれると何も言えない。GPGPU AdCの合間を縫いつつのFXシリーズの話です。
さて、今日はPiledriver……の話をする前にBulldozerの話を致しましょう。
なぜBulldozerの話？
Piledriverではアーキテクチャに改善が入りました。では、前世代と比べてどれぐらい向上したのでしょうか？
それも実アプリケーションで！
……ベンチマークのためのアプリケーションで性能向上とかはいいやすいんですよ(例:LAPACK, LINPACK)
Intelがﾏｼﾞｷﾞﾚした論文とかもありますし、実際に使用するようなものでどういった性能向上が得られるか、というのが非常に焦点になると思うのです
さて、今回ベンチマークに使用するのはNAS Parallel Benchmarkと、個人的に気にしている分岐予測機構についての結果をメモリたいと思います。
割と数値計算分野でよく扱われるものが含まれているNAS謹製のベンチマークツール。READMEを見るとSGIのスパコンで動かしたりしていた感じがしていて、MIPSか時代の流れを感じるなぁとか思ってみたりします。僕にとってはMIPSというのはPocketPostPetとかWindowsCE機のCPUなんですよね
つーか本当はPARSECかPhoronixを動かそうとしてたんだけどなんか動かなかったからブチ切れながらNAS Parallel benchmarkにしたんですよ。
PARSECはもっと親切になるべき。というかコードメンテするべき。PhoronixはDLに時間かかりすぎるので断念しました。いいツールだとは思います
分岐予測のはなし
たびたびこのブログでは登場するw_o大先生のところからコードを引っ張ってきます
http://int.main.jp/txt/k10/
で使用されたコードですね
(ちなみに、w_o先生がすでに一度Trinityについての記事を書かれていますが、本稿はBulldozer&Piledriverについての比較記事ですんであしからずご了承ください)
さて、Bulldozerでは以下の結果となりました
1,392,146 branch-misses # 4.05% of all branches [84.00%]
3,140,544 branch-misses # 5.59% of all branches [83.56%]
6,342,833 branch-misses # 5.37% of all branches [83.86%]
12,692,306 branch-misses # 5.31% of all branches [83.62%]
25,767,303 branch-misses # 5.24% of all branches [83.50%]
51,348,832 branch-misses # 5.19% of all branches [83.38%]
103,111,451 branch-misses # 5.19% of all branches [83.33%]大体4%から5%の分岐ミスが発生しています
この辺がPiledriverでは改善されているのでしょうか？ 話によると、分岐予測機構は改善されているっぽいとのことですが……
NAS Parallel Benchmarkの話
NAS Parallel Benchmarkとは、は以下のサイトが詳しいです
http://mikilab.doshisha.ac.jp/dia/smpp/01_bench/naspara.html
同志社大学さまありがとう！
先のサイトによれば、NAS Parallel benchmarkは以下のような問題に対するベンチマークが取れます
| EP | 乗算合同法による一様乱数、正規乱数の生成 |
| MG | 簡略化されたマルチグリッド法のカーネル |
| CG | 正値対称な大規模疎行列の最小固有値を求めるための共役勾配法 |
| FT | FFTを用いた３次元偏微分方程式の解法 |
| IS | 大規模整数ソート |
| LU | Synmetric SOR iterationによるCFDアプリケーション |
| SP | Scalar ADI iterationによるCFDアプリケーション |
| BT | 5x5 block size ADI iterationによるCFDアプリケーション |
この中で着目したいのはEPでしょうか。
EPは浮動小数点演算をメインに扱うもの。つまり、Bulldozerに対して天敵ともいえるアプリケーションであるといえます。
今回は、シングルスレッドでFPUを占有した場合、マルチスレッド(4スレッド2モジュール使用)でFPUを奪い合う場合についてみていきたいと思います
条件はclassAです
さて、Time in seconds とMop/s totalを見ていきましょう
Time in seconds
| thread | 1 | 4 |
|---|---|---|
| BT | 125.14 | 86.29 |
| CG | 1.63 | 1.04 |
| EP | 41.64 | 13.29 |
| FT | 6.66 | 3.25 |
| IS | 0.00 | 0.00 |
| LU | 63.81 | 25.60 |
| MG | 2.10 | 1.44 |
| SP | 92.91 | 66.29 |
Mop/s total
| thread | 1 | 4 |
|---|---|---|
| BT | 1344.80 | 1950.23 |
| CG | 919.80 | 1438.39 |
| EP | 12.89 | 40.41 |
| FT | 1071.38 | 2195.13 |
| IS | inf | inf |
| LU | 1869.64 | 4660.85 |
| MG | 1855.61 | 2711.80 |
| SP | 914.93 | 1282.41 |
…あれ、意外にスケールしてる…？
EPを見ると、時間にして41.64->13.29,Mop/sにして12.89->40.41と、割と順当に1/4,x4になっています
スケジューラーがいい感じになっているのかしら？
と疑問に思いながら1スレッドと4スレッドの場合のperf statを取ってみる
$ export OMP_NUM_THREADS=1
$ perf stat ./ep.A
(略)
Performance counter stats for './ep.A':
42024.027852 task-clock # 0.998 CPUs utilized
4,382 context-switches # 0.104 K/sec
0 CPU-migrations # 0.000 K/sec
481 page-faults # 0.011 K/sec
155,874,426,498 cycles # 3.709 GHz [83.30%]
5,562,831,923 stalled-cycles-frontend # 3.57% frontend cycles idle [83.35%]
115,610,579,562 stalled-cycles-backend # 74.17% backend cycles idle [33.35%]
56,479,019,482 instructions # 0.36 insns per cycle
# 2.05 stalled cycles per insn [50.01%]
6,411,166,114 branches # 152.560 M/sec [66.67%]
428,316,636 branch-misses # 6.68% of all branches [83.33%]
42.113603511 seconds time elapsed
$ export OMP_NUM_THREADS=4
$ perf stat ./ep.A
(略)
Performance counter stats for './ep.A':
46960.709766 task-clock # 3.957 CPUs utilized
4,960 context-switches # 0.106 K/sec
5 CPU-migrations # 0.000 K/sec
844 page-faults # 0.018 K/sec
169,874,912,351 cycles # 3.617 GHz [83.29%]
4,432,542,175 stalled-cycles-frontend # 2.61% frontend cycles idle [83.35%]
54,275,223,099 stalled-cycles-backend # 31.95% backend cycles idle [33.36%]
56,655,235,438 instructions # 0.33 insns per cycle
# 0.96 stalled cycles per insn [50.03%]
6,411,949,722 branches # 136.539 M/sec [66.67%]
431,403,520 branch-misses # 6.73% of all branches [83.33%]
11.866363016 seconds time elapsed順等か…？
EPが4倍になっているのに対して、4倍になっていないものがCGとかMGとかですね
（クロックがかわっているのはBIOSで止めろよとか思われそうですね）
だとすると、コレは完全にFPUがネックで詰まっているのだと考えられます
PiledriverではFPUのスケジューラが改善されているということですので、この辺りの変化があると考えられます
では、次はPiledriverを見ていくことにしましょう
くみ上げレポートとかも待っててNE!!
