【気象/IT】「ゲリラ豪雨」予測も　天気予報に新型スパコン「ＳＲ１６０００モデルＭ１」　１秒間に８４７兆回の計算が可能−気象庁

「ゲリラ豪雨」予測も　天気予報に新型スパコン　気象庁

http://www.asahi.com/national/update/0602/images/TKY201206020127.jpg
写真：気象庁の新型スパコン「ＳＲ１６０００モデルＭ１」＝東京都清瀬市の気象衛星センター

　気象庁は５日、天気予報に活用する新型スーパーコンピューター「ＳＲ１６０００モデルＭ１」
（日立製作所製）を稼働させる。データ処理能力が上がり、予測が難しかった局地的な大雨
「ゲリラ豪雨」などの発生見通しにも役立つとしている。

　新型スパコンは東京都清瀬市の気象衛星センターに設置された。気象庁によると、計算
速度はこれまでのスパコンの約３０倍で、１秒間に８４７兆回の計算が可能。当面は羽田空港
周辺の気象予測の強化から取りかかるという。（赤井陽介）

朝日新聞 2012年6月3日19時8分
http://www.asahi.com/national/update/0602/TKY201206020117.html

関連ニュース
【IT】経産省、車載器の速度や位置などのプローブ情報を共有化-渋滞やゲリラ豪雨把握
http://anago.2ch.net/test/read.cgi/scienceplus/1326357082/-100
【科学】今夏は太平洋高気圧弱く、ゲリラ豪雨3割増の予想も…「昨年のように連日晴天とはならないだろう」 画像あり
http://toki.2ch.net/test/read.cgi/wildplus/1312455064/-100
【話題】「ゲリラ豪雨」精密予測へ 広島、岡山両都市圏に設置の高性能気象レーダー試験運用 中国地方整備局 画像あり
http://toki.2ch.net/test/read.cgi/wildplus/1303906560/-100
【気象】ゲリラ豪雨の雲探せ ウェザーニューズ社が移動レーダー
http://toki.2ch.net/test/read.cgi/wildplus/1281429218/-100
【気象】ゲリラ豪雨:GPSを使って発生を予測 今秋にも運用開始
http://gimpo.2ch.net/test/read.cgi/scienceplus/1244493414/-100
【気象】気象レーダー観測5分ごとに ゲリラ豪雨対策で
http://gimpo.2ch.net/test/read.cgi/scienceplus/1244457556/-100

「ＳＲ１６０００モデルＭ１」　何か無性にスパコンに萌えてしまう

なにこの8ビットパソコン臭漂うお名前

「ゲリラ豪雨」予測なら俺の古傷がうずくからすぐわかる。

なんか簡易トイレみたいな外観。

>>4
スパコンの古傷の方が凄いよ

ゲリラ豪雨の兆候が観測されてから計算して予報が間に合うのか？
一日前の情報でゲリラ豪雨の出現確率とか位置を求められるとは思えない。

＞１秒間に８４７兆回の計算が可能

これじゃあ、日本人１億人の顔を顔認証装置で探し出す事は一瞬で出来るな。

もう悪い事は出来んな。

オウムの残党もそろそろ捕まるだろう。

京はどうしたの？ソフトが無ければただの箱？

このクラスでいくらくらいすんだろ

役立たずに何十億もかけたんだろ。

ゲリラ豪雨と集中豪雨は、何が違うの?

>>3
俺はMIPSを思い出した

>>9

　　　京の方が汎用性が強いが、どうもフルに使われていないみたい。

　　　無料お試し計画があるみたいだし、使って欲しいと宣伝しているみたいだ。

PC-8801mk2SRモデル30

でも、

明日の天気も当たらん気象庁ｗｗｗ

馬鹿ほど　簡単に計算することができずに無駄に計算ばかりする

計算能力なんてどうでもいいから、何が出来るか記事にして欲しいな
レーダーで虫の集団を観測してその情報から天気予測するシステム
のほうが実用性あったりして

ゴリラげうう

あの新人、計算高い奴らしいよ。

スーパーコンビニ？

>>18

馬鹿っぽい

気象についてはほぼ方程式ができているんだし今までの計算量がありすぎてできなかったんだから正しい選択

>>18
俺が中二の頃、もっとも欲しかったモデル。
早まってFM-NEW7を買っちまったが。

前面のピラミッド状のキラキラは飾りですか？
放熱性能upとかあるの？

>>18　の虫レーダー積乱雲予想システムはこれな
虫を追跡し積乱雲予測…気象研などが成功
ttp://www.yomiuri.co.jp/science/news/20120526-OYT1T00466.htm

>>22　自分を賢いとは思っていないけど馬鹿にする理由くらいは書いてほしいな

> 発生見通しにも役立つ

要はアテにはならんちゅうことかよｗ

無駄無駄
どうせまた原発事故が起きれば黙秘なんだろう

IBM POWER755の日立版だっけ？
畳基板のやつだろ

>>12
通り雨かどうかじゃね？

可能なのは足し算でしょ?

阿呆れんほーの仕分けで、山間地のアメダス減らしたようだが、天気の予測精度に変化はなかったの？

水平分解能力が今までの5kmから2km　に細かくしても予報時間に間に合うような速さらしいです。

東京アメッシュの使い勝手の良さ

>>9
>1　のスパコンは1年中気象庁関連で占領する。

>1　を設置せずに気象庁が京を使ったら、1割くらい常駐することになり
京を使おうとする他の人間にとって烈しく邪魔になる

>>35
>>1のスペックからすると8割5分くらい常駐じゃないの？

ああ Power7 のヤツか。筋のいいマシンだな

>>36　兆と京は四桁違いだよ　847兆=0.0847京

>>38
あ！そうだった（汗
側レスご指摘蟻〜！

>>23
＞気象についてはほぼ方程式ができているんだし‥‥

こういう馬鹿と，それを信用するメディア，クソ政治家が
過去７年間，温暖化詐欺に乗って２０兆円をドブに捨てた。消えろ白痴。

>40　の方がおかしい。気象っていっても対象（気象要素、空間、時間）が
違えば信頼度は桁違いなのに、十把一絡げで考えてる

スパコンのCPUもすっかり米国製になっちまったな。
京は富士通製だけど、富士通も先端fabは諦めちまったし。

中国製CPUを使わざるを得ない事態にだけはなりませんよーに…
中国製のチップにバックドア仕掛けられてたなんて話も聞くし…

なんで京だとだめなの？
えろい人おせーて。

>>12
ゲリラ豪雨は範囲が狭い

レンホー何か言ってみろよｗｗｗ

>>42
そろそろ電気伝達を原理するCPUを卒業する時期がきたってこと。

でも、こいつ竜巻予測率は上がらないんだよね。
ゲリラ豪雨でﾀﾋらんが、竜巻はね…
竜巻の精度上げて欲しい。イイカゲンな※国より外れるとかありえん。

１０年後には家庭用パソコンになるのかな

それにしても Power7 はいい石だね。IBMの本気を見た気がするよ。
DECが生きていたらこんな石を作ったんだろうな

ファミコン時代のスパコンと
ウィンドーズマシンがおなじ性能

1-2km間隔で降雨計を配備すりゃいいだろ

気象計算ってことはFFTとかに最適化してんのか？

これで８４．７寺風呂ぷっすか。
スペック的には地球シミュレータの２倍てことになるのか。
体育館にくらべたらずいぶん小さくなったねえ。

１秒間に８４７兆回も計算せなゲリラ豪雨予測できひんの？

