Pravdaの日記： 次期地球シミュレータ 8
日経IT Proの記事、NECが次期地球シミュレータを190億円で落札、世界1位は狙えず [nikkeibp.co.jp] より。
NECは2008年5月12日、独立行政法人の海洋研究開発機構（JAMSTEC）が運用するスーパーコンピュータ「地球シミュレータ」の次期システムを落札したと発表した。同日JAMSTECが入札結果を公開し、6年間のハードウエアのリースと保守・運用費用などで合計190億円となった。
ピーク性能は131TFLOPSだそうですので、1TFLOPS当たり1.45億円。ただし保守運用費込みの値段です。
一方、同じく日経IT Proの記事、富士通がJAXAから110億円でスパコン受注、性能は国内最高に相当 [nikkeibp.co.jp] によると、ピーク性能135TFLOPSに対して、受注額は6年間のリース契約で110億円とか。1TFLOPS当たり0.81億円。まあ、JAMSTECのシステムはベクトル機で、JAXAのはスカラ機ですので単純な比較はできませんけれど。主に実行されるアプリの性質も異なるでしょうし。
ところで、CNET Japanブログの記事、再び、ベクタ・プロセッサは必要か？ [cnet.com] で、能澤徹という人が、なにやら怪しいことを書いています。
マクロ視点では、既に昨年指摘したように、RISC思想の一つである「1命令1サイクル」の敷衍以降、ベクタ機とスカラ機（スーパースカラを含む）の理論性能算定上の差異はなくなり、構造的な違いとしては、シーモア・クレイが考案したベクタ機の「巨大なレジスタ・ファイル」と、C. コンティとD. ギブソンがS/360-モデル85用に考案した「キャッシュ・メモリ」の違いが挙げられる程度なのである。
言い換えると、「（大量の高速レジスタ）＋通常メモリ」か、「（限定量の高速レジスタ＋大量の高速キャッシュ）＋通常メモリ」か、の違いということである。しかし、マクロ視点からは、（）の中は一体と考えられるので、論理的には大きな違いはないということになり、それ程大きな実行性能の差異が生ずるとは考え難いのである。
勿論この構造的差異がプログラミングに大きな影響を与えているわけではあるが、アーキテクチャに適したプログラミングをすれば、大きな性能の差異は発生しないと考えられるということなのである。
マトモな計算機アーキテクチャの本を読めば、ベクトル機は１命令で複数データを処理する“SIMD”に最適化された構造で、大量のデータをCPU－メモリ間でやりとりするためのロード／ストア・パイプラインが装備されていることが書かれているはず。ベクトル・レジスタとキャッシュ・メモリに「大きな違いはない」とは、アーキ屋さんが聞いたら憤死しそうな論であります。
そこまで言うなら、能澤徹氏が国から10億円ほど頂戴して、ベクトル機用アプリをスカラ機に移植すれば良いんじゃないでしょうか。ただし性能は同等、計算結果は同一を保証という条件で。あたしゃ万一そんな仕事が降ってきたら、どんなに汚い手を使ってでも逃げますけどね。
また、論拠になっている“Lattice Boltzmann Simulation Optimization on Leading Multicore Platforms”[crd.lbl.gov] という論文も、計算規模が小さ過ぎて、このデータでTOP500に入るようなシステムについて議論するには不適切。現在のAMD OpteronやIntelのCore 2 Quadは、４コアだと「それなり」にCPU－メモリ間のバンド幅性能とバランスがとれているように見えますが、８コアとかになると、今のSun Niagara2システムみたく、DIMMを４枚１組とか８枚１組でインターリーブ数を増やさないと、バンド幅が足りなくなるような気がするのですけど、どんなもんでしょう。
能澤徹というお方 (スコア:0)
スパコンは専門外ですね。別に「経歴外のことを話すな」とは言いませんが、
「簡単にボロが出る話をされたら白けるよね？」というところでしょうか。
不勉強すぎると。
Re:能澤徹というお方 (スコア:1)
コンピュータの歴史も半世紀くらいたちますが、ことトップクラスのマシンに関しては、CPU－メモリ間のバンド幅をいかに広げるか、メモリのアクセスレイテンシをいかに見えなくするかの歴史でもあったワケですよね。
まだ「近年の大規模システムではノード間通信のレイテンシを隠蔽できないので、各ノードはベクトル機でなくともスカラ機で充分」と書けば、モットモらしく読めるんですけど。能澤徹というお方、実に不勉強というか、根本的に分かってないというか…。
GRAPE開発で有名な牧野淳一郎氏が、公開用日記 [artcompsci.org] で、「１億円当たりのメモリバンド幅」を書かれていますね。そういう点をふまえて、次世代スーパーコンピュータ概念設計評価報告書 [nao.ac.jp] の記事でベクトル機のコスト・パフォーマンスの悪さを指摘されていますが、ハードウェアだけの話というウラミがあるものの、非常に説得力があります。
まあ、牧野先生といえば、ゴードン・ベル賞を３回も受賞した世界的なアーキテクトですので、能澤氏などと比較したら失礼にあたるのでしょうけど。;-)
次期地球シミュレータ (スコア:0)
2.今日のCPUには巨大なキャッシュまたは巨大なレジスタ・ファイルがあるわけで、単純なBusのBandwidthと主メモリだけからB/Fを考えても意味はないでしょう。
現実に問題になるのは、メモリ・バンクのコンテンションとかレイテンシなど、Bandwidthだけでは計れないものですよ。
因みに、高B/Fが必要なのは,Linpackのようなアプリケーションで、Linapckの実行性能比が高ければ、B/Fはあまり問題にはならないと思います。勿論、B/Fは同じアプリケーションを書いてもプログラミングの良し悪しにより大きく左右されますので、この場合は「良い方」を想定しての事ではありますが。
3.Dr. FlynnがCPUのアーキテクチャをSIMDとかMIMDとかに分類したのはS/360－Model91などを設計していた頃の話で、彼の頭の中にあったのは、MIMDのIlliac-IVとかSIMDのTI-ASCのようなものであったと思っています。TI-ASCは、CDC-7600のPipelineと合わさって、メモリ・ベースのベクタ機CDC－STAR、レジスタ・ベースのベクタ機CRAY-1となりますが、命令のFetch以外にデータ処理をもPipelineで行い、１データ1サイクル（ベクタ命令を含めると1命令1サイクル）の処理を目指したものです。SXはこの系列に属します。
これは70年代初期に Dr. J. Cocke等が考えたIBM801での1命令1サイクルのRISK処理思想と同じです。対象になるデータがFPなのか普通のデータなのかの違いです。今日ではRISCはCISCに吸収されてしまった感がありますが、Powerにしろ、x86にしろ、対象データはFPをも含んで、1命令1サイクルと言う事です。
LD/STのアーキテクチャはSeymour CrayがCDC6600で始めたもので、CDC6600はRISK/スーパースカラの系列に属すると考えられますが、同じ人物が設計したので、ベクタのCray-1もこれを使っていますので共通のアーキテクチャという事でしょう。
近年使用されているSIMDという言葉はPentiumのMMX/SSEなどから始まった言葉で、Multimedia処理のためDSPをx86とかPowerPCが内部に取り込んだものです。つまり今日のSIMDというのはスカラCPUに属するもので、本来のCray-1のようなベクタCPU（Flynnの言うSIMD)に属するものではないわけです。
近頃は、GPGPUの話もありますが、これはFPアクセラレータで、本来的CPUの話ではないでしょう。
スーパースカラ処理は命令発行（命令管理）に関わるアーキテクチャですので、命令処理（Pipelineなどの演算実行）そのものとは関係ないと考えるべきでしょう。FP処理では、スーパースカラーか、Multi-FPUか、SIMDかといった並列処理に、あまり大きな違いはないですよ。
しっかり勉強して、質問があったり、間違いでも見つけたら、コメントに書き込んで置いてください。期待してますよ。
Re:次期地球シミュレータ (スコア:1)
コメントを読ませていただくと、ご趣旨は「ベクトル機もスカラ機も、“1命令1サイクル”という点では同一である」とおっしゃっているようですが、ベクトル命令とスカラ命令は全く異なるものと、当方は認識しています。
公開している日記ですので易しく書きますが、仮に、0x5555番地から始まる64個のデータと、0x6666番地から始まる64個のデータを加算して、0x7777番地以降に格納する処理を考えます。FORTRANでは、以下のような演算ですね。 仮想的なスカラ命令のアセンブラでは、以下のようなイメージになるでしょう。 そして、処理すべきデータは64個ですから、それぞれのアドレスを1ずつ増やしていって、64回繰り返す必要があります。そうすると、命令は4×64で256回、メモリから取ってきて解釈し、実行しなければいけません。
一方、仮想的なベクトル命令のアセンブラでは、以下のようなイメージになるでしょう。スカラ機のレジスタは1つにつき1個のデータしか格納できませんが、ベクトル機のレジスタ（下記のVA,VB,VC）は複数個のデータを格納できます。 ここで注目すべきは、上のスカラ命令の場合と大きく異なり、メモリから取ってきて解釈し実行される命令数はわずかに4、という点です。
もし、ここで考えているベクトル機もスカラ機も同じメモリバンド幅ならば、命令を取ってくる数が少ない分だけBUS資源を効率的に使えますよね、というのがベクトル機なり“SIMD”なりの基本的な発想だと思っているのですが、違うでしょうか？ もし違うのでしたら、文献なり論文なりをお示しくだされば、大変助かります。
また、「近年のスカラ機はハーバード・アーキテクチャで大きな命令キャッシュがあり、さらに命令の先読み（いわゆるprefetch機能）があるため、スカラ機でもベクトル機並みにBUS資源を効率的に使える」というお話でしたら、ぜひ定量的評価の載っている文献なり論文なりをお示しくだされば、ありがたいです。
結局、当方のような数値計算屋から見ると、ベクトル機というCPUアーキテクチャとBUSは切り離せないもので、お書きになっている、というご意見とは、のっけから「認識」が違いますから、話が噛み合わないのも無理はないですね。
われわれスパコン業界スズメの（一部の）間でささやかれているベクトル機の問題点は、ここ10年ほど、ベクトル機のメモリバンド幅が頭打ちになっている点で、「BUSで実効性能が引っぱられているなら、事情はOpteronやXeonベースのマシンでも同じで、ハードが複雑なベクトル機でなくても別にいいじゃん。x86マシンの方がもの凄く安いし」ということです。いくらコンパイラ屋さんが頑張っても、コードの全ての部分がベクトル命令に置き換えられメモリバンド幅いっぱいを使いきれるワケではありませんので。ことコンピュータに関して、過去のCPUアーキテクチャや命令セットだけを取りあげてその意味を議論しても、ある意味「衒学に過ぎない」と申し上げておきましょう。もちろん、「じゃあ新しいハードを作ろうか」と簡単にゆかないところに今のコンピュータ・サイエンスの難しさがあるのは理解しているつもりですが。パターソン＆ヘネシー『コンピュータの構成と設計』でも、既存のコードを走らせた結果をベースに、CPUアーキテクチャや命令セットだけでなくI/Oまで議論していたと記憶しています。（お読みになっていないのでしたら、ぜひご一読を。）
Re:能澤徹というお方 (スコア:0)
＞コメントを読ませていただくと、ご趣旨は「ベクトル機もスカラ機も、“1命令1サイクル”という点では同一である」とおっしゃっているようですが、ベクトル命令とスカラ命令は全く異なるものと、当方は認識しています。
＞ここで注目すべきは、上のスカラ命令の場合と大きく異なり、メモリから取ってきて解釈し実行される命令数はわずかに4、という点です。
＊＊＊
○認識が違っていると思いますけど。
ではどうやってピーク性能を計算しているのか教えてください。
「１データ1サイクル（ベクタ命令を含めると1命令1サイクル）」と書いたとおりで、命令をCPUの
Re:能澤徹というお方 (スコア:1)
＃ 引用の順番を少し変えます。
今のスカラ・プロセッサのプログラミング上、興味深い論文ですが、“Lattice Boltzmann Simulation Optimization on Leading Multicore Platforms” [lbl.gov] を会社で印刷して読みましたけど、数値計算屋の目から見ると「結局、“LBMHD”という、プラズマ解析で陽解法を使っているらしいコードで、計算ピーク性能に対してベクトル機なみに実行効率が上がるのは、Sun Niagara2とCell Bladeの、メモリバンド幅が広いマシンだけだよね」という、わりと広く知られている事実のみです。
GRAPE開発の牧野淳一郎先生の 公開用日誌 [artcompsci.org] で、能澤徹氏のブログ記事と、この論文について少し触れていて、と書かれていて、いささか手前味噌ですが「メモリネックな計算」という点では、牧野先生と見解は同じでしょうか。個人的には、Olikerらの書いた論文の中では、ベクトル機が苦手としている疎行列計算の性能評価、“Optimization of Sparse Matrix-Vector Multiplication on Emerging Multicore Platforms” [usc.edu] の方が興味深かったりするのですけど。
ぜんぜん違いますよ(大笑い)。公開用の日記ですから親切に書きますけど、仕事で関わったことのあるベクトル機の系列で、かつ触れても支障なさそうなところで、富士通VPP5000のハード解説 [fujitsu.com] がネットで見られますので、それを元に。
図４の「VPP5000 PE構成図」にあるように、ベクトル機はスカラユニット(SU)とベクトルユニット(VU)でできています。“PE”は「プロセッサ・エレメント」の略で、一般に使われているノードと同義。ベクトル機でもSUは必須です。変数の依存性などで、コードの全てをベクトル命令にコンパイルできるワケではありませんし、またノードといえど、OSは走らせねばならないですしI/O処理もあります。そして、スカラ命令だけ実行している時のSUは、
メモリからの命令の取り込み → 命令の解釈 → 命令の実行 → メモリへのデータ書き込み
と、通常のスカラ機と変わりありません。VPP5000のクロックは300MHzですので、いくらVILWアーキでも、SUの浮動小数点演算性能はしょせんクロック300MHzなりです。
一方、SUにベクトル命令が入ってきた場合、以下のようになります。スカラ命令とベクトル命令の違いは、別のコメント [srad.jp] に易しく書いたつもりですので、分からなければ見てください。
メモリからの命令の取り込み → 命令の解釈 → （お、ベクトル命令だ） → ベクトル命令をVUに転送
一方、SUからベクトル命令を受けたVUは、浮動小数点演算を行うワケですが、ここで注意すべきは、
- その後、SUとVUは必要に応じて同期をとればよい
- SUとVUのクロックは別であっても構わない
- VUがデータアクセスに使うロード／ストア・パイプラインは、SUの使うロード／ストア・バスと独立である
の３点くらいでしょうか。実際のVPP5000では、1クロックに対して最大32演算できるので、論理性能ピーク値は、300MHz×32で、9.6GFLOSになります。演算パイプラインの立ち上がりロスを無視すれば、VUは9.6GHzで動作し、1クロックで1演算命令を行っていると解釈することもできます。また、VUのメモリバンド幅は、前述の富士通の記事によると 76.8GB/S とありますが、この数字は高価なSRAMを主記憶に使った場合で、通常のDRAMだとその1/5の、15GB/S程度だったでしょうか。VUの演算器とメモリバンド幅は、お互いに足を引っぱらないように設計するべきで、そこで常にByte/Flopsの値が問題になってくるワケです。
要約すると、ベクトル機のハードは、通常のスカラ機(SU)と、それに付随するベクトル型浮動小数点演算専用ハード(VU)からなるヘテロな構成で、それぞれのデータバスは独立しています。これは、ベクトル機のハードを語る上での「イロハのイ」です。
お言葉を返すようですが、貴方こそもう一度Cray-1のハードウエア・マニュアルを読むべきではないでしょうか？ 幸い、以下のページ [ed-thelen.org] からネットで読めます。“Figure 3-1”を見れば、スカラ演算部とベクトル演算部で、データバスが別箇になっているのが判りますよね？ 貴方がどこのどなたか存じ上げませんけど、技術論文さえマトモに読めない、能澤徹氏とかいう「自称テクノロジー・ライター」の無知な妄説に加担する必要はありませんよ、とご忠告申し上げておきます。
Re: (スコア:0)
VPP5000のVPPというのはVector Parallel Processorの略でしょ。要するにVectorのPipelineを並列に複数個持っているという意味です。
今VPPの詳しいSpecを見る気はしませんので、あなたの言う1クロック32演算を信じるとすると、VPP5000は32本のPipelineを並列に有するということで、もしPipelineがFMAをサポートしているとすれば16個のPipelineを並列に持つ機械という事になります。
これは、Cray-1が1Pipelineであったことからの進化という事ですが、基本のVector Pipelineの論理構造は同じで、1浮動小数点演算を1クロックで処理す
Re:能澤徹というお方 (スコア:1)
もちろんメーカーのエンジニアさんの言葉は慎重に聞きますが、鵜呑みできないところにトシが表れているのでしょうか(笑)。いくつかのテスト・プログラムを実行させてみて「どうも実際のハードはこういう仕組みになっているらしい」と推測できる場合もありますけれど（最近のマイクロ・プロセッサも同様）、ハードの真実をつきとめて発表するのがわれわれのミッションではありませんし、メーカーさんにも事情がありますので、まあ、黙して語らないところはありますね。この商売からオサラバしたら、もう少し自由にものが言えるのではないかと思います。1990年代の前半は、スパコンが出すデータの量と、その結果を可視化するsgiとかのグラフィックス・ワークステーションの処理能力がほぼつり合っていました。しかし1990年代の後半になって、いわゆる「ベクトル並列」になると、もうsgiのマシンでは処理しきれない出力データ量ですので、結局アプリの中でデータの「間引き」をして、可視化用データを別途出力せざるを得なくなったのですね。現在は、「スパコン上で可能なら、そっちで計算して欲しい」とFFTやら色々、出力のためのデータ処理をアプリの中で行う要求が出てきました。本来の計算に加え、別のものを仕込まないといけなくなったので、それなりに勉強が大変です。しかしこれも何かのめぐりあわせですので、次の世代に先送りせず、やれる限りのことはやっておこうという姿勢です。