つっても、非公開のを別につけているわけではない。
Copyright 1999- Jun Makino
2009/08 2009/07 2009/06 2009/05 2009/04 2009/03 2009/02 2009/01当面の予定
This is the meat part you always want to read fist. So, here it how it goes:本当なら GPU じゃない何か別のものだな。
- 3.0 billion transistors
- 40nm TSMC
- 384-bit memory interface
- 512 shader cores [renamed into CUDA Cores]
- 32 CUDA cores per Shader Cluster
- 1MB L1 cache memory [divided into 16KB Cache - Shared Memory]
- 768KB L2 unified cache memory
- Up to 6GB GDDR5 memory
- Half Speed IEEE 754 Double Precision
さらにお返事いただく。さすがにプロな人はすごい。
- えーと、いまのところ HPL の乱数生成部を使ってないので、、、
- C99の（もともと gcc拡張？）多次元配列は Fortran の配列と同様に使えるとおもってましたが、違うんでしたっけ？すみません、よくわかってません、、、
- こちらでやっているのは TRSM そのものの再帰ではなくてなんだか変なものですが、使っている範囲 (K=2048から 512まで再帰、そこで停止）では大丈夫なようです。
- ありがとうございます。使ってみます。
- これはこの辺を実験してみるのが今回の目的で、現在のところ、再帰的パネル分解の途中で row major から column major に戻す、という実装で、（他もそうとういじったあとですが）HPL をそのまま使うより 10% 程度速くできています。これは、あくまでも GRAPE-DR を使って K=2048 の DGEMM だけが速くなる、という時にどうするのが最適か、という話で、普通の計算機ではあまり関係ないです。あと、並列化するとどうせここは通信に隠れるのであまり関係なかったような気がしてます、、、1ノードでの性能、というのではそれなりに違いがでました。
- ありがとうございます。実際に使うのは Nehalem なので、、、
- はい、そのへん HPL と違うことをしているわけではなくて、パネル分解にだけ再帰を使っています。GRAPE-DR が K=2048 で初めてピークがでるという代物なので、ブロックサイズを2048 にすることが絶対条件ですので、、、
3. さすがですね。はい、そのとおりで、 1/4 になるのですが、元が 1TF (いや、まだそこまでいってないのですが、、、）なので 1/4 になっても Nehalem でやるよりずっと速くて、こっちのほうがまし、ということです。5.7 はい、パネル分解についても、k=1024, 512 は GRAPE-DR をつかう、256、128 はチューニングのできと、CPU と GRAPE-DR での並行処理がどれくらいうまくいくかで CPU を使うか GRAPE-DR を使うかを考える、という感じです。なので、k=256 ないし 128 のパネル分解を、これはもう GRAPE-DR を使わないで CPU だけで、可能な限り速くしたい、というような話です。でも、ここは k が小さいと遅くなる、というのはそうなのですが、それでも他に良い方法があるわけでもないのでは、、、あれば是非採用したいです。
はい、GRAPE-DR の場合はなにしろ DGEMM 「だけ」が普通の 20倍くらい速くなるので、行交換と TRSM の部分が普通より20倍大きく見えるという恐ろしいことがおきます。さらに k=2048 を使いたいとかいうことがあるので TRSM の計算量が普通の場合より桁違いに増えてまして、、、この部分も なんとかしてGRAPE-DR を使う、というのが必須になっています。
行交換についてもそのとおりで、なので row major も使ってみるとかいった普通ではないことをテストしてみています。
The parallel code[23] that we have developedとあるので ref 23 ってなんだろうと思ってみると:
Makino J (2004)それは私が書いたものでしょうか？みたいな。
例えば、04年6月に地球シミュレータを抜いてトップに立ったIBMの「Blue Gene」は、31ビットPOWERPC604の組み込み型プロセッサを搭載し、70テラFLOPSをたたき出した。しかしFORTRANやC言語が使えず、31ビットってなんだろう？とか、 PowerPC 「604」っていつの話だっけ、とか、 大体 604 は組み込み型じゃないし、何をどう間違えるとこんなことが。BG/L は組み込み、というか IP で提供している 440コアに浮動小数点を強化して、 メモリインターフェースとか通信インターフェースもつけた特製プロセッサ。
でも、ちゃんと Fortran も C も動く。性能出すにはアセンブラを、とかある と思うけどそんなのは x86 だって同じだ。 「コンピュータ産業を35年間ウォッチし続けており、メインフレーマの経営・ 技術・営業戦略に精通している。」人の記事なんだそうで。まあ、メインフレー ムのことにはきっと精通しているんでしょう。
後藤さま
コメントありがとうございます。
上の 0.7Gflops というのは１スレッドで測定していますが、上の見積りにはいってない要因（私の使いかたが想定外だということですが）として、 A が行優先、つまり、
double a[2048][2056];
から 0--2047, i--i+7 の領域を切り出してきている（Cも同様に行優先）ということがあって、TLB ミス等の影響がでているようです（列優先の場合には２倍以上速くなっていたので）。HugeTLB を使えばいくらかは改善しますが、あまり大きくはなかったです。何故 K=N=8 で行優先なんていう阿呆な使いかたをするかというのにはいろいろ事情がありまして、、、
官民共同で開発中の次世代スーパーコンピューター（スパコン）計画で、国が投入する総事業費が当初予定の１１５４億円から７６億円増の１２３０億円に膨らむことが文部科学省の来年度予算の概算要求で明らかになった。民間側の主体だったＮＥＣなどが今春、離脱したことなどの影響という。０６年度から理化学研究所、富士通、ＮＥＣ、日立製作所が共同で開発を開始。今春、ＮＥＣと日立が業績悪化で離脱。２社が担当していたシステムが製作できなくなり、ハードウエアの変更が必要になった。うーん、、、