LINPACK と LAPACK

注意:
コメント欄を参照下さい。私の経験不足から『出鱈目』という称号を頂き、鉄槌攻撃を受けました。
記事はここに残しておきます。コメントも残しておきます。信じるか、信じないか?個人の口コミです。多くの人にとって都市伝説と同レベルなのかもしれませんね。

この記事に関連する実証データを御存知でしたら、コメントなど頂けますと幸いです。
色々なケースが有るかと思いますが、非常に興味が有ります。


追記:
Bulldozerが同世代のIntel CPUよりも演算性能で上というエビデンスを書いてみます。


Opteron 6282 SE (2011/11)
 8 FLOPS@Clock × 3.0GHz@TB(TC) × 8モジュール = 192.0 GFLOPS
Opteron 6284 SE (2012/06)
 8 FLOPS@Clock × 3.1GHz@TB(TC) × 8モジュール = 198.4 GFLOPS
※Bulldozerは128Bit演算機を1/2クロックで実行出来る為、2同時演算×2演算機×2回@Clock=8FLOPS@Clockとなる。
※8モジュールを8コアで稼働させると上記より更に1割程TBクロックが上昇します。

XEON E7-8870 (2011/04)
 4 FLOPS/Clock × 2.533GHz@TB × 10コア = 101.3 GFLOPS
XEON E5-2690 (2012/03)
 8 FLOPS/Clock × 3.1GHz@TB × 8コア = 198.4 GFLOPS
XEON E5-4650 (2012/05)
 8 FLOPS/Clock × 2.9GHz@TB × 8コア = 185.6 GFLOPS
※HyperThreadを使うとAVXのピーク性能は低下する為、HyperThreadをOFFにして完全な物理コアで実行する必要があります。

この様に、同世代のトップエンドCPU同士を比較しますと、理論値では同等で、TBの効果次第で順位が入れ替わる程度に拮抗しています。

上に掲載した数値は理論値ですが、Intelの場合は演算機の構造がFADDとFMULで加算と乗算に特化した演算機を1個づつ同時並列に実行可能です。つまり、加算と乗算の演算回数が同数の場合に理論値に近い性能を出せます。
しかしBulldozerはFMACという汎用演算機を2個持っている為、加算と乗算の演算回数が同数でなくとも理論値に近い性能を出せます。

LINPACKベンチマークは、加算と乗算を同数実行する為、Intelの演算機の構造でも理論値に近い性能が出ます。しかし、加算と乗算の演算回数がどちらかに偏っている場合、といいますかLINPACKベンチマーク以外の汎用的な演算を行った場合はBulldozerの方が理論値に近い演算性能が出せるという訳です。普通の汎用的な演算で加算と乗算を同時に同数何時間も実行し続けるでしょうか?それはとてもレアなケースで、その様な場合のみ理論値に近い性能が出せるのがIntelのCPUです。

Bulldozerのこういった性能はFMA4により効率良く引き出す事が出来る様です。BulldozerがFMA4を実装している理由はこちらを見ると判りますが、Intelが途中で仕様変更を行った為、それに右往左往させられ無駄な労力を強いられているであろう事が容易に伝わってきます。

この状況にAMDは当然不満を持ったと思いますが、一般的なメディアで報道されたでしょうか?少なくとも私は、そういった報道を知りません。

大学などの研究者の中に、これに気付いた人々が居て根本原因であるLINPACKベンチマークに疑問を呈した様です。

その2年後、2013年にLAPACKを使ったベンチマークのHPCGという物がようやく登場し2014年以降の計測値が公開されています。が、このHPCGが登場するタイミングに合わせる様にIntelはソケット互換のXEON E5-2697 v2を2013年9月に発売し 12コア 3GHz@TB に強化しています。しかし AMDはSteamroller版のトップエンドOpteronやコア数増加したOpteronを発売する事無く沈黙しました。GLOBALFOUNDRIESやTSMCなどのファウンドリが製造プロセスの微細化でIntelに遅れをとっている為、AMDがコア数を増やせないという側面も有ると思いますが、AMDがGLOBALFOUNDRIESを分社化し売却せざるを得なくなった2009年に何が起きていたかを見ると、政治的な物が見え隠れしていると思います。これは氷山の一角でしょう。我々が普段知らない所で企業は政治的な圧力をIntelにかけられているといった情報は、TV局のディレクターなどから実際にいくつか耳にした経験が有ります。

参考までに・・・
筆者がBulldozerを購入した3年前にOpenCLを使って実測した結果へのリンクも貼っておきます。3年前の事なので自分でも忘れてましたが、赤字は実測値を元にした推測値ですが順当な結果だと思います。この様にBulldozerは同世代のIntelのCPUよりも演算性能が本来は高いのです。

-----以下、元々の本文です-----

LINPACKLAPACKに付いて・・・