>>48
土建屋のおっちゃんが死んでるし
子どもも川で流されただろ

計算８４７兆回って、いわゆるAND、OR、EORみたいな
アセンブラ１行でやれる計算のことだよね？

>>43
現時点では設計が日本側だし、不自然な仕組みが付け加えられてたら
仕様が変わることからわかる……と思いたい。

今後Venus的なプロセッサが出てきた時には専用工場になる可能性もあるかな。
ルネサスは微細化プロセス技術は保持し続けたいみたいだし、小規模工場のプランもある。

>>57
倍精度浮動小数点数（指数部と仮数部あわせて64bit）の
掛け算や足し算だよ

847Tflopsか。
Core i5 2.67GHzで36Gflopsだから、今のパソコンの２万倍速いのだな。

http://www.hitachi.co.jp/Prod/comp/hpc/SR_series/sr16000/SR16000_CA-679R.pdf

によると、SR16000モデルM1の最大性能は502TFLOPSなんだけど、847兆回に届かない
のはなんでだ？

>>1

上記PDFにある、

モデルM1では、専用ノード間
ネットワークによる完全結合の高速ネットワークを採用しました。
また、モデルM1では、各ノードに専用のノード間ネットワーク制御
LSIを実装し、各ノード間を低レイテンシで強固に結合。ノード間転送
性能は、ノードあたり最大96Gバイト／秒（単方向）＊と高速です。

ってのが、京との違い

>>44
ピーク演算性能がいくら高くても、それに見合ったノード間通信速度がないと、ほとんど
の応用では実効計算性能はぼろぼろになる

京は、本当に金の無駄だった、あの金がNECに流れてたら全然違ったのに

職員を周辺に配備して気象報告させた方が早いのでは

>>61
おっと、>>1ってあるのは、

>>9
>京はどうしたの？ソフトが無ければただの箱？ 

へのレス

>>61
気象庁自身のリリースでも847TFLOPSだね。(下記ページのPDF別紙)
http://www.jma.go.jp/jma/press/1205/24c/20120524_naps_renewal.html

M1は32の倍数でしか構成できないらしいから、気象庁のはメモリ量も演算性能も半端だし、複数システムの組み合わせかな。
512, 256, 64, 32ノード各一台とか。

最近、俺のゲリが収まらない＞＜
そんなリソースがあるなら、
ゲリ予測も立ててほしぃ

>>62
ウェザーニュースのゲリラ豪雨調査隊

>>41
そこまでわかってるのに次に進めない研究者たちって馬鹿なの？

>>61
Power775のスーパーノードは128CPU（4畳ブレード、32MCM）。

異なるs-nodeのCPU-CPUは2x10GB/s（上り下り）で通信できるわけだけど、
それって2x128CPUで共有だよ。2x128CPUの中で2x1CPUだけが
通信するときには2x10GB/s フルに使えるが、同時に通信する
ペアが増えたら増えただけバンド幅は低下する。

ttp://news.mynavi.jp/articles/2010/09/14/hot_chips22_scomputer/001.html

完全結合っていっても実際はこう

異なるs-nodeのCPU間
　CPU-HUB-HUB-CPU　4/128
　CPU-HUB-HUB-HUB-CPU 28/128
　CPU-HUB-HUB-HUB-HUB-CPU 96/128

>>64
54物理ノード（432論理ノード）が二つ

使ってみたい

何だ気象の方程式って

>>68
>異なるs-nodeのCPU-CPUは2x10GB/s（上り下り）で通信できるわけだけど、 
>それって2x128CPUで共有だよ。

それは、相手が同じs-nodeの場合だけじゃねーか

s-node間は、10GbpsのDリンクで完全結合されてるから、一つのs-node内のCPUが
それぞれ異なるs-nodeと通信するようにプログラムすりゃいいだけ

>異なるs-nodeのCPU間 
>CPU-HUB-HUB-CPU　4/128 
>CPU-HUB-HUB-HUB-CPU 28/128 
>CPU-HUB-HUB-HUB-HUB-CPU 96/128 

お前の引用した記事の冒頭ぐらい読め

>IBMのBlue Watersシステムの計算ノード間の接続構成は、富士通のTofuとはまったく異
>なる。3Dトーラスで10万ノードを接続すると、立方体としても一辺が46ノード程度になる。
>したがって最も遠いノードとの通信には各次元で約23個のICCを通過しなければならない。
>これに対してBlue Watersでは数個のHUB Moduleを経由するだけでシステム内のどのノー
>ドでも到達できる構成となっている。

>したがって最も遠いノードとの通信には各次元で約23個のICCを通過しなければならない。

>したがって最も遠いノードとの通信には各次元で約23個のICCを通過しなければならない。

>したがって最も遠いノードとの通信には各次元で約23個のICCを通過しなければならない。

京のしょぼさがわかるだろ

>>69
最悪でも　CPU-HUB-HUB-HUB-CPU で届く範囲で
最大規模だとそうなるな

重箱の隅をつつくのは多次元では当たり前のことだったんだよ！
http://togetter.com/li/317843

>>72
>一つのs-node内のCPUが
>それぞれ異なるs-nodeと通信するようにプログラムすりゃいいだけ

もしもそれが簡単なことなら、これも簡単なことではないのかな

各CPUが
それぞれホップ数の少ないCPUと通信するようにプログラムすりゃいいだけ

京は3次元メッシュが12重に重ねられているような接続で
迂回経路はいっぱいある。

インターコネクトチップとCPUの接続は京の方が太い

Power775 HUB 192GB/s / 約1TFLOPS
ttp://news.mynavi.jp/photo/articles/2010/09/14/hot_chips22_scomputer/images/010l.jpg

京 ICC　2x20GB/s /128GFLOPS
ttp://news.mynavi.jp/articles/2012/04/18/kei_all/001.html

>>75
>>それぞれ異なるs-nodeと通信するようにプログラムすりゃいいだけ 
>もしもそれが簡単なことなら、

簡単だよ

>これも簡単なことではないのかな
>各CPUが 
>それぞれホップ数の少ないCPUと通信するようにプログラムすりゃいいだけ 

それが簡単なら、完全に独立で通信しない複数のコンピュータを使えば済むな

>京は3次元メッシュが12重に重ねられているような接続で 
>迂回経路はいっぱいある。 

遅延が大きいことだけでも、大問題なんだけど？

>>76
大域での通信速度が問題なのに、隣接チップ間なんて極局所的な通信速度を持ち出す
時点で、、、、、、

そりゃLINPACKの性能だけは出るけど、実用性は皆無

>Power775 HUB 192GB/s / 約1TFLOPS 
>京 ICC　2x20GB/s /128GFLOPS  

京の設計の非実用性が際立つだけなんだけど？

天気崩れるときはいつもレーダーナウキャストの予測見てるんで
そのうちそれの精度が上がるといいなー

週間天気予報どころか明日の天気予報すら信じる事ができない

いくら計算できても計算式入れる奴が馬鹿だと馬鹿な答えしか出ないだろ
そのへんどうなってんだ？

８０年代PCみたいな名前だな

>>77
ホップ数≠遅延時間だが、そこまで言うなら具体的な数値をあげてはどうだ

>>78
インターコネクトチップのローカルCPUとは逆側

Power775 HUB 896GB/s / 約1TFLOPS
京 ICC　100GB/s / 128GFLOPS

あまりかわらない。ここで差がなければ
Powerが京に大差をつけることはできないよ

べぬるい専用機？六方細密接続とかしないのかね？

