アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
専用コンピュータ (スコア:3, 興味深い)
スパコンも含む、汎用コンピュータよりスピードが出るのは当然だと思います。
何フロップスといった尺度で単純に比較するのは既に意味がないということでしょう。
Re:専用コンピュータ (スコア:2, 参考になる)
ベンチマークだけはやたらと早い（が、実際に使ってみると今一つ…）というならともかく、
今回は実際にターゲットとなる用途があって、その領域ではこれだけの演算能力があると
いうことなのですから。
計算能力の尺度がないと、どのくらいでシミュレーションが完了するのかの見積もできないし。
生体分子屋から見ると (スコア:5, 参考になる)
その辺はかなり微妙な問題を含んでいると認識しているのですが……。条件によってはFLOPS!=実演算速度なんですよこれ。
GRAPEの基本アルゴリズムは力場の計算にO(N^2)のアルゴリズムを使用しています。
天体計算の場合には同じアーキテクチャでもO(N log N)やO(N)のアルゴリズムを利用でき、GRAPEのトップ性能をほぼ引き出して計算を行うことが可能です。というわけで天体計算には、このFLOPS数はほぼそのまま計算速度と取って良い。
それに対して、生体分子の場合には若干事情が異なります。
・天体より粒子数が多い。水ありだとN>50000とかよくある。
・天体と異なり密な系である。TreecodeでO(N log N)になりにくい。結果O(N^2)を使わざるを得ない。
・生体分子のシミュレーションに良く用いられる周期境界条件がGRAPE向きでない。GRAPEはEwaldをサポートしているが、トップスピードは出ない。条件を注意深く設定しないとクラスタに負ける(MDGRAPE-2の頃)。
・というか周期境界条件をまともな計算誤差で計算してベンチマークを取った例が無い(!)。
周期境界条件に関しては特に大きな問題で、GRAPEではより高度な(オーダーレベルで速くなる)アルゴリズムが使えないor使いにくい、という問題があります。まぁこれは並列度を上げるにはある程度仕方がないんですが……。
だからこのボードが「生体分子MDに」とか書かれると正直「?」という感じです。そもそも生体分子に限らず、FLOPS数だけを書いて分子動力学にも使える、とするのはだいぶミスリーディングです。
#FLOPS数の定義は浮動小数演算の回数ですから、この数字はオーダーに関係なく高くなるわけで。
で、思うのが、
・正直天体計算に特化しすぎている。生体分子にもう少し合わせたシステムを考えて欲しい。
・FLOPS表示で宣伝をするのは良いけど、実際の計算条件は制限が多いことを隠しているのは困る。怖くて手が出せない。
GRAPEシリーズの研究者は良くやっていると思うし、素晴らしい技術であると思うんですが、分子動力学や生体分子固有の問題にもう少し目を向けて欲しいなぁ、と。
もちろん、条件を限って使えばGRAPEは素晴らしいシステムだと思います。特に周期境界条件を考えなくて良い系には最適でしょう。
#この世界で生きていけなくなりそうなのでAC
#識者の方ツッコミお願いします
Re:生体分子屋から見ると (スコア:1)
Re:生体分子屋から見ると (スコア:1, 参考になる)
O(N log N)だとGRAPE以外の処理との比がO(log N)に減ってしまうのでO(N^2)の方がGRAPEの効果が大きいはず。
生体分子のシミュレーションで周期境界を使うのに計算速度以外の理由があるのでしょうか。結晶のようにターゲット自体に周期境界にする必然性がないなら、MDGRAPEで加速された孤立系計算でもよいのでは。
天文屋のコメント (スコア:1, 参考になる)
http://grape.astron.s.u-tokyo.ac.jp/~makino/journal/journal-2006-06.html#20 [u-tokyo.ac.jp]
生体分子屋ってアホですか？
Re:天文屋のコメント (スコア:0)
本当にスラドのモデって何の役にも立たないどころか有害ですね。なんで自分が知らないことをこうも自信満々に評価できる人たちばかり何でしょうね。
わざわざコメント付けてまで「参考になった」とか言ってるバカまでいるし。
それとも「素人を騙して煙に巻く方法が参考になった」んでしょうかね:-P