LINPACK
 TVニュースでも時々取り上げられていますから知名度が高いと思います。元は演算ライブラリの名称ですが、そのライブラリを使ったサンプルプログラムをベンチマークの代わりに使ったのが起源で、今ではスパコンのTOP500を決める指標です。
 BLAS (Basic Linear Algebra Subprograms) を元にした演算ライブラリですから、Linear Algebra Package の略なのだと思われます(推測)。しかし略し方が頭文字をとってLASとするのではなくLINとしている所が興味深いです。
 歴史は古く1970年代のスパコンで採用されたのが最初らしく、パソコンのCPUで言えばi8086の時代に出来た物で、それ以降の歴代のIntel製CPUはLINPACK向けであるかの様に8087の統合に始まりSMP -> MMX -> SSE -> マルチコア化 -> NUMA -> AVXと拡張してきました。実際、SSEやAVXの演算機(加算機と乗算機の数や並列動作の為のパイプライン構造など)を詳しく調べるとLINPACKベンチマークの為だけに創られたかの様に最適化されている事が判りますし、LINPACKベンチマークを実行するとSSEやAVXの演算機がほぼ100%フル稼働し、多コアMP環境でも全コア100%の負荷に成りパイプラインもフル稼働しますから、逆に言えばLINPACKベンチマーク向けに最適化されていなければ100%近い利用率には成り得ない訳です。
 そしてi8086が登場し活躍し始めた1970年代当時からスパコンの指標とされていますが、スパコンでの実際の用途では多くが後述のLAPACKに置き換わっている様で、実態としてはLINPACKライブラリはベンチマーク専用ライブラリと言えるのかもしれません。
 しかし不思議な事にLAPACKベンチマークでGoogle検索しますとLINPACKに置換された検索結果しか表示されません。Google検索では、ご存知の通りGoogleにを渡せば検索結果を変更出来ますからIntelが情報操作している事は明らかでしょう。試してみると判りますがGoogle検索を使ってLAPACKのベンチマークソフトに到達する事は非現実的な程に困難です。

LAPACK
 LINPACKと同様にLinear Algebra Package の略です。 ちゃんと頭文字を使っているのでLINPACKよりは略し方が自然ですよね?
 歴史的にはLINPACKより新しく1992年に初版が登場し、パソコンのCPUで言えば Am29000 というAMD初のCPUが登場した時代で、パソコンの世界では未だAMDの知名度はそれほど高くはありませんでした。
 しかしLAPACKの演算ライブラリは実際の用途ではLINPACKより洗練され使いやすく、今ではLINPACKは使われておらずLAPACKが使われている(Wiki情報)とされています。
 AMDの3DNow!に付いては判りませんが、少なくともBulldozerに搭載されたFMA4はLAPACK向けに最適化されている様でLAPACKを使ったベンチマークを実行するとBulldozerは同世代のIntelに勝る様です。

結論というか大人の事情、政治力
 もしスパコンのTOP500を決める指標がLINPACK ではなく LAPACK であったなら、AMDのBulldozer系CPUは今よりも圧倒的に売れていたのかもしれません。というかLINPACKベンチマークという非常に特殊で現実には滅多に使われない様な演算のみを繰り返し行うベンチマークだけがTOP500を決める指標に成っているというのも考えてみればとても不思議ですよね?実際、この事実をマスコミは殆ど報道しませんが、LINPACKを開発した本人さえ1970年代に作られた単なるサンプルプログラムをいつまでもTOP500の唯一の指標にしている事に疑問を感じ問題提起しているらしいです。
 と言いますか、こんな事を書いてると、私のブログもGoogle検索から除かれてしまったり改変されてしまうかもしれませんね!?

 筆者としては、LINPACKLAPACK のベンチマーク結果を両方並べて見てみたいものです。というか、ほんとのところ、どうなん?というのを知りたいですね。自分でやってみようかな・・・同じ問題を解くのに、どちらのライブラリが優れているか?という基本的な部分は無視されて1970年代の古いライブラリのたった一つのサンプルプログラムを使ったベンチマークだけがTOP500を決定するのは不思議過ぎます・・・

 同様の事は、OpenCLランタイムでも感じました。といいますか、IntelのOpenCLランタイムはIntelのCPUでしか動作しない様にチェックする仕組みになっていますが、AMDのOpenCLランタイムはx86-64のCPUならば、IntelでもVIA nanoでさえも動作しました。
関連記事
スポンサーサイト

コメントの投稿

非公開コメント

No title

>  AMDの3DNow!に付いては判りませんが、少なくともBulldozerに
> 搭載されたFMA4はLAPACK向けに最適化されている様でLAPACKを
> 使ったベンチマークを実行するとBulldozerは同世代のIntelに勝る様です。

実際に「勝る」というのなら比較データを提示しなければなりませんが、
そんなものは提示されておりません。
何を根拠にそんなことを言っているのでしょうか?


Intelが政治的な圧力をかけたというのも根拠に乏しいですね。
Pentium 4 Xeonの時代まで、Top500スパコンにおけるx86プロセッサは
全くといっていいほど存在感のないものだったことはご存知でしょうか?
Top500のランキングの変遷を見ればわかりますが、Intelがスパコンにおけるシェアを
拡大したのは2000年代に入ってからです。