気象庁のスパコンはハイタック時代から日立の指定席
数値予想は一部の技官を除いて日立に丸投げだろ

ときどき、ハードとかソフトに障害が生じると思うんだが、
そういうときは予報はストップなのか？
また、東電が電源を供給できなくなったら、止めるの？

>>83
>ホップ数≠遅延時間だが、そこまで言うなら具体的な数値をあげてはどうだ 

遅延時間はホップ数に比例するし、パケットの先頭をみてすぐにフォワードすることで比例
定数が減らせるのは通信がほとんど行われていない場合だけ

ある程度以上のトラフィックがあれば、HOLブロックにより、パケットの大きさとリンク速度が
同じなら、ホップ数≒遅延時間となるので、具体例を考えるまでもない

さらに、各ホップでリンクの帯域を消費するので、（実効通信帯域）＝（リンク帯域）／（ホッ
プ数）となり、遅延だけじゃなく帯域もぼろぼろなのが京

>>84
>インターコネクトチップのローカルCPUとは逆側 

>>76
>インターコネクトチップとCPUの接続は京の方が太い 

と言っておいて、真逆かよ

何を錯乱してんのか知らんが、CPUとは逆側はまさにトポロジーが問題になる部分なので、
同程度のリンク速度でもトポロジーがぼろぼろの京は、遅延も帯域もぼろぼろ

>>88
漠然と一般論ばかり語ってないで具体的な数値を頼むよ

>仮に、この最も距離が離れたノード間でパケットを送ると、中間のノードの
>通過に5.6μs、これに送信と受信側での計0.5μsが加わり、トータルで
>6.1μsかかるという計算になる。もちろん、これは最悪のケースであり、
>平均的にはこの半分程度の時間となる。また、隣接通信が大部分という
>アプリケーションでは0.5μsで通信ができることになる。

Cool Chips XV - 「京」のTofuインタコネクトの詳細が明らかに
ttp://news.mynavi.jp/articles/2012/04/25/coolchips_xv_tofu/

ゲリラ豪雨予想できても、床上浸水止められないんだから・・
やっぱ被害は同じじゃん。

ゲリラ豪雨をどう予測してるんだろな。

空間と時間をどのくらいの間隔で離散化してるんだろう。
高さ方向にどのくらいの細かさでどのくらいの高さまでメッシュを切ってる？。

空気の粘性をどう考慮してるんだろうか。ニュートン流体？
初期入力条件は？収束条件は？
並列計算にするのにどうやって分割した？


やっぱり、こういうのを作れる人たちってエリートだよなーって思うよ。

>>88
首根っこの太さが似たような条件では
トポロジーに万能のものはないよ

こないだの、MEGAQUAKE見て、
地震の解析にコンピュータ大活躍でわろた。

たかじんみると、地震予知に可能性なさそうに思えるけど、
MEGAQUAKEみると、地震予知は近い将来期待出来るのではないかと。

計　算　機　が　ど　れ　ほ　ど　速　く　な　ろ　う　と　も

計　算　す　る　連　中　が　ア　ホ　な　ら　成　果　ゼ　ロ

>>91
ま、お前みたいな無能には一生理解できないだろうけどなｗ

>>94
そのとおり。計算機がどんなに凄くとも計算モデルがデタラメなら
計算結果もデタラメにすぎない。

計算機は確定された予測モデルで効率よく予測するわけで予知
する道具ではないね。

>>96
GIGO （garbage in, garbage out）ですね。

このコンピューターを競馬予想に特化させたら的中率どれぐらい？

予測、予報よりも予防してくれ

>>89　京はHPCCのFFTで、1/10のサイズで実行効率1%ですがｗ
フルサイズではどうなるんだろなｗ

>>89
>仮に、この最も距離が離れたノード間でパケットを送ると、中間のノードの 
>通過に5.6μs、これに送信と受信側での計0.5μsが加わり、トータルで 
>6.1μsかかるという計算になる。もちろん、これは最悪のケースであり、 
>平均的にはこの半分程度の時間となる。また、隣接通信が大部分という 
>アプリケーションでは0.5μsで通信ができることになる。 

お前、それが、

>>88
>遅延時間はホップ数に比例するし、パケットの先頭をみてすぐにフォワードすることで比例 
>定数が減らせるのは通信がほとんど行われていない場合だけ

の場合だってことも理解できずに具体的数値とかいってんの？

実際の性能は、

>ある程度以上のトラフィックがあれば、HOLブロックにより、パケットの大きさとリンク速度が 
>同じなら、ホップ数≒遅延時間となるので、具体例を考えるまでもない 

なので、ぼろぼろ

>>92
FATREEででもなきゃあ、首根っことかないんだが？

１秒間の使用料金はいくらぐらいになるのかな。

この表はSR16000 M1 導入前のものからまだ更新されていないようだ

数値予報モデルの種類
ttp://www.jma.go.jp/jma/kishou/know/whitep/1-3-4.html

>>100
1PFLOPS以上で1%を超えるシステムは例えばどんなものがあるのかな

>>101
101には具体的数値にたどり着く能力がありません　でいいんだな？

>>104
まー、それでも二位に5倍の差を付けてるし、本格運用前だから
今後は更に実行効率が上がるからいいんでね。フルシステムで計測したら
NEC製のベンチマーク専用機の100倍は行けるでしょｗ

>>105
105はHOLブロッキングのことすら何も知りません、でいいんだな

>>107
ここは科学板なんだから漠然と概念だけじゃ不十分で数値は必要だよ

>>104 だれもそんなこと言ってないｗ
ノード間通信能力を要するベンチマークで京は全く値が出ていないという事実そのもの。
やれるところだけやりました、ってだけなのに、十分性能がでるなんてほざくなってことだｗ

>>109
このスレには
　帯域の数値比較を軽視し
　遅延の数値を紹介するわけでもなく、
　ベンチマーク値比較を紹介するわけでもなく
Power775が京を圧倒するとほざいている人がいるが、それについての感想は？

>>110 SR16000M1を使ったことないので知らない。
カタログ値でPower775の方が可能性があることと、メモリ・通信を要するアプリを抱える研究所が
この系統を伝統的に使っているのも事実。
圧倒しないといいたいのであれば、あなたこそSR16000M1の数値を出せばいいだけ。

ちなみに>>111の無能が言ってることは全部うそっぱちね
FFTの京の実行効率は10%超えてるし、項目に拠っては90%を超えてるものもある
そんな阿呆の言うことに付き合う必要はないよ

現行のプログラムで精度を上げて明日の天気を5日後に出すようなプログラムを実行したら「明日」の天気は当たるの？
当たるプログラムを高速化できるなら意味が有るけど。

>>113
>103　に、主な数値予報モデルの概要　って表が載ってる。
それによれば、常時数種類の異なる精度の予報計算をやってるようだな。

一番詳しい精度のものについて

>従来予測の難しかった規模の小さな現象の予測を目的とした
>局地モデル（別添参照）の運用を新たに開始する予定です。

>第２図は、平成23年７月新潟・福島豪雨の例です。
>水平分解能５キロメートルのメソモデルよりも、水平分解能２キロメートルの
>局地モデルの方が、より実際に近い降水を予測していることがわかります。
http://www.jma.go.jp/jma/press/1205/24c/20120524_naps_renewal.pdf
http://www.jma.go.jp/jma/press/1205/24c/20120524_naps_renewal.html

ということらしい

で、京はどこいった？

>>108
漠然と概念wwwww

