アカウント名:
パスワード:
> 流体の計算は分散処理といっても隣のノードとの同期が重要です。
富士通のプレスリリース文の中にある「高機能インターコネクト」がどの程度レイテンシを抑えられるか注目されます。また、SPARC64VIIは1CPU当たり4個のマルチコア構成で、国立天文台の牧野淳一郎先生のWeb記事 [artcompsci.org]によると、チップ内のコア間の通信や同期のオーバーヘッドを非常に小さくする努力をしているそうです。
同じ4コアのIBM POWER6プロセッサがクロック4.7GHz(最大)なのに対し、SPARC64VIIは2.5GHzと見劣りします。富士通は半導体部門を分社化してしまったので、今後クロックを上げていけるかどうかも興味深いです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
どっちが処理能力高いの? (スコア:2, すばらしい洞察)
参加者を募るのが大変だったり、機密事項が多かったり、何かとハードルがあるんですかね。
処理量とhttp://jaxagoods.net/ [jaxagoods.net]の商品が交換できるような仕組みにすると、 結構な人が集まり、スパコンより費用が掛からなかったりして。
Re:どっちが処理能力高いの? (スコア:2, 参考になる)
簡単に言えば1step計算したら隣のノードと計算結果を交換し、次のstepを計算する、
これの繰り返しです。
SETI@homeのようにある程度の長さの処理を単独のノードで計算できるようなものとは設計が違って当然です。
ノード間をLANでつないでもどうかなぁ、というレベルなのに、
家庭にあるPCがどんなに高速なものでも1Gbpsもでない通信速度では話にならないでしょう。
Re:どっちが処理能力高いの? (スコア:2, 興味深い)
> 流体の計算は分散処理といっても隣のノードとの同期が重要です。
富士通のプレスリリース文の中にある「高機能インターコネクト」がどの程度レイテンシを抑えられるか注目されます。また、SPARC64VIIは1CPU当たり4個のマルチコア構成で、国立天文台の牧野淳一郎先生のWeb記事 [artcompsci.org]によると、チップ内のコア間の通信や同期のオーバーヘッドを非常に小さくする努力をしているそうです。
同じ4コアのIBM POWER6プロセッサがクロック4.7GHz(最大)なのに対し、SPARC64VIIは2.5GHzと見劣りします。富士通は半導体部門を分社化してしまったので、今後クロックを上げていけるかどうかも興味深いです。
Re: (スコア:0)
バイナリ互換を重視したんじゃねーの?
っーか、国策という点でもIBMは入れてほしくないなぁ、日立経由でも。
Re:どっちが処理能力高いの? (スコア:2, 興味深い)
CPU/OSが同じでも構成が異なれば同一バイナリでは全く性能が出ませんので、最低でも再コンパイルが必要です。
それよりも重要なのはコンパイラとプロファイラで、富士通の開発部隊はコンパイラまわりの最適化とキャッシュヒット率からをノード間通信まで含めたチューニングに定評があります。
どちらかといえば富士通のコンパイラが最適化しやすいようなコードが既にあるから、というほうが近いかもしれません。
それに直接メールを打てば日本語で返事をくれるので、人的な繋がりがそのまま研究の効率になり、同じベンダの採用が続いているのでしょう。
kaho
Re: (スコア:0)
Re: (スコア:0)
何があるのかと考えてみると
A.単純だが大量の種類存在する(組み合わせが多い)
例:遺伝子・UD解析
B.一定の単位で区切ることができ相互の相関を考えなくて良い
例:SETI(時空列でオーバーラップさせる)、動画圧縮(Iフレから次のIフレ単位としてP/Bフレ作成とか)
こんな感じでしょうか。
過去分散が必要だった処理も1台の性能が上昇する事で1台で完結可能になれば、
流体もType.Bみたいな状態になるんでしょうかねぇ・・・
Re:どっちが処理能力高いの? (スコア:1)
climateprediction.netなんてはその方向に近いんですかね.
分散処理と言いながら個々の計算は数カ月かかるようなサイズで,でも多数のパラメータでの
計算を多数の計算機に割り振ることで並列化をするという方向なんで.
Re: (スコア:0)