LINPACKによるスパコンランキングの支配は、それこそベクトル型スパコンの支配力が
大きかったころから既に既に確立していたものです。


IntelがLAPACKが苦手であるという根拠もありません。
Math Kernel LibraryはLAPACKをもとにしており、ポストLINPACKとして有力な
共役勾配法にも最適化されております。

http://www.tekwind.co.jp/_img/product/category/intel/reseller_prodpage_mkl_and_mkl_cluster_edition.pdf

つまり、あなたの書いたことは全くの出鱈目です。

Re: No title

出鱈目記事に鉄槌をさん、コメント有難う御座います。

色んな意味で、とても勉強になります。

> >  AMDの3DNow!に付いては判りませんが、少なくともBulldozerに
> > 搭載されたFMA4はLAPACK向けに最適化されている様でLAPACKを
> > 使ったベンチマークを実行するとBulldozerは同世代のIntelに勝る様です。
>
> 実際に「勝る」というのなら比較データを提示しなければなりませんが、
> そんなものは提示されておりません。
> 何を根拠にそんなことを言っているのでしょうか?

実際にLAPACKを使っている大学の研究生から伺いました。
技術論文とは異なり、趣味の個人ブログですが、比較データを提示する義務が有るのでしょうか?もしそのような事が実際に必要でしたら御教授下さい。

残念ながら、技術資料をこちらから提示する事は現時点では出来ませんが、Web検索しますとFMA4に関するデータをいくつか見付ける事が出来ると思います。時間に余裕が有れば自分で検証してみたい事柄でもあります。
しかし、AMDはBulldozerアーキテクチャとは全く異なるZenへと来年移行する予定ですので、仮にやったとしても私の検証が終わった頃にはZenが登場しているでしょう。

Intelが配布しているIntelのCPU向けに最適化されているIntel Optimized LINPACKを試した時の記事を、以前掲載した事が御座います。
http://dualsocketworld.blog134.fc2.com/blog-entry-335.html

この際に、FMA4(SSE5)に対する最適化や、IntelのCPUでもHyperThreadでLINPACKを実行すると劇的に遅くなる事と同様の理由でBulldozerのモジュール構造では効率が出ないのですが、この二つに対するチューニングを施して実行するだけの時間的な余裕が無かったのが残念です。

> Intelが政治的な圧力をかけたというのも根拠に乏しいですね。

近年の例では、こういった物があります。
例1:ベンチマークに対する政治的影響力
http://pc.watch.impress.co.jp/docs/column/ubiq/20110624_455363.html
例2:実装ベンダーに対する政治的影響力
http://news.yahoo.co.jp/pickup/120963

マスコミの事については、某テレビ局ディレクターと個人的に居酒屋で話した時に伺った情報ですが、大手スポンサー(つまりテレビ局の収入源)には逆らえないという切実な事情があり、テレビでIntelのマイナスになる事を発言する事は出来ないそうです。

> Pentium 4 Xeonの時代まで、Top500スパコンにおけるx86プロセッサは
> 全くといっていいほど存在感のないものだったことはご存知でしょうか?

はい。
私は、ネトバ世代の初期のXEONからお世話に成っています。
http://dualsocketworld.blog134.fc2.com/blog-entry-69.html

当時は某大手通信業者の2万アクセス@1hなサーバをチューニングする際にネトバのHyperThreadがどの程度効果が有るか?などを調査・検証しながらチューニングしていました。

> LINPACKによるスパコンランキングの支配は、それこそベクトル型スパコンの支配力が
> 大きかったころから既に既に確立していたものです。

そうですね。

> IntelがLAPACKが苦手であるという根拠もありません。

その様に書きましたでしょうか?

> つまり、あなたの書いたことは全くの出鱈目です。

そうかもしれませんし、かなり当たっているかもしれません。

もし、よろしければ、Opteron(InterlagosやAbuDabhi)と同世代のWestmare-EPやSandyBridge-EPを各々実機でそろえて、両者向けにそれぞれ本格的なチューニングを施したLINPACK相当のベンチマークと、類似の演算を行うLAPACKライブラリを使いチューニングを施したベンチマークとを作成・実行して、比較・検証を行ってみては如何でしょうか?その結果を拝見できましたら幸いです。

No title

『でたらめ』というのは『嘘』ではなく、『根拠が無い』とか『いいかげん』といった意味です。

出鱈目記事に鉄槌を氏は「嘘をつくな」とか「Intelの方が速い」と言っているのではありません。「根拠の無いことを言って他者を貶めるな」とか「根拠を示せ」ということを言っているのです。

根拠の無い内容で「そうかもしれませんし、かなり当たっているかもしれません。」というのは出鱈目と言うのですよ。
ご自身の記事が「出鱈目では無い」と言うのでしたら、根拠となるデータ(自分自身で計測ではなく、信頼できる記事の紹介でも可)をご自身で示すべきであり、出鱈目記事に鉄槌を氏に検証してくれと言うのは筋違いです。
出鱈目記事に鉄槌を氏はどちらが速いとかそういうことを言っているのでは無く、あなたの出鱈目な姿勢を批判しているのですから。