定性的議論できっちり決着ついてるのに、それが理解できないやつが、科学を騙るな

最初の頃は気象庁の計算機はＩＢＭだったと思ったがな。7090？とか

>>112 はいはい、嘘を言ってるのはだれだｗ
京のHPCCの結果
FFT　実行性能/理論性能　34718.5 GFLOPS/　147456コアx8GFLOPS ≒3%
http://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=459
京のフルノードは8万ノード(×8コア)　1/4サイズに落としているにもかかわらず、この結果。
早く全ノードを使ってのバケツリレーをやってみせてよｗ

スーパーコンピュータ「京」のMPIと低レベル通信
http://img.jp.fujitsu.com/downloads/jp/jmag/vol63-3/paper11.pdf
http://jp.fujitsu.com/about/magazine/backnumber/vol63-3.html

MPI 隣接　1.27us 1.27-0.5= 0.77us(MPI over head)

両端ICC（中継ICCと処理時間が異なる）とMPI over head の合計に比べて
1中継のlatencyは約1/13 にすぎない。全CPU対象だと平均約28中継。
ICC数と遅延が比例しているとは言えないね
　1.27 + 0.1x[ICC数] us

全CPU範囲、最悪0.5+58x0.1=6.3us、MPI 7.07us
平均3.3us、MPI 4.07usくらい

Power775 MPI
　1.1us ((4-1)CPU (1-0.25)MCM)　CPU-CPU　
　1.6us ((32-4)CPU (8-1)MCM)　CPU-HUB-HUB-CPU
　？us ((128-32)CPU intra s-node)　CPU-HUB-HUB-CPU
　？us ((65536-128)CPU inter s-node)　CPU-HUB-HUB-HUB-HUB-CPU
ttp://mmc.geofisica.unam.mx/femp/Varios/SC11/src/pdf/papers/tp39.pdf
ttp://mmc.geofisica.unam.mx/femp/Varios/SC11/src/html/papers/tp39.html

>>118
全ノード使ってないってことは、使うと、実効理論比が低下するだけじゃ済まないで、実効
FLOPS自体が低下するってことだろ

>>114
情報感謝です。pdf読んだ。
グラフで降水量の予測精度が観測データに近いのに驚きました。これは期待。

>>122
それっていかにも、精度大幅アップ（当社比）って結果だよな。
気象庁（室井）の、素人にはこんなの見せとけば大喜びだろっていう、
バカにした態度が、ミエミエのようにしか思えんがな。

柏キャンパス地下の７０００はどうなったんだ？

>>122
シミュレーションで過去の結果を合わせ込むのは可能。
というか、それが出来なければ全く話にならない。

しかし、だからと言って将来の予測が出来るかどうかは別問題。

予報手法の検証なんだから、過去のある時点よりも未来の気象を
未知としてそれよりも過去のデータだけから計算する。

滅茶苦茶たくさんのデータについてこれをやって
その予報が当たる確率が高ければ、
本当の未来に対する確率も高いことを期待して良い

>>98
ぶっちゃけ、オッズからリターン計算して最適化した方が早いとは思う

>>126
だから、その「過去のデータ」の何がどれくらい効いてくるのかってのを結果を知ってるから最適化出来るんだよ。
後、境界条件とかもね。
しかし、それが本当に正しいかどうかは分からないから、本当に予測に使えるとは言えない。

予算使ってるから何かと宣伝しないといけないからな。

FFTの実行効率で勝負するなら、SR16000のFFT実行の効率は何%だ？

SR16000 M1 (Power775)はシステムサイズが変わると
トポロジーがガラッと変わる。FFTの効率もガラッと変わる。

小規模、例えばこれ
ttp://www.cc.u-tokyo.ac.jp/system/smp/smp_intro.html
みたいに56MCM（224CPU）なら全てのMCMと全てのMCMが
2xHUB経由で結ばれていて、かつ、HUB間は全て専用・非共有だから
FFTはかなり好成績が期待できる。
MCMと一対一で存在するHUBが56本足だからこれができる。

気象庁やBlueWaters計画のシステムはトポロジーが↑とは異なる。

なぜなら、完全結合できるMCM数は57（約56TFLOPS）まで。
それよりも大きなシステムになると、中継HUBを経由するようになる。
中継HUBは複数の経路に共有される。CPU数が200強までの
システムに比べたら相対的にFFTの効率は低下する

あ

ES2が今度TOP500で何位になるか楽しみです。

>119 >120
一つのCPUから見て1.6us以内で届くCPUの数

BlueWaters計画 191 cpu = 4(MCM)+28(畳)+96(intra s-node)+64(other s-node) -1
K-Computer 519 cpu （後述）

京は6次元だから数えるのが面倒くさい。隣接MPI（2xICC） 1.27us（>119）。
1.6us 以内だと中継ICC 3つ(両端含めて5)までOK（>89のリンク先）。
3次元メッシュを中継個数で制限すると範囲は8面体状になる。
8面体の大きさ毎の節の数　1、7、25、63、129
残りの3次元は12node のコンパクトな接続（>89のリンク先）
12 = 2 + 5 + 4 + 1（距離毎でまとめ。1は自分自身）
中継3xICCで届くcpu数は
　(2x7 + 5x25 + 4x63 + 1x129)-1 = 519 cpu　　1.6us
以下同様に
　(2x1 + 5x7 + 4x25 + 1x63)-1 = 199 cpu　　1.5us
　(2x0 + 5x1 + 4x7 + 1x25)-1 = 57 cpu　　1.4us
　(2x0 + 5x0 + 4x1 + 1x7)-1 = 10 cpu　　1.3us（隣接）

519個のCPUについて、大半のCPUには1.6us 以内で複数の経路がある。

これは「気象計算」という立派な目的のためのスパコンなんだから
京とかどうでもいいじゃん

未だに機械旋回式のドップラーレーダーが最新とかいう現状を何とかしろよ。
さっさとフェイズドアレイに切り替えろ

>>61
500TFLOPS超えのPower775がtop500 にお目見えしたけど
Rmax/Rpeak が0.73 くらいしかないね

>>135
京は、通信量が多いとHOLブロッキングで遅延が激増するから、話にならんよ

天気予報ごときでどんな大層な計算が必要なのかな

>139
京　AlltoAll/理論バンド幅　　〜67%　〜90%
http://news.mynavi.jp/photo/articles/2012/02/21/kei_computer/images/006l.jpg
-------
AllReduce

京 18000CPU　15us
http://news.mynavi.jp/articles/2012/02/21/kei_computer/001.html

Power775 512CPU　18us
http://domino.research.ibm.com/library/CyberDig.nsf/papers/18BCD8D0191281A58525799C00508FA8/$File/rc25259.pdf

>>141
ど素人？

>京　AlltoAll/理論バンド幅　　〜67%　〜90% 
>http://news.mynavi.jp/photo/articles/2012/02/21/kei_computer/images/006l.jpg 

京の理論バイセクションバンド幅が小さいのが問題なのに、その90%とか言われても、、、

>AllReduce

って、通信量は極小

>>142　
狼少年てあるよね

バンド幅！　>61　　　→　別に。　>76　>84　
ホップ数！遅延！　>72　→　別に。　>119 >120 >134 >135

HOL blocking！　って言われても、本当かなぁ？　ってなるよ

>>143
>狼少年てあるよね 

いや、お前は、一応プロの羊飼いである狼少年のレベルじゃなくて、ただのど素人

>バンド幅！　>61　　　→　別に。　>76　>84　 

