つっても、非公開のを別につけているわけではない。
Copyright 1999- Jun Makino
2007/06 2007/05 2007/04 2007/03 2007/02 2007/01当面の予定
IBMの基礎研はこの産業機器組込用の超低消費電力の小CPUを多量に結合して高 性能スパコンを作るという方式はQCDだけでなく、ナノ、BIOなどの多方面にも適 用可能であると考え、1PetaFlopsを目指したBlue Geneの開発を決断した。QCDOC が1コア１FPUチップであるのに対し、BGは2コア4FPU構成にしたが、 Interconnectは時間軸を減らし一般的な3次元トーラスとしたのである。なんか歴史が改変されていて、元々の BlueGene はなかったことになっている。
IBMは Power4/5に加え、基礎研の研究プロジェクトであったBlue Geneを加えて提案 し、両方が採用となったのである。そして、このとき以来、Blue Geneは納品先 のLLNL(ローレンスリバモア国立研究所）の頭文字のLを付けてBlueGene/Lと呼ば れるようになったのである。ここでも歴史が改変されていて、 L は最初は Lite だったのが、、、
スパコンはあくまで道具であり、それ自体を目的化し、国産に固執するのは行 き過ぎであろう。道具は、道具として多くの研究者に与えることが本質であると 思うからである。ま、 IBM の人がそういうのを書くのは勝手だけどさ。税金なんだから、本当 は国内の会社にいくか海を渡って消えてしまうかは大問題である。
このような激動の世界の中で、若干ずれているのが、筑波大のPACSーCSという システムである。これは筑波の計算科学センターが中心になってQCDのために、 日立と富士通におよそ22億円前後で発注作成したシステムである。Max10.35TF, Peak14.34TF, Lnkpack実行効率72.18%のシステムで、CPUはNet-Burstアーキ テクチャーのXeon 2.8Ghz、Interconnectは独自の4次元トーラス型でQCDSPと同 じ構造である。BG/Lの3次元トーラスではQCD計算でパフォーマンスがでないとし て独自開発に及んだものであるが、その客観的成果は公表されていない。ネットワーク 3D ハイパークロスバーだけど、、、
参考までに、KEKのBG/L 4ラック・システムはMax18.67TF、Peak22.94TF、 Linpack実行効率81.39%で8.5億円前後と推定されている。PACS−CSの38.6%の値 段で、性能は1.8倍なので、価格性能比的には4.7倍程度と考えてよい。 PACS- CSの代わりにBG/L−4ラックを購入したとすると13.5億円の無駄を省くことがで き、逆に、この13.5億円が独自Interconnectの「わがまま」の対価と言うことに なるのであろう。 同じ頃に完成した東工大のTSUBAMEはSun-Opteron− InfinibandでMax38.18TF、Peak49.87TF、Linpack実行効率76.56%(ClearSpeedを 除く）を約20億円程度で契約しており、Linpackに関してはPACS-CSの4倍近い性 能を示していることも指摘しておきたい。QCD 計算の効率と Linpack の効率が同じならこの比較意味があるけど、 BG/L は IBM の発表で QCD 計算の効率が 20% 程度、TSUBAME はあのネットワーク では数字を出すのも、、、という感じなので、、、とはいえ、朴さんの 2005/2/16 の資料だと Xeon の QCD での性能も 20% 辺りかな。
そもそも、経験的事実としてCPUにNet-burstのXeon、GbEthernetを選んだ時点 で、PACS-CSのパーフォーマンスは上がらないであろうことは予想されたことで ある。PACS-CS の問題点はそんなところではなくて、Xeon+GbE のくせになんで 1 ノー ド70万円もするんだよ？というところ。まあ、理由は単純に F+H から買った からだけど。まあ、Fからクラスタ買うより C から箱買ったほうが安い、とい うのはそれでいいのか？というのは大問題だと思う。
要するに、QCDの計算、あるいは計算科学という大目標に対し、（税金によ る）お金のかけ方が「でたらめ」なのではないかと言うことである。こんなデタラメな文章でなんか言われてもね。別に筑波の弁護をする気はない けど、ちょっと勘弁して欲しいかも。
***********************************************************************
Dear Colleagues,
We are pleased to announce a two day workshop:
AstroGPU 2007
IAS, Princeton, 9-10th November 2007
http://www.astrogpu.org
on high performance General Purpose Computation on Graphics Processing
Units (GPGPU) in Astronomy and Astrophysics, to be held November 9-10th
2007. at the Institute for Advanced Study in Princeton, NJ, USA.
Rationale and Goals
-------
Graphics processing unit (GPUs) are rapidly emerging as a powerful and
cost-effective general purpose platform for high performance computing.
The current generation of GPUs sports capabilities in TFLOP range,
already an order of magnitude greater than the most powerful x86 CPUs.
Such an increase in computational power opens opportunities to explore
previously inaccessible problems in astronomy and astrophysics. However,
it also brings the challenges of adapting existing algorithms and codes
(and devising new ones) to run efficiently on intrinsically massively
parallel SIMD/SPMD GPU architectures.
The goal of this workshop is to explore and discuss the applicability of
GPUs to astrophysical problems. It will bring together astrophysicists,
colleagues from other areas of science where GPGPU techniques have been
successfully applied, and representatives from the industry who will
demonstrate in tutorial sessions the GPU hardware, programming tools,
and GPGPU techniques.
Program Outline
------
A tentative program can be found at
http://astrogpu.org/index.html#Program
The program is divided in three conceptually distinct sessions:
scientific talks, hands-on GPGPU tutorial and discussions. The
scientific talks will focus on current and emerging computational
problems in astrophysics requiring TFLOPS-level computational power, and
efforts under way to apply GPUs to astrophysical problems.
A one-day course on the CUDA (Compute Unified Device Architecture) GPGPU
programming interface will be presented by representatives from NVIDIA.
The course will assume a basic knowledge of the C programming language.
Participants will be able (and encouraged) to experiment with sample
GPGPU codes both during and after the tutorial sessions. GPU hardware
and software will be provided, but participants are asked to bring their
own laptops in order to access it (with wired or wireless networking).
The workshop will conclude with a roundtable discussion on the
directions of high performance computing, the viability of GPUs as a
computing platform for astrophysics, and comparisons to alternatives
(Cell, GRAPE, etc.).
Participation
------
The workshop will be limited to ~70 participants. Those interested in
attending should preregister by filling out a form at:
http://astrogpu.org/prereg.php
to receive further announcements and updates.
We expect no or only a modest registration fee. Hotel accommodation will
be offered at nearby hotels, possibly at reduced rates depending on the
number of participants. A list of hotels and rates will be posted on the
website in time for second announcement, which is expected in late August.
We may be able to provide some assistance to junior participants and
participants coming from outside of the US. If you need assistance to
attend the workshop, please send us a request by email (to
mjuric@ias.edu), with details about your needs and a brief justification.
Free wireless internet access will be provided at the Institute. A
limited number of public computers and wired ethernet connections will
also be available.
Invited and Contributed Papers
------
A current list of invited speakers may be found at
http://astrogpu.org/index.html#Speakers
It will be updated as we receive confirmations and responses from the
speakers.
Due to time constraints, we do not plan for contributed oral
presentations. Participants are however encouraged to contribute poster
papers. There will be no proceedings.
Further details will be provided in time for second announcement.
Location
------
The Institute for Advanced Study is located in Princeton Township in
central New Jersey. The Institute is approximately 2km from the center
of the town of Princeton and is easily accessible by car, train, or taxi
from major cities along the Eastern seaboard. Major airports serving
Princeton include New York metropolitan area airports -- Newark (1 hour
by train or car), JFK or La Guardia (2-3 hours), and Philadelphia
airport (2-3 hours):
http://www.ias.edu/about/directions/
For further information about the Institute and the School of Natural
Sciences, visit us at:
http://www.sns.ias.edu/
http://www.ias.edu/about/
Organizers
------
Mario Juric (Chair, IAS)
Piet Hut (IAS)
Eric Ford (U. Florida)
Please circulate this message widely to others you believe may be
interested.
On behalf of the organizers,
--
Mario Juric,
Member, School of Natural Sciences, Institute for Advanced Study
Web : http://www.sns.ias.edu/~mjuric
Phone : +1 609 734 8352 PGP: ~mjuric/crypto/public.key
E-mail reading/answering policy: http://majuric.org/email/
明日の×××ですが、スーツでお願いします。 夏なのでネクタイは無くても構わないと思います。
放射能の漏出は確認されていない。(読売の記事、 13:21) と発表しておいて実は
新潟県中越沖地震の影響で、東京電力柏崎刈羽原発６号機（新潟県）で使用済 み燃料プールの水があふれ、施設内の排水溝を通じて海に流れ出ていたことが １６日、東電の調べでわかった。水は微量の放射性物質を含んでおり、流れ出 た量は不明で過去に例のない想定外の事態だったという。(朝日の記事、 23:27)であったと、、、なんか対応が××すぎ。設計想定よ り大きな揺れだったのに壊れなくてよかった、、、(壊れてなかったとすれば)
g++ -I/usr/local/include -L/usr/local/lib -I.. -o testmat matmul32.o testmat.cc -L../ -lvpmsim -lm -lqd
In file included from /usr/local/gcc-3.3.2/include/c++/3.3.2/bits/stl_algobase.h:69,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/memory:54,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/string:48,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/bits/locale_classes.h:47,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/bits/ios_base.h:47,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/ios:49,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/ostream:45,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/iostream:45,
from /usr/local/include/qd/qd.h:26,
from testmat.cc:7:
../new:2: error: 構文解析エラー before `m'
../new:15: error: 構文解析エラー before `#' token
../new:16: error: 構文解析エラー before `#' token
../new:17: error: 構文解析エラー before `#' token
../new:18: error: 構文解析エラー before `#' token
../new:19: error: 構文解析エラー before `#' token
../new:20: error: 構文解析エラー before `#' token
In file included from /usr/local/gcc-3.3.2/include/c++/3.3.2/bits/stl_algobase.h:71,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/memory:54,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/string:48,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/bits/locale_classes.h:47,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/bits/ios_base.h:47,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/ios:49,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/ostream:45,
from /usr/local/gcc-3.3.2/include/c++/3.3.2/iostream:45,
from /usr/local/include/qd/qd.h:26,
from testmat.cc:7:
/usr/local/gcc-3.3.2/include/c++/3.3.2/bits/stl_pair.h:71: error: 文法エラー
before `;' token
/usr/local/gcc-3.3.2/include/c++/3.3.2/bits/stl_pair.h:73: error: '_T1' is used
(以下省略)
エラーメッセージを落ち着いて見ると、 "../new"、つまり、 current の 上
の new というファイルをヘッダファイル
/usr/local/gcc-3.3.2/include/c++/3.3.2/new の代わりにインクルードして
破綻している、ということは明らかなわけだが、そのことに気が付くのに手間
どった。
SPARC64 VIで、FMAの演算のレイテンシを短縮して、Linpackなどの FMAを高密度で実行するアプリケーションで、FMAを稠密に実行できるようにした。これにあわせてレジスタの書き込みポートを 4つに増強し、レイテンシ短縮にバランスさせた他、レジスタリネーミング用の Floating point register Update Buffer（FUB）を 48本に強化した。つまり、 V では FMA のレイテンシが大きすぎて FUB の数が足りなかったの で FMA を稠密に実行できなかったと。あれ、でもこっちの 発表資料だとそもそも VI では Fused Multiply and Add になってる。 IBM の特許じゃなかったっけ？
では本当にベクター型はスカラー型に比べて実行効率が高いのかというと、5-6年くらい前は事実であった。しかし現在では事実ではない。Top500第1 位のBGLは26万CPUコアで76.5%であり、1ラック2048CPUコアでは82.2%である。第2位のオークリッジ研のJaguarは Opteron Dualコアで85.2%である。従って地球シミュレータの87.55%が飛びぬけて高い訳ではない。っていっても、行列の要素をモートンオーダーで格納する、とかいったレベル のチューニングをやって 77 % な BG/L と比べられても、、、みたいな。
又、TOP500のベンチマークは連立方程式を解くためのLINPACKだけであるが、LINPACKを含んだより広いアプリケーション・ベンチマークであるHPCCで比較すると、Linpack１TFLOPS当たりのシステムでのフーリエ変換（FFTE)や行列の転置（PTRANS)などでは OpteronやBGLに劣る結果となっているのである。 つまり、現在の実測性能データからは、ベクター型スパコンがスカラー型スパコンに対し優位に立っているというデータは見当たらないのである。というのはどこをみたんだろ？ base and optimized runsで見ると、 BG/L の FFT 性能は HPL の 1% 以下なのに対して SX-7は (32PE 1ノードだと) 30% で BG/L の 30倍効率 が高い。マルチノードのまともなデータはないっぽいけど、これは 測定方法の問題のような。 FFT は地球シミュレータで 3D FFT で結構理論ピークに近い 値がでてたし。まあ、そういう意味では BG/L の値が低いのも測定方法の問題 かも。次世代スーパーコンピューターで、こんなベンチマークでトップ をとるとかいうのを目標に出しちゃったのはなんか問題な気がする。
とはいえ、業界では有名な
178位 名大 理論性能13.84TFLOPS 実行性能6.86TFLOPS 49.57% 290位 宇宙航空研究所 理論性能11.98TFLOPS 実行性能5.41TFLOPS 45.16% 414位 京大 理論性能 9.19TFLOPS 実行性能4.55TFLOPS 49.51%Linpack で 50% しかでない HPC 2500 の話が書いてあるのは素敵。 某先生が某さんから理由を聞いた、という話は聞いたことがあります。はい。 SPARC 64 VI では直ったみたいだし、別に LINPACK で性能がでなくても実際のアプ リケーションで同じだけ実行効率が下がるわけじゃないし、まああまり本質的 な問題ではないと思うけど。
従来１社が手掛けてきた国産スパコンとしては異例の共同開発だ。って、、、「科学技術用高速システムプロジェクト」とかはなかったことになっ てるのかしら。
この４５ナノの半導体については、量産のメドがまったく立っていない。といっても国内でも松下は量産にはいったし、東芝・ソニー・NEC 連合はやる、 というか
ＮＥＣエレの中島俊雄社長は４５ナノ技術について「自社単独では難しい」と、量産化にメドが立っていない状況を示唆した。つっても、もう2年くらい前から NECエレは単独開発のつもりなんかないと思 います。
と色々細かいところはあるけど、
３社体制になった理由を理研は「あくまで技術的な理由」（次世代スパコン開発実施本部）としている。だが参加メーカーからは「巨額の公共予算を１社にだけ配分できないという配慮」との恨み節が漏れる。なんてところまで取材したのは(まあ、誰がみたってそう見えると思うけど)結 構感心。
The symposium will be held in the Conference Center of the beautiful island of Capri (Italy).とか書いてあって、会議場がどこかとか書いてないなあ。 Vesperini はもう 10年もイギリスとかアメリカにいると思うが、その辺イタリア人のままである。 ちなみにおそらく会場と思われる場所。
apt-get install gcc-g77私も PLplot 使うかな。 Ruby binding は今のところなさげなのがアレ。
Ａ 今回導入するスーパーコンピュータシス
テムは、超並列型スーパーコンピュータシ
ステムである。超並列型スーパーコンピュ
ータシステムは複数ノードで構成される高
並列型計算機であること。ここで、ノード
とは、主記憶を共有する１台以上のCPUから
構成されるコンピュータシステムであると
定義する。ノード単体あたりの理論ピーク
演算性能が160 GFLOPS以上（倍精度浮動小
数点演算）であり、かつ理論ピーク演算性
能の総和が150 TFLOPS以上（倍精度浮動小
数点演算）であること。実効演算性能につ
いては、ベンチマークにより評価する。
Ｂ ノード単体あたりの主記憶容量は32 GBy
te以上であり、かつ総主記憶容量は30 TBy
te以上であること。全ノードの内、16ノー
ド以上は128 GByte以上の主記憶容量を有す
ること。
Ｃ CPUは64ビット拡張されたIA32アーキテク
チャに基づくものであること。
Ｄ 各ノードが備えるノード間接続のための
ネットワークリンクのデータ転送速度の理
論ピーク値が、１ノードあたり５ GByte/秒
以上であること。
Ｅ ノード毎に総計250 GByte以上の物理容量
を有する磁気ディスクドライブ群を備える
こと。当該の磁気ディスクドライブ群はRA
ID-１による運用が可能であること。
Ｌ 全ノードのうち半数以上のノードがフル
バイセクションバンド幅で接続されること。
残りのノードにおいては、多数のノードで
フルバイセクションバンド幅が確保される
ことが望ましい。
いくつか項目省略したけど、資料招請の段階でこんな細かいのか。で、
x86-64 でないといけないとか ノード当り 160Gflops 以上ないといけないと
か理論転送速度が 5GB/s 以上とか、ノード毎の RAID1 で 250GB 以上のディ
スクとか意味不明、というか、意味はわかるけどこんな書き方するかよ？みた
いな仕様が一杯。これで年 10億(前のシステムと同じとして)なの？
をい、、、レフェリーが自分の名前がはいっている論文の結論を全く逆に書いている
yum install rsh-server vi /etc/xinetd.d/rlogin vi /etc/xinetd.d/rsh /etc/init.d/xinetd restartみたいな感じだったような気が。