Re: No title

> 『でたらめ』というのは『嘘』ではなく、『根拠が無い』とか『いいかげん』といった意味です。

まぁ、そういう意味では、全く根拠が無い訳ではなく、自分なりに個人的に聞いた情報などを口コミ的に書いているのです。ですから、私的には出鱈目で書いてる訳じゃなく、ソースも有るのですが、それは公開できない情報もあるし、大勢の人が見たら出鱈目と感じる記事があるのでしょうね。その点、勉強に成ります。

個人の趣味で書いてるブログと、プロのライターが書いたスポンサーによる偏向報道をするマスコミの情報と、どっちが出鱈目に見えるかと言えば前者(つまり私の記事)の方が出鱈目に見えるでしょうね。ほんと、勉強に成ります。

健康食品関連のシステムを組んだ時に、メディアを使って商品の宣伝やマーケティングをしている現場に立ち会った事が有るのですが、痩せるBefore&Afterの捏造の仕方とか、ほんとにここまでやっていいの?って思うような事をやって、そこにエビデンスという名の嘘を塗り固める為のデータやグラフを追加して事実っぽく偽装してゆくんです。見てると怖いですよ。こんな事を書いても、その事実を証明する手段は有りませんから、これもまた出鱈目コメントとして流れてゆくのかもしれませんね。

信じるか、信じないか、都市伝説みたいですねw

No title

人生経験も豊富でしょうから、ご自分が理解していないものを他人に理解させようとするのが
困難なことは十分おわかりかと思います。
なお主張を曲げる気がないとおっしゃるのであれば、私は容赦なく否定します。


1. Googleが「LAPACK benchmark」を「LINPACK benchmark」に訂正する理由

そもそもLAPACKは、密行列演算に特化したLINPACKよりも広範囲の数値計算をカバーする巨大なパッケージでして、連立一次方程式を解く方法一つとっても、複数のメソッドが用意されております。
HPLの後継として提唱されているCG(Conjugate Gradients; 共役勾配)法は、そのLAPACKに含まれる一部のメソッドにすぎません。
だから「LAPACKのベンチマーク」っていったい何のベンチマークだ?ということになります。
「LINPACKのスペルミスじゃないのか?」というGoogleのcorrectionもある意味妥当なのです。

圧力だなんだとわめく前に、まずLAPACKがどういうパッケージなのかを調べることを覚えてください。そして、「LAPACK benchmark」ではなく「"conjugate gradients" benchmark」で検索してみてください

2. IntelがGoogle検索結果を操作する必要がない理由

上記の私がGoogle検索結果は、このページが上位にヒットしました。
https://software.intel.com/en-us/articles/intel-optimized-technology-preview-for-high-performance-conjugate-gradient-benchmark

HPLに代わるスパコンの性能評価基準としてHPCGへの最適化を全面的にサポートするという内容です。
あなたの理屈では、Intelが圧力をかけて、LINPACKに縛り付けたがってるのでしたよね?


もちろんトップに引っかかるのはHPCGのページです。
http://www.hpcg-benchmark.org/custom/index.html?lid=155&slid=275

Top500とは別に、CG法をもとにしたランキングは既に始まっておりまして、参加数はまだ少ないのですが、Top500でも1位を取った天河2号が圧倒的な物量を駆使してこちらでも1位を獲得、京は2位を獲得しています。
GPGPUやPhiなどのアクセラレータを積んだスパコンが割りを食う結果となっていますが、Xeonオンリーのクラスタが高い効率を発揮しているのがおわかりかと思います。

Top500と同じく、6月と11月のランキングの集計を行っています。
上位は順位に変動はありませんが、いずれもソフト側の最適化でスコアを上げてきていますね。

こちらは理研の発表資料ですが、理論性能あたりの比率も併記しています。
http://www.aics.riken.jp/jp/science/research-highlights/more/hpcg2014.html


9位のマックスプランク研のiDataPlex(演算アクセラレータ無しのXeonクラスタ)に至っては理論性能比の上では、京すら上回っています。
演算粒度の上では、256ビットSIMDのAVXは128ビットのHPC-ACEより理屈上不利であるにもかかわらず、です。
(もちろん、規模が大きくなるほどインターコネクトの負荷が高くなるので、規模が違うものを単純比較することは不毛ではあるのですが)

以上のとおり、アクセラレータを積まないXeonクラスタが軒並み高い理論性能比を出している以上、IntelがCG法を使わせないように圧力をかける理由は無いと見るべきでしょう。


3. 「Bulldozerのほうが性能が高い」という虚構について

Bulldozer(とそのマイナーチェンジのPiledriver)のメモリコントローラはネイティブの4chではなく、2chのメモリコントローラを持つ4モジュール・8コアのダイを
cHTバス接続でMCM化して擬似的に4ch化したもので、ネイティブの4chメモリコントローラを持つSandy Bridge以降のXeonと比べれば、その効率は比べるべくもありません。
HyperTransportやPCIeのバンド幅も、OpteronのそれはXeonと比べてはるかに劣っています。