バイセクションバンド幅なんだけど？

バイセクションバンド幅の意味すら知らないってことだよね

>HOL blocking！　って言われても、本当かなぁ？　ってなるよ

そりゃあそうだろ、ど素人なんだから

詳しいのは誰かとかあまり興味ないんですよ。
現物の出した結果を知りたい。
高性能になることを疑われなかったのに
そうじゃなかった例というのもあるから実証が尊ばれるわけで

>>144 alltoallのバイセクションバンド幅を自慢したいのなら、
1536プロセスの結果なんか出さずに、それこそ8万ノードのデータだせよｗ
こんな小さな体系で、バイセクションバンド幅確保できてますって、
それこそバカ丸出しじゃないかｗ

>>145
>現物の出した結果を知りたい。 

バイセクションバンド幅やAllReduceの意味すら知らずに、結果の数字だけ知って、、、

>高性能になることを疑われなかったのに 
>そうじゃなかった例というのもあるから実証が尊ばれるわけで 

京は最初っからLINPACK以外ではろくに性能がでないことはわかりきってて、実際そうなった

>>146
>>>144 alltoallのバイセクションバンド幅を自慢したいのなら、 

え？

売れない京の営業に必死なお前、つまり、ID:H4D+tdUj、じゃああるまいし

>>147

> 京は最初っからLINPACK以外ではろくに性能がでないことはわかりきってて、実際そうなった
去年LINPACKじゃなくて実アプリでゴードンベルを取っているのはどういう理由なの?

>>148
>去年LINPACKじゃなくて実アプリでゴードンベルを取っているのはどういう理由なの?

実アプリwwwwww

また、ID変えたのか

電子状態の計算なんて、LU分解がほとんどだろ

モンテカルロ法なんて、LINPACKより楽に性能だせる実アプリだしwwwwwwwwww

>>149

別人なんでほんとに知らんのだけど。

そんなアホでもできるとでも言いたげな計算が評価されたのはなんでなの?

>>149
＞電子状態の計算なんて、LU分解がほとんどだろ

昔はね。そのやり方だと電子数の増加に対する計算量の増え方が
急激なので”少ない”電子数のときしか使わなくなっている。
最近の原子数の多い計算はSchroedinger方程式も Poisson方程式もリアルスペースで解く。

>146　はアンカーが不適切なんじゃないの？

8万のデータがあるなら知りたいよ

>>150
>別人なんでほんとに知らんのだけど。 

それが本当だとしても、「ほんとに知らん」ど素人が二人に増えただけ

>>151
>昔はね。そのやり方だと電子数の増加に対する計算量の増え方が 
>急激なので”少ない”電子数のときしか使わなくなっている。 
>最近の原子数の多い計算はSchroedinger方程式も Poisson方程式もリアルスペースで解く。 

え？

act.jst.go.jp/info/h13cst/hyouka/h13-m03.pdf
密度汎関数法（Density Functional Theory: DFT）では、多電子系の基底状態が一電子密度の汎関数と
して与えられることが示され、具体的に有効一電子方程式（Kohn-Sham方程式）を解くことにより、多
くの物質群で極めて精度の良い計算結果が得られている。しかしながら系のサイズNに対して、計算時間
はおおよそN3となり、数千個の原子群の計算は不可能であった。しかし、物理及び化学の知見によれば、
共有結合あるいは金属結合においてさえ、局所的な相互作用によって物質の構造が決まっている事が示唆
される。すなわち密度行列（density matrix）演算子を実空間で表現すると、２点間の距離が大きくなる
と、その値は急激に０に近づくことが示唆される（密度行列の局所性）。このことを用いて、計算時間が
オーダー(N) の手法の開発が期待される。

第２の手法も密度行列の局所性を利用したものである。密度行列とグリーン関数の間には、正確な関係
式が存在する。この手法ではグリーン関数を実空間で表現し、それを連分数展開し、有限項で打ち切るこ
とによりオーダー(N)が達成されている（リカージョン法）。その際にはブロックLanczos変換が有効に用
いられている。また系のクラスター分割とＬＵ分解を利用したオーダー（Ｎ）法も開発されている。やは
り103原子群からなるカーボン・ナノチューブ(CNT) の密度汎関数法計算が可能となっている。

なんだが？

ゴリラげい雨

>>152 まだ恥さらしたいかｗ
alltoallでもバイセクションバンド幅の90%を維持できいますって自慢してるバカがいたから、
それは高々、1536プロセス内での話だろって言ったわけだｗ

>>153
賞の計算はRSDFTでやったものだと思うが
RSDFTの主要部分はLU分解ではないはず

>>153

素人なのは十分承知しているので単に尋ねたいだけで
そんなに馬鹿にするような計算で他にも候補があっただろうに
なんでゴードンベルが取れたのかということが素朴な疑問への
説明はないように思えるが。

>>156
それじゃあ、>>151が全否定されたことの言い訳になってないし、「また系のクラスター
分割とＬＵ分解を利用したオーダー（Ｎ）法も開発されている」ってのは、LU分解主体で
も解けるってこと

LU分解でも解ける問題が、LU分解ではないが同様に通信量の少ない方法で解けても
何の不思議も無いが、研究としてたいした意味もない

>>157
>そんなに馬鹿にするような計算で他にも候補があっただろうに 

なかったんだろ

LINPACK専用機で効率的に解ける実アプリなんて、限られてるからな

このままLINPACK専用機にこだわっても、先は無いってことだ

Blue waterは完成していたらどうだったのかね。同じPOWER7だけど。

>>159
>138　に片鱗が見えている

>>158
その文面でレフェリーよりも自分を支持しろといわれても無理だよ

A massively-parallel electronic-structure calculations
based on real-space density functional theory
http://www.sciencedirect.com/science/article/pii/S0021999109006676

>>158

> >そんなに馬鹿にするような計算で他にも候補があっただろうに
>
> なかったんだろ

いやゴードンベルの候補だって。
あなたの言う通り京がLINPACKより下らない計算しかしてないなら
なぜ他の計算機より評価された?

>>161
たいした意味のない研究でも査読通ることはいくらでもあるし、それまでLU分解で解けると
知られてなかったなら、それなりの意味はあるだろ

後でLU分解で解けるとわかれば、最初の論文の価値は落ちるがな

>>162
そもそも受賞したのは、ゴードンベル賞のピーク性能のやつじゃねーか

それなら、基本的にLU分解で解ける問題しか受賞対象にならんが、LU分解で解きました
だとやはり受賞は無理だろうから、そこがどう（意図的じゃなくても）隠蔽されるかだけの問
題になってねーか？

>>163

> だとやはり受賞は無理だろうから、そこがどう（意図的じゃなくても）隠蔽されるかだけの問
> 題になってねーか？
隠蔽しただけじゃねえかと簡単に言うがそれなら審査員はあなた以下のボンクラ揃いということ?

>>163
あともう一つ質問

> それなら、基本的にLU分解で解ける問題しか受賞対象にならんが、LU分解で解きました

2002にESが受賞した問題もLUという話なの?

計算する格子を小さくするんだろうな。
元データが不正確なら意味ないけど。

ゴードンベル賞って長崎大のラデオンたくさんくっつけたスパコンが取ったやつか

Bisection bandwidth
仮想Power775 s-node x 360、Rpeak 11312824.32GFLOPS
　180 x 180 x 2(dir) x 10GB/s = 648TB/s

京　Rpeak 11280384GFLOPS
　36 x (16+1) x 12 x 4 x 3、どの軸方向も1接続あたり2(dir)x5GB/s
　　　　(16+1) x 12 x 4 x 3 x1(non-torus) = 2448　24.48TB/s
　36　　　　　　x 12 x 4 x 3 x2(torus) = 10368　103.68TB/s　8:9 分割
　36 x (16+1)　　　 x 4 x 3 x2(torus) = 14688　146.88TB/s
　36 x (16+1) x 12　　　x 3 x2(torus) = 44064　440.64TB/s
　36 x (16+1) x 12 x 4　　　x2(torus) = 58752　587.52TB/s　1:2 分割

>>164
>隠蔽しただけじゃねえかと簡単に言うがそれなら審査員はあなた以下のボンクラ揃いということ? 

ボンクラというより、政治的に賞を出さないとまずいから目を瞑ったってとこだろ

>>165
>2002にESが受賞した問題もLUという話なの? 

LINPACK番長の話で、ES持ち出すとはwwwww

>>169

> ボンクラというより、政治的に賞を出さないとまずいから目を瞑ったってとこだろ

どういう政治的な意図があるんでしょうか?
富士通から学会に大量のスポンサー料を貰っているとか?
他にも政治的に下らない研究でゴードンベルを貰った例を上げてもらえますか?


> LINPACK番長の話で、ES持ち出すとはwwwww

あなたが次のように書いてるからESのときも同じなんですかと聞いたんですが。
> それなら、基本的にLU分解で解ける問題しか受賞対象にならんが、LU分解で解きました

>>170
>どういう政治的な意図があるんでしょうか? 

ゴードンベル賞受賞者なしなんて事態を防ぎたい意図くらい、あんだろ

>あなたが次のように書いてるからESのときも同じなんですかと聞いたんですが。 

馬鹿は、もうちょっと休み休みやれ

>>171

> ゴードンベル賞受賞者なしなんて事態を防ぎたい意図くらい、あんだろ

政治的意図というのはそれだけなんですね。
でも部門によっては受賞者なしの年はありますよ。

> >あなたが次のように書いてるからESのときも同じなんですかと聞いたんですが。
>
> 馬鹿は、もうちょっと休み休みやれ

で同じなんですか。それとも違うんですか。

>>172
馬鹿は、もうちょっと休み休みやれ

>>173

馬鹿な質問かもしれませんが質問内容は明確ですので
あなたには答える能力がないと思っておきます。

>>173
「京は無駄で無意味」って言いたいだけだもんな
そりゃ調べない考えないになるわな
レスするだけ無意味だの

と、ど素人の妄想でしたとさ

ほんと、レスするだけ無意味だわ

どうもこのスレ見る限り素人の妄想が多数派のようなので、
この先もアンチさんの言うLINPACK専用機が国策スパコンとして作られ続けるんじゃないかね。

まあ日本は民主主義の国ですから。何も言わない自称専門家さんの意見なんて……

top500 のシステム数で圧倒的多数派は3D トーラス以下、
みすぼらしい接続のシステムばっかりだよ。調達するときに
LINPACK/$を重視するからそうなるのだろう

相対的に見れば京やBG/QはLINPACK以外でも性能の
落ち込みが酷くならないようにと頑張っている方だよ。
5次元とか組んで少しはましなシステムにしようとしている

両極端に、安さ最高、接続最低の汎用サバに毛の生えたものと
SXのような、相互接続最高、価格は高嶺の花、というのがあり
他は全部その間のどこかを目指すしかない

中間のものはどれも、実用性が低いという批判も、割高だという批判も
受ける羽目になる。どちらの批判もバカでもできる

>>178
中間なのに、alltoallでバイセクションバンド幅も十分確保できるよってほざくから
アホは休み休み言えって馬鹿にされてるだけだろｗ　それすらわからないかｗ

無駄なコンピュータシミュレーションと思うもの
第一位　地震予測
第二位　１週間先の天気予報

いや、第一位は何と言っても気候シミュレーション。

>>179
>168　のPower775システムは仮想であって、現実に10Petaの
Power775を稼動させている組織はない。ないものの性能がよくても
しかたがない。今後10Peta規模で稼動する見込みもない。

見込みがない理由。Power775は電力効率が悪いから最大級の
システム構築はどこも二の足を踏む。既にPoerw7+のうわさが
聞こえて来ているから今から無印システムの企画は立ち上がらない。
+のシステムはバンド幅とFLOPSの関係が無印搭載システムとは
変わる可能性が高い。

>>182
まだアホを晒したいのかｗ　Power775のことなんか言ってない。
はやく、全ノードつかってのバケツリレーをやってその性能を示してみたらどうだｗ
alltoallでも十分バイセクションバンド幅が確保できるんだろｗ

これを設置するよりドップラーレーダーでセンサーを強化するほうが
はるかに精度が上がる。

どんだけ原始的なセンサー情報をスパコンで計算しているか学べ。

>>16
95%当たれば充分だろ
お隣りの土人国よりいいよ

それとも降水確立を理解してない小学生か？

>>183
同じことばかり吠えてないでいくつかの都合の悪い質問も答えてみたら

>>183
>>168みるだけで、バイセクションバンド幅のなんたるかが全くわかってないアホなのは
明らかなのに、何をいまさら？

ヒュートランより23倍ほども速いのか
かっけえ

>>186
ついに、自分を批判するのは特定の一人と、妄想の世界に入ったかｗ
都合の悪い質問に答えないのは、お前じゃないのかｗ
俺は、京はalltoallを使用するアプリでは、明らかに不得手で使い物にならない、
ということしか言っていないんだがなｗ　

>>189
そこまで妄想広げられるなんてすごーい

>>190　おまえのバカ丸出し発言ｗ　富士通の営業かｗ
>366 ：名無しのひみつ：2012/07/04(水) 00:48:10.34 ID:9khSt6+N
> 新しい動きとして一般利用枠に計算能力の6.7倍の応募があったことを踏まえて
> ガラクタ呼ばわりする人は批判してみよー
課金したら、研究者はほとんど申請しないだろなｗ　タダだから申請してるだけｗ

>>191
ちょっと前まで使いものにならないから誰も使わないと言っていたのが
最近では暇潰しで申請書類を書いてるに変わったのか。

>>192
だから、俺がいつそんなことを言ったんだｗ　

次に産業分野の利用は官庁関係の付き合いで仕方無くと言うんだな。

age

全てのノードを直接接続できないから、多少の変形は可能でも実際には
３次元に接続する以外には接続できない。

ESのように巨大なクロスバーで接続するのは今後は現れない、みな
同じような条件で如何に速度を稼ぐかになる。

主題はソフト側を工夫してその障害を乗り越える事になる。

>>196
効率1%程度の現状で、今後ソフト側で対処しますってかｗ
そんなんだから、10Pを必要とする理由は、計算機屋が1位を取りたいだけなんだろって言われるわけだｗ

1%は低いと誰もが思うだろうけど、では何%なら高いのかよくわからない。
密結合クラスターでやっても10%程度の処理なら巨大ノード数で1%超えればわりと高効率だし。

>>198
>密結合クラスターでやっても10%程度の処理なら巨大ノード数で1%超えればわりと高効率だし。

そういう場合って、疎結合でノード数増やしても効率はノード数に反比例して低下するんで、
「わりと高効率」でもなんでもないってば

結局、ノード数増やしてTPPを増やすのに金をかける野依・富士通路線は予想以上の大失
敗で、密結合に金をかけるNEC路線しかないってこった

>>184
そうだよな
少ないサンプリングデータを元に複雑系を対象に計算をせざるを得ないから予想できない
いち早く兆候を検知する仕組みが開発の方向性としてはｺｽﾄﾊﾟﾌｫｰﾏﾝｽが高い

>>199
それはわからんではないが、帯域依存が低い処理で巨大ノードが勝つだろう。
それなら処理需要をどう見積もるかの問題がある。

まあ京は日本の国策スパコンの割には演算器寄りだろうし、
次はES路線に近いところに回帰するだろう。

>>201　そういうことだ。で本来なら、京では不向きなアプリでも、LINPACKで一位をとりたい、という理由で、
京で我慢しろって強いてるだけなのに、ここではアホが一生懸命、alltoallでもバイセクションバンド幅が確保できるとか、ほざいてるってだけｗ
しかし、帯域依存が低い処理って言っても、10万並列で通信が目立たない処理ってのも、強スケーリングじゃまずありえない。
並列化率99.9998%の処理って、元々独立な処理ってことだろｗ

でも当たらない天気予報

空を見つつ肌で空気を感じ取り
「うーん　今夜から明朝にかけて雨かのう・・」
とつぶやく爺さんの方が上

だからそれでいくらの売上を達成してるんだ？
小さなHPC市場でシェア何％だ？
インテルやAMD、IBMの営業利益を知ってるのか？

富士通のＳＰＡＲＣはSunMicrosystemの製品に使われてる。けど、少ないんだろうな
あれから国内で導入例たぶん増えてるけど

　
化学者もグルになって気象テロを隠ぺい

http://ichiba.geocities.jp/gbsg0309/02/3/32.html

これまで、「ヨウ化銀」の散布などと言って、

トンチンカンな説明で大衆を惑わした。

>>203
観測精度が何十年も前のレーダーなんだし。最新のドップラーレーダー使えよ。
長期予測じゃ地熱の変化や宇宙線や太陽風の影響は無いとまで
断言している愚かな計算だから。
宇宙線の量で雲の生成確率が恐ろしくかわるのにパラメータにはいっていない。
何故なら観測していないからとか、太陽の黒体放射は変化しないという理屈で
バンアレン帯の外でしか観測が困難な太陽風も極地に落ちる量でしか観測していない。

ほとんどの問題は計算するパラメータの採取がデタラメってことで計算じゃない。

スパコンを新調して確実に良くなるのは短期や局所の精度なんだろうな。
長期は ambiguity の排除ができてない

米海軍の予報精度向上実績　24-120時間　1988-2011年
http://japan.cnet.com/news/society/35018492/6/

もう10年も前から
http://www.weather-service.co.jp/weather/srf/index.html
ここの降水短時間予報を見ている。気象庁発表のを表示しているだけだが、
ここが自分にはいちばん見やすい。
最近は前より雨雲の動き予想が正確になってきたと思うが、6時間先でも
まだ外れることもある。（昔は3時間先までだった）
今度のスパコンはまだこの戦力になってないと思うが、参戦の暁には
6時間先がもっと正確になるかな？

まちがった計算を何兆回やっても、答えは間違ってる

御意

wwたしかに

スーパー計算機開発のための名目なんだよきっと
この分野では気象のプロより計算機科学のプロが跋扈してるんだろうな

当たるか当たらないかはセンサーとモデルの問題で、
どれだけ具体的な予想ができるかは計算機の能力にかかってくる。

精密な予言をして外したらこっ恥ずかしいが、当たったらすごい。
……計算機の能力上がるのってハードルが上がるだけか。

いち早く速いスパコン入れたけど旧式使ってた国よりも
予報当てられなかった国もあります

１：ＧＰＵ使えないのか？
２：気象計算のボトルネックはどこか？差分法だとすればメモリ転送能力？
３：計算の主な部分が極めて規則正しいなら、専用のハードを作れば
加速できないか？

計算屋ばっかりだな
たとえば・・
いつも発表される台風の進路予想というのがあって
現在位置からだいたい直線でもってどこを通るとか予想ラインが示される
それをみて俺はいつも考える
今の時期と気圧配置からだともう少し東にぶれるはずだから列島は外れるな〜　とか　
だいたい俺の予想が当たってる

九州で洪水

で、洗濯物を仕舞わねばならないほど降るか降らないかを、９０％以上の確度で予報できるようになるのはいつなんだろ。
３０％の”降水確率”で、大降りに何度遭遇したことか。

GRAPEだと、専用設計で速度を上げる余地があったが、

天気予報気象用で完全専用設計、他の計算は一切考慮しない、
として、速度をあげられる余地があるかなあ。

あったら面白いけどな。
精度が問題にならない連続計算は、アナログ計算機（オペアンプ）
ファジイ回路とか、なんかネタ無いかな。

>>217
いつも発表される台風の進路予想にもコンピュータが
使われているって知らんのか？

気象庁にいる名人予報官という人達も気象の長期的変動について
ゆけなくなってきたんだよ、だから数10年に一度の異常気象が
毎年起きるとか訳のわからんことを言ってる。

計算屋が必要なんだよ

>>220
ほら吹きはマキノだけにしとけよｗ　どこにGRAPEに余地があるのやらｗ
お得意のソフトが対応すればよい、であれば全ての計算機に余地があるよな。
GPGPUは既に、気象庁のメソモデルを使って、100TFLOPSの演算速度を出しているのに、
あえて、GRAPEを出すなんて、ほんと腐った連中だよなｗ

意外にも、GRAPEは京に貢献しているらしい。
ベクトルユーザは、京のスペックに必ずしも満足していないが、じゃあGRAPEをアクセラレータに使ったハイブリッドではどうか、
となると、とたんに、SPARCで結構です、と納得してもらえるらしい。
どうように、東工大の松岡さんも、TUBAMEはみんなのスパコンなんていってるが、GPGPUなんてほとんどつかわれてないだろ、
おまえのおもちゃか、って陰口たたかれても、じゃあGRAPEでとなると、やはり、GPGPUの方がまし、とみんな納得してくれるらしい、
GRAPEって何気に、使い道あったんだなｗ

GRAPEにそんな意義があったとはｗ
マキノは中学生の自由研究並み反原発活動を、天文学者の社会貢献って自己満足してるけど、
これって、いかにマキノの研究が意味のないものなのかを象徴してるようなもんだよな。
でも、GRAPEはしっかり社会貢献してたそうですｗ
あと、天文台の汚物を早く引き払ってくれたら言うことなしですな。
放射能とかほざいてる暇があったら、自分で出したゴミぐらい早く処分しろよｗ

このアクセラレータ案二つはGPUとGRAPEなのかな

23枚目
ttp://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu2/022/shiryo/__icsFiles/afieldfile/2012/06/11/1321983_9.pdf
ttp://www.mext.go.jp/b_menu/shingi/gijyutu/gijyutu2/022/shiryo/1321983.htm

>>225
両方とも、ゴミGRAPEベースｗ

GRAPEとは、Garbage Research Activity of PiPE に由来するらしいからｗ
これに拍車をかけたのが、GRAPE-DR。
DRとは、Deceit Revision に由来し、
もはやゴミ研究と認定されてしまった、GRAPEにおいて、
汎用かつ2PEを先駆けてとの詐欺補正をかけて、公金を騙し取ったプロジェクトのことｗ

>>227
わかりやすい説明だ、納得した。