Top500のほうを見ると、AMD Opteron(Bulldozer世代)オンリーのx86クラスタ100位以内に5つもあるのですが、いずれもHPCGのスコアを登録していません。
CG法によるランキングの都合が悪いのは、むしろ例のAMDのほうではないですか?

例のGreen500で1位をとったというFireProのやつもありません。
あれはLINPACKのスコアを消費電力で割っただけのGREEN500で1位を取るためだけに
それ専用にスペシャルチューンしたという、スパコンの存在意義を否定する
哀れなコンピュータですから、登録しないのは道理です。




CG法について若干解説させていただきます。
LINPACKではただ行列積を繰り返していればいいので、プロセッサが大規模になるほど演算量あたりのメモリ帯域・ノード間通信のコストは相対的に下がります。
(Top500のルールでは、たとえ0.0×0.0+0.0の積和演算であっても演算を省略するための最適化を許しておりません)

一方で、CG法はその行列全体における0.0の部分が大部分を占めており、無駄な部分をいくら
計算しても有効なFLOPS数にカウントされません。
したがって、演算ユニットをリッチにしたからといって、足回りを改善しなければ、スコアが上がるというものではないのです。
これはGPUやXeon PhiなどのPCIe接続のアクセラレータが軒並み振るっていない事実からも
おわかりかと思います。



今一度お尋ねしますが、あなたのその記事の主張は何を根拠にしていますか?

Re: No title

> 1. Googleが「LAPACK benchmark」を「LINPACK benchmark」に訂正する理由

これも、推測であって、ソースが有る訳ではないと思います。
従って、ソースを提示するという意味では難しそうですね。

しかし、ものすごく長文で回答するのには、なかなかエネルギーが要ります。

> だから「LAPACKのベンチマーク」っていったい何のベンチマークだ?ということになります。

それは、マイナーなので、確かにそうかもしれませんね。
LINPACKベンチもライブラリの一部を使ったものですから、そういう意味では同じですが、LINPACKベンチマークという言葉が定着しているという意味で、確かに仰る通りかもしれません。

しかし、これもソースを提示して、これが正しいとするという意味では難しそうですね。

> 2. IntelがGoogle検索結果を操作する必要がない理由
>
> 上記の私がGoogle検索結果は、このページが上位にヒットしました。
> https://software.intel.com/en-us/articles/intel-optimized-technology-preview-for-high-performance-conjugate-gradient-benchmark

これは、私の記事の数日前に改訂された物の様ですね。
私が記事を書いた当時はヒットしなかったのかもしれません。

> 3. 「Bulldozerのほうが性能が高い」という虚構について

FMA4に関する調査ですね。

曲げるつもりは無いという訳ではないのです。

> Bulldozer(とそのマイナーチェンジのPiledriver)のメモリコントローラはネイティブの4chではなく

http://dualsocketworld.blog134.fc2.com/blog-entry-338.html

そうですね。

ちょっと、外出してきますので、追々また改めまして・・・

No title

『個人ブログが出鱈目に見える』なんていう曲解はしないでください。
プロが書いていても信頼できない記事も有れば、個人ブログで信頼できる記事もあります。
単純に、あなたのこの記事が『根拠の無いこと』や『根拠と結論の因果関係が乏しいこと』を平然と書いている事が問題なのです。

例えば
>しかし不思議な事にLAPACKベンチマークでGoogle検索しますとLINPACKに置換された検索結果しか表示されません。Google検索では、ご存知の通りGoogleに金を渡せば検索結果を変更出来ますからIntelが情報操作している事は明らかでしょう。

『LINPACKに置換された検索結果しか表示されない』、『Googleに金を渡せば検索結果を変更出来る』という根拠から『Intelが情報操作している』という結論に何故なるのでしょうか?
『誰も情報操作をしていない』場合でも『Intel以外のどこかが情報操作している』場合でも当てはまります。
推測では無く『明らかでしょう』と断言まで出来る根拠が全くわかりません。

例えば
>それ以降の歴代のIntel製CPUはLINPACK向けであるかの様に8087の統合に始まりSMP -> MMX -> SSE -> マルチコア化 -> NUMA -> AVXと拡張してきました。
・・・以下省略

他社も追随している機能や他社の方が先に実装している機能ばかりですが、同機能を搭載した他社をを含まずにIntelがLINPACKに最適化されている根拠は何でしょうか?

例えば
>LINPACKベンチマークを実行するとSSEやAVXの演算機がほぼ100%フル稼働し・・・以下省略

新命令を搭載しても従来のプログラムが高速化されるわけでは無く、新命令を使ったコードを書かなければいけないわけですが、『ソフトウェアがIntelのCPUに最適化されて100%フル稼働』ではなく『IntelのCPUがLINPACKに最適化されている』とされる根拠は何でしょうか?

Re: No title

見物にきた第3者さん、こんばんは。

出先であんまり、じっくり書けないですが、パイプライン構造やFADD、FMULなどの演算機の構造と構成がLINPACKを実行した際にフル稼働する様な構造(つまりチューニングされている)様です。