昔、秋葉原で（当時人気のPC機種だった）AppleIIのコンパチを作るための
プリント基板が売られていて、それがオレンジとかグレープという名前だったと
思う。そのネーミングセンスを頂いちゃったのじゃなかったかな。

省エネ世界一になったら評価してやる。
省エネ世界一になったら評価してやる。
省エネ世界一になったら評価してやる。
省エネ世界一になったら評価してやる。
省エネ世界一になったら評価してやる。
省エネ世界一になったら評価してやる。

>>229
インベーダゲームのせいで、74245の入手に苦労しました。
Orangeは、拡張ボードの部分がなしのものでしったけ。
CPUとMemory以外はTTLでできているので、ビデオをまわりの回路図を見て感激しました。

上の方でSR16000M1 に比べて京がぼろぼろ説と
それに対する反論のようなやりとりがあるが
HPCCに同型の比較的大きなシステムが登録されたようだな

G-FFT/理論最大
　SR16000M1（Power775）
　　8047 GFlops / 1443.56352 TFlops = 0.557% base
　京
　　11003.4 GFlops / 1179.648 TFlops = 0.933% base
　　34718.5 GFlops / 2359.296 TFlops = 1.47% opt

ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=481
ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=456
ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=459

こりゃまた底辺の競争だなあ。
安物クラスタでも更に酷いのは、これ以下だというのが恐ろしい。

>>232
真の通信能力を見るなら、RandomRing Latency/Bandwidthじゃないか？

1 名前:名無しＳＵＮ :2011/04/02(土) 20:48:38.64 ID:Y+rXgelz
　福島第一原発の事故を受け、日本気象学会が会員の研究者らに、大気中に拡散する放射性物質の
影響を予測した研究成果の公表を自粛するよう求める通知を出していたことが分かった。自由な
研究活動や、重要な防災情報の発信を妨げる恐れがあり、波紋が広がっている。

　文書は３月１８日付で、学会ホームページに掲載した。新野宏理事長（東京大教授）名で「学会の
関係者が不確実性を伴う情報を提供することは、徒（いたずら）に国の防災対策に関する情報を混乱
させる」「防災対策の基本は、信頼できる単一の情報に基づいて行動すること」などと書かれている。

　新野さんによると、事故発生後、大気中の放射性物質の広がりをコンピューターで解析して予測
しようとする動きが会員の間で広まったことを危惧し、文書を出した。

　情報公開を抑える文書には不満も広まり、ネット上では「学者の言葉ではない」「時代錯誤」など
とする批判が相次いだ。「研究をやめないといけないのか」など、会員からの問い合わせを受けた
新野さんは「研究は大切だが、放射性物質の拡散に特化して作った予測方法ではない。社会的影響も
あるので、政府が出すべきだと思う」と話す。

　だが、今回の原発事故では、原子力安全委員会によるＳＰＥＥＤＩ（緊急時迅速放射能影響予測）の
試算の発表は遅すぎた。震災発生から１０日以上たった２３日に発表したときには、国民に不安が
広まっていた。

　気象学会員でもある山形俊男東京大理学部長は「学問は自由なもの。文書を見たときは、少し怖い
感じがした」と話す。「ただ、国民の不安をあおるのもよくない。英知を集めて研究し、政府に
対しても適切に助言をするべきだ」

　火山防災に携わってきた小山真人静岡大教授は、かつて雲仙岳の噴火で火砕流の危険を伝えることに
失敗した経験をふまえ、「通知は『パニック神話』に侵されている。住民は複数の情報を得て、初めて
安心したり、避難行動をしたりする。トップが情報統制を命じるのは、学会の自殺宣言に等しい」と
話している。

▽朝日新聞
http://www.asahi.com/national/update/0402/TKY201104020166.html

【気象】ゲリラ雷雨「お盆に注意」　東京は１２０回も？ウェザーニューズが予想[7/26]
http://anago.2ch.net/test/read.cgi/wildplus/1343267819/

>>232
G-FFT/理論最大
　SR16000M1（Power775）
　　8047 GFlops / 1443.56352 TFlops = 0.557% base
　　94855.8 GFlops / 1443.56352 TFlops = 6.57% opt
　京
　　11003.4 GFlops / 1179.648 TFlops = 0.933% base
　　34718.5 GFlops / 2359.296 TFlops = 1.47% opt

>>237　URL入れ忘れた

ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=481
ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=482
ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=456
ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=459

SX-9
　234.329 GFlops / 98.304 TFlops 0.238% base
　6942.39 GFlops / 98.304 TFlops 7.06% opt
　11876 GFlops / 131.072 TFlops 9.05% opt

ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=384
ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=385
ttp://icl.cs.utk.edu/hpcc/hpcc_record.cgi?id=421

やっぱり、京はぼろぼろｗ
全ノード使うと、optでも1%きったりしてｗ
Alltoallでも十分バイセクションバンド幅が確保できるんだろｗ

PC-8801 mkII SR 16000M1

HPCCのaward は % ではなく絶対値だから、京の関係者がHPCCに
興味があれば　>232　よりも多いノード数の結果を送るだろう。
今年秋なら主要四種のいくつかでベスト3に入れる見込みはあるからな。

Power775 に大きなシステムの計画は見当たらないからたぶん
award のトップは取れない。Sequpiaが四冠の可能性が高い。
まあ高い%を公開しておくことはPower775の宣伝にはなるかもしれない

>>98
入手できる要素数がそんなに多くないからPCでやるのと変わらんのでは。

>>242
興味があればじゃなく、10Pの必要性を主張したんだから、
全ノードを使ってエントリーするのは、必須、敵前逃亡は許されない。
それにSequoiaにだったら、勝てる可能性もある。

今日の天気予報も晴れだったが突然雨になった。
精度の上がった予測はまだ？「晴れ時々曇り所によりにわか雨」が最強か。
予報に確率論いらない。晴れと言ったが雲量0とは言っていないとか降雨0とは
言っていないとかそんなのばっかり。条件が難しいなら予報できないと言え。
自分や子供が突然の雨にぬれるのは予報が正しくないからだろう。98%とは思えない。

>>245
予報出来ないなら言うな　かｗ

じゃあ　目の前の箱か携帯を叩き壊したら
文明の利器なんて必要無いでしょ

>>236

ゲリラ雷雨防衛隊　今年もスタート
http://weathernews.jp/guerrilla/

最近の日本では長く続いた風習や信仰が廃れてしまっている。
昔の主婦は、親から伝わるぬかの苗床を大事に育ててたくあんを
つけていたが、そのような乳酸菌ベースの健康食品の風習も今まさに
廃れつつある。

照る照る坊主に明日の天気が晴れますようにと願をかけて吊す。
そうして願いを叶えて呉れなかったら、斬首するというのがあり、
童謡にも歌われている。

さて天気予報が外れたら気象予報士の首を切る訳にはいかないとあれば、
スパコンの

マジで天気予報が糞すぎる
広い範囲に当たり障りのない予報

しっかし当たらんねー天気予報
半日先の予報すらほぼ100%の確率で外してる

関東はしばらく涼しい日が続くと言ってたじゃないですかああ？
今日の東京34度なんですけどおおおおおおおお？

京速は使いっぱなしにできないしな。
気象庁だと、常用のをいつも手元にしておかないとな。
このぐらいが丁度いい。モデル化をがんばれ

それよりモデルＭ１って名前はどうなのよ
普通機種名の次のＭはモデルって意味だろ

福一で、気象庁は国民の敵である事が暴露された
そんな気象庁が、国民のため働くとは思えん

>>246
そりゃあ別の話だろ