演算機の構造がBULLDOZERの場合は128BitのFMACを2個搭載し、これを1モジュール2コアで共有しています。

演算機は、128Bit -> 256Bit -> 512Bit と徐々に拡張されていますが、どのタイミングでIntelのCPUが256Bitになったか失念してしまいました。

http://pc.watch.impress.co.jp/docs/column/kaigai/20090518_168661.html

この記事にあるSSE5として実装される予定だったものがBulldozerの128BitのFMACを効率良く利用出来るはずの命令セットです。

何度か書きましたが 『 Bulldozer FMA4 』のキーワードで検索してみて下さい。

帰宅後に、追々、暇を見つけてまた返事します。

しかし、私もブログだけに時間を割けるわけではないので、必ずしも高レスポンスで返事を書けるとは限りません、中には数ヶ月放置してしまったコメントなどもあると思いますが、その辺りは、御了承下さい。

しかしまぁ、冒頭にも追記しましたが、都市伝説レベルで考えて下さって良いと思います。

Re: No title

> HPLに代わるスパコンの性能評価基準としてHPCGへの最適化を全面的にサポートするという内容です。
> あなたの理屈では、Intelが圧力をかけて、LINPACKに縛り付けたがってるのでしたよね?

HPCGは、たぶん、Bulldozerが正当に評価されてないとして新たに立ち上がったのではないか?と思います。

時系列的には、Bulldozerが2011年で、この頃からFMA4の性能がLINPACKでは生かしきれないとされ、LAPACKによるベンチマークが切望されていたと思います。

HPCGはBulldozerの登場から2年後の2013年頃からの本格稼働じゃないでしょうか?未だ詳しく調べてませんが。

この時期、IntelはAVX用の演算機を256Bitに拡張してFMA4の性能を上回る様に演算機を改良していると思います。

つまり、AVXの演算機が256Bitに拡張されたのとタイミングを同期させる様にHPCGが登場しているとも考えられます。HPCGでBulldozerのFMA4を上回る目的でAVX演算機を256Bitに拡張したと見るのは、偏見かもしれませんが、タイミングとしては、ほぼ一致しているのではないでしょうか?

BulldozerのFMA4が登場したのと同世代は、Intelも演算機が128Bitだったと記憶しています。しかし記憶違いかもしれず、まだそこは明確に出来ていません。

各社のCPU演算機の数とビット数を時系列で並べてみて、そこにHPCGの登場時期を重ねてみると、何かが見えてくるかもしれません。

No title

AMDにTBなんて機能はありません。
似たような機能のTCならありますが。

http://news.yahoo.co.jp/pickup/120963 の記事ですが
http://ascii.jp/elem/000/000/346/346959/
の件の判決が2009年に出たのであって、2009年に何かがあったわけではありません。

Opteron 6284 SE(32nm)は315mm2×2=計630mm2
XEON E5-2690(32nm)は435mm2
Steamroller(28nm)ではIPCを上げるため使用トランジスタ数を増やしたため、ダイサイズは同コア数の32nm世代と同程度。
一方でIvy Bridge(22nm)世代のXeonは10コアで341mm2、15コアで541mm2。
ダイサイズを考えるとXeonに対抗出来るコア数の製品なんて出せるわけがありません。

あと、これは単純に疑問なのですが・・・
AMDは知りませんがIntelの場合『A=A×B+C』のレイテンシは下記の通りです
Sandy Bridge:8サイクル(乗算5+加算3)
Haswell:5サイクル(乗算5、加算3の同時実行)
加算・乗算どちらも出来る汎用演算器にしたらもっとかかるでしょう。
また、『PMD_MT 高速化版』というAVIUtlのプラグインフィルタの作者によると、Steamroller(A10-7850K)ではFMA4を使うよりFMA3を使う方が速かったという報告もあります。
FMA4を最初に言い出した(けど結局FMA3にした)のはIntelだというのに、未だにFMA4対応製品は発表されていません。
AMDもZenではFMA4非対応との噂も出ています。
実アプリではFMA4の方が本当に速いのですか?

Re: No title

> AMDにTBなんて機能はありません。
> 似たような機能のTCならありますが。

ご指摘ありがとうございます。
TCの認知度が低いのではないかと思い、あえてTBと書いた方が読者総体として見た場合に伝わりやすいという筆者の推測の元にTBと書いています。が、今後同様の指摘を頂きかねませんのでTB(TC)という記載に変更させて頂きました。

> http://news.yahoo.co.jp/pickup/120963 の記事ですが
> http://ascii.jp/elem/000/000/346/346959/
> の件の判決が2009年に出たのであって、2009年に何かがあったわけではありません。

その通りです。
当然、何年も前から当該行為が行われていたわけであって、その瞬間の出来事ではありません。
同様に、Fabを売却するに到る過程も、当然ですが瞬間的に決まる訳ではなく、何年も前からの積み重ねの結果なのです。
もう少し広げて考えれば、CPUの発売も同様に、企画、設計、試作、テスト、販促、量産、販売と長期スケジュールで完成するのであって、発売日に突然完成した訳ではありません。

しかし、そういった結果に到る経緯を解説する場ではないと思いましたので、あえて書いていません。

> Steamroller(28nm)ではIPCを上げるため使用トランジスタ数を増やしたため、ダイサイズは同コア数の32nm世代と同程度。
> 一方でIvy Bridge(22nm)世代のXeonは10コアで341mm2、15コアで541mm2。
> ダイサイズを考えるとXeonに対抗出来るコア数の製品なんて出せるわけがありません。

その様に書いたつもりです。
「GLOBALFOUNDRIESやTSMCなどのファウンドリが製造プロセスの微細化でIntelに遅れをとっている為、AMDがコア数を増やせない」の記述がそれです。

> あと、これは単純に疑問なのですが・・・
> AMDは知りませんがIntelの場合『A=A×B+C』のレイテンシは下記の通りです
> Sandy Bridge:8サイクル(乗算5+加算3)
> Haswell:5サイクル(乗算5、加算3の同時実行)
> 加算・乗算どちらも出来る汎用演算器にしたらもっとかかるでしょう。

汎用演算機にするとレイテンシ(つまりパイプライン段数/クロックサイクル)が増えると思うのは何故でしょう?

FMA3よりもFMA4の方がオペランドが多いのでレイテンシが増える(方が実装しやすい)というなら判りますが、汎用演算機にしたが為に、それがすなわちレイテンシ増加につながるというのが、いまひとつ判りません。解説して頂けると助かります。

> また、『PMD_MT 高速化版』というAVIUtlのプラグインフィルタの作者によると、Steamroller(A10-7850K)ではFMA4を使うよりFMA3を使う方が速かったという報告もあります。

ある意味では当然です。
FMA4は4オペランド、FMA3は3オペランドで、関数に例えれば引数が4と3の違いが有るので、引数4の方が重たいのです。ですから、FMA3で出来る演算をFMA4でやると少しばかり遅くなるでしょう。とは言え、倍も遅くなる訳ではなく、重たい分(L2の占有率などが変わる為)僅かな差ではないかと思います。

しかし、元々FMA4向けに組まれた演算ロジックや、FMA4向きの演算ロジックをFMA3で置き換えた場合は、FMA3の方が最大で倍近く遅いと思います。

構造的に、そうなるでしょう。

> FMA4を最初に言い出した(けど結局FMA3にした)のはIntelだというのに、未だにFMA4対応製品は発表されていません。

論理的にはFMA4の方が有利でも、物理実装が難しいからだと、どこかに書いてありましたね。
難しい実装を行ったわりに、LINPACKベンチマークでは効果が出ないのであれば、ビジネスとしてどうか?と考えた場合、株主や経営陣がどういった判断をするか?と考えれば、ある意味では当然だと思います。

> AMDもZenではFMA4非対応との噂も出ています。

Zenで全く実装しないのか、それとも下位互換目的でエミュレーション(つまり動作はするが、遅い実装)にするか、それともやっぱり本格的に実装しちゃうか、それは未だ製品版が世に登場していないので、なんともですね・・・

> 実アプリではFMA4の方が本当に速いのですか?

それは、本文に書きました通りです。

それに、そもそもFMA4バイナリを適切に吐けるコンパイラでコンパイルするか、アセンブラで記述するかしてなきゃ駄目ですよ?

No title

>しかし、元々FMA4向けに組まれた演算ロジックや、FMA4向きの演算ロジックをFMA3で置き換えた場合は、FMA3の方が最大で倍近く遅いと思います。

えっ!?
FMA3とFMA4は扱う元データ数も演算回数も同じですよね?
FMA3だとレジスタ内のデータを1つ破壊するから退避が必要になる場合が有るだけですよね?

蛇足:FMA3ってIntelはHaswellからの対応だった気がする。

Re: No title

> えっ!?
> FMA3とFMA4は扱う元データ数も演算回数も同じですよね?
> FMA3だとレジスタ内のデータを1つ破壊するから退避が必要になる場合が有るだけですよね?

そうですね。
退避する先のレジスタが埋まっていれば、メモリに退避しないといけないかもしれません。
色々なケースがあると思いますし、他の命令で代用出来る場合もあるでしょうから、必ず倍かかるとは思いませんし、早朝の眠い時間ですから雑談レベルでかなり適当に書いてますけどね。

> 蛇足:FMA3ってIntelはHaswellからの対応だった気がする。

それはFMA4では?

Re: Re: No title

X = A x B + C を演算する場合

FMA3だと
X = A
X = X x B + C
という2段階の処理になりますね、たぶん

FMA4だと
X = A x B + C
を1回実行するだけで済みそうです

メモリに退避する必要はないのかもですね

しかし、上記のFMA3動作だとフェッチを2回実行しないとなので、やっぱり倍かかるんじゃないでしょうか?

No title

>退避する先のレジスタが埋まっていれば、メモリに退避しないといけないかもしれません。
素人考えでの質問で申し訳ないですが、FMA3+(4つめのレジスタに)退避でもFMA4でもレジスタを4つ使うわけですから、(4つめのレジスタ内容を)メモリに退避する必要がある状況ならFMA4の場合でも(4つめのレジスタ内容を)同じように退避させる必要があるのでは?
レジスタ間退避が追加されたくらいで処理時間が2倍になるのでしょうか?

>それはFMA4では?
???
前のコメントでFMA4非対応を肯定しいたと思うのですが?
実際のところ、FMA4に対応したIntel製x86CPUなんて現存しません。(HaswellどころかBroadwellも非対応です)
FMA3はHaswellからの対応なので実はAMDの方が先に実装されていたわけです。(私は、AMDはSteamrollerから対応でIntelの方が先に実装したと勘違いしていましたが)

Re: No title

> レジスタ間退避が追加されたくらいで処理時間が2倍になるのでしょうか?

仮に、レジスタ間コピーと、FMA3演算、それぞれ個別に専用パイプラインがあり、フェッチ-デコード-エクゼキューションと続く一連の流れを互いに干渉されず並列動作可能であれば、FMA4と等速で実行出来そうです。というか、そんな構造だったかも?

しかし、その場合でも、もう一つレジスタ間コピーや類似の命令を実行したい場合を想定すると・・・結局、パイプラインに競合が起きるので遅くなると思います。要は同時に使えるリソースの数と、その実行に必要なクロックサイクル数で決まると思うのです。あとまぁ、メモリ上のサイズでしょうかね。

というか、Bulldozer、Westmare-EP、SandyBridge-EP、3種とも実機を持っているので試してみればよいだけなんですが、そういう気分に成れず、こうして脳内仮想CPUを使って不確かな記憶とともに回答してるのです。

> >それはFMA4では?
> ???
> 前のコメントでFMA4非対応を肯定しいたと思うのですが?
> 実際のところ、FMA4に対応したIntel製x86CPUなんて現存しません。

この記事で書いているのは、あくまでBulldozerと同世代のIntelのCPUの事なので、ブログ趣旨としてはWestmare-EP(EX)またはSandyBridge-EPという事に成ります。

> FMA3はHaswellからの対応なので

それは知りませんでした。
後ほどIntelから機械語命令リファレンスでも探してみます。
(リファレンスを見ていたら、やる気が出てくるかもしれませんしね!?)

では、なおさらFMA4を搭載しているBulldozer(具体的にはInterlagos)の方が同世代のIntelのCPU(Westmare-EP(EX)やSandyBridge-EP)よりもベクトル演算が早そうですね?

今まで仕事でも、このブログでも、チューニングというものを幾度となく経験してきた経験から述べますと、時間かけてチューニングすると、どんどん早くなります。
Javaで書かれた画像処理をチューニングして20倍早くした事もあります。同じロジックでも、ちょっとした工夫で早くなったりします。

結局、最終的に『早い』ってどういう事?かと言えば、曖昧ですよ。
逆に、遅いのはチューニング不足とか、プログラミングが下手とか、ダウンタイムを減らす事を優先して遅くなったりとか、偶然が重なったりとか、色々あります。
CPUの性能を100%引き出す事は不可能ですから、ベンチマークの作り方次第で早い遅いが簡単に入れ替わったりもするのです。
プロフィール

DualSocketTheWorld

Author:DualSocketTheWorld
自作を始めて20台目くらいになりますが、最初からデュアルソケット限定(始めた当時はデュアルスロット)で自作しており、近年になってAMD K6を試したくなりSocket7でK6-2+のシングル構成で組んだのがシングル初です。

シングルマザー(含:シングルソケットマルチコア)や4ソケット以上の自作は基本的にしませんし、メーカー製PCの改造も基本的にはしません(ノートPCのSSD化くらいはしますが・・・)

基本路線はワークステーションと呼ばれる分野での自作で、OSもWindows系であればProfesionalが主な対象に成ります。

ゲーマーの様なOverClockは行わず、WS路線としてハイエンドCPUとハイエンドGPUの組み合わせで定格或いはDownClockで発熱を抑えつつ、その時のアーキテクチャに置いて爆速かつ静音を目指し、30年以上の長期に渡り稼動状態をキープする事を目指します。

※基本的にリンクフリーです。どこでも自由にどうぞ。

※画像は時々変ります。

※お決まりの文章ですが、改造は個人の責任で行ってください。ここに記載された情報は間違いを含んでいる可能性が有り、それを元に製作や改造などをして失敗しても筆者は一切責任持てませんので悪しからず。

筆者略歴:
小学生時代にゴミ捨て場で拾ったジャンクテレビ数台を分解して部品を取り出し真空管アンプを自作、中学生時代にPC8801mkⅡsrでZ80アセンブラを始める。社会人になって初のプログラムは弾道計算、後に医療系・金融系プログラマ~SEを経て100~200人規模プロジェクトのジェネラルマネジャを数年経験、独立して起業。現在は不動産所得で半引退生活。
(人物特定を避ける目的で一部経歴を変更しています)

最新記事
最新コメント
最新トラックバック
月別アーカイブ
カテゴリ
アクセスカウンター
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR