アカウント名:
パスワード:
同一ノード内の並列化にはOpenACChttp://www.openacc-standard.org/ [openacc-standard.org]とかOpenMPといったものがあるし、ノード間ではOpenMPIといった規格があってこれらは普通のPCでも使えなくはない状況。敷居が下がってきてるんで、割と普通のプログラマなら少し頑張ればスーパーコンピュータでコードが書けるようになりつつあるんじゃないかな。
こんなこと書くと、いや物凄いスキルが要るんだ無理無理絶対無理という人も出るに違いないけれども専用のスキルをもった職人しかコードが書けないスーパーコンピュータってのも意味ないですよ正直。
道楽で使ってみた事はあるけど、個人で試しに使ってみるレベルだと、頑張っても10ノードに届かないでしょ。既存のアルゴリズムを、スパコン用に置き換えたりするには、数学的センスと専門教育が必要だと思うよ。
単独のＰＣで動作させているときと違ってノード間の通信コストが大きい分、ノード間の通信を減らすような最適化も必要。１～数スレッドでしか動かしていないロジックを分解して、数百～数千スレッドにばらす事も必要。場合によってはこの過程で根本的なアルゴリズムの変更も必要だったりする。途中でノードが死んだりした場合とかを想定して、計算途中データの保存とかも考えなきゃいけない。トランザクション数もデータ量も生半可な量じゃない。
そのあたりのノウハウはスパコン固有のものだし、専門にやっている人が設計しないと、中々厳しいと思うな。コーディングするだけなら、いくらでもできるでしょうけど。
なるほど。やはり普段自分がPC上で行なっているプログラミングなんかとは全く別物のようですね。実際に触って遊べるようなスパコン・エミュレータ的なものはどっかに無いのかな。
最近のスパコンのほとんどはIAアーキ＆Linuxなので、エミュレータもなにもなく簡単に手に入りますよ。
プロセッサは Intel EM64Tがほとんど → http://www.top500.org/charts/list/37/procfam [top500.org]
OSはLinuxがほとんど → http://www.top500.org/charts/list/38/osfam [top500.org]
Interconnectは最近InfiniBandが増えてるけどGigabitEtherが最多 → http://www.top500.org/charts/list/37/conn [top500.org]
最近のスパコンでのプログラミングの特殊性はアーキテクチャ/OS の特殊性じゃなくて、上のnarunaru さんのコメント [srad.jp]のようにコア/ノード数が多すぎることに起因するんですよ。
# 一般的にどういう理解なのかは知らないです。あくまで自分の理解。
～数10並列で十分にスケーラビリティかだせても、数百とかそれ以上になるとnarunaru さんの書いたように通信量が増えてきてそっちがネックになるとか、計算自体の速度が速くなりすぎて通信のオーバーヘッドが無視できなくなるとか、比較的軽い処理だったので並列化する必要がなかったはずのところがネックになるとかその他もろもろでスケーラビリティが悪くなるってのが普通です。スケールを大きくするほど問題が(増えていく/顕在化する)ってのが本質的な難しさだと思います。
そーゆーのを回避するために全てのコアに分散させて行っていた計算をx %のコアだけで行い、残りの 100 - x % は同時進行できる別の計算をすることで実質的な通信量を減らしたりする、みたいな面倒なマネをしたりするのはもはや多分普通のこと。
# 大体ロードバランサ的なことを考えないといけなくなる。めんどい。
あとは一品物の巨大なものだとプログラムを書くときにスパコンのネットワーク構成まで考えないといけないってこともあります。小さいクラスタなら全ノードが一つのハブにぶら下がっているのが多分普通ですが、超大規模な奴だとまず間違いなくそんなことにはなっていません。物理的に近所なノードとしかつながってないでしょう。
その場合、all to all みたいな通信をしようとすると小規模なクラスタの場合より実質的に通信量が増えてしまいそうので、プログラミングするときにうまく考える必要があります。あとは上の narunaru さんのコメにもあるように、数万とかコアがあれば確率的に使っている最中の故障確率も必然的に上がるので、そういうエラー時のデータ保存も考える必要が発生するでしょう。小さいクラスタならこの辺の悩みとは無縁です。
# 考えてあってもあんまり害はないとは思いますが。
スパコンでまともにスケーラビリティが出るプログラムの開発ってムズいんですよ。こんなふうに。真面目にやると汎用性がなくなりがちなのはまぁしょうがないと思います。
ちなみに自分はこーゆーのはやってないです。つーか絶対やりたくないし、マトモにできそうにもない。これってそういえば元記事の内容と関係無い気がしてきた。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
スーパーコンピュータも使いやすくなるんじゃ (スコア:3)
同一ノード内の並列化にはOpenACC
http://www.openacc-standard.org/ [openacc-standard.org]
とかOpenMPといったものがあるし、ノード間ではOpenMPIといった規格があって
これらは普通のPCでも使えなくはない状況。
敷居が下がってきてるんで、割と普通のプログラマなら少し頑張ればスーパーコンピュータで
コードが書けるようになりつつあるんじゃないかな。
こんなこと書くと、いや物凄いスキルが要るんだ無理無理絶対無理という人も出るに違いないけれども
専用のスキルをもった職人しかコードが書けないスーパーコンピュータってのも意味ないですよ正直。
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:1)
道楽で使ってみた事はあるけど、個人で試しに使ってみるレベルだと、頑張っても10ノードに届かないでしょ。既存のアルゴリズムを、スパコン用に置き換えたりするには、数学的センスと専門教育が必要だと思うよ。
単独のＰＣで動作させているときと違ってノード間の通信コストが大きい分、ノード間の通信を減らすような最適化も必要。
１～数スレッドでしか動かしていないロジックを分解して、数百～数千スレッドにばらす事も必要。
場合によってはこの過程で根本的なアルゴリズムの変更も必要だったりする。
途中でノードが死んだりした場合とかを想定して、計算途中データの保存とかも考えなきゃいけない。トランザクション数もデータ量も生半可な量じゃない。
そのあたりのノウハウはスパコン固有のものだし、専門にやっている人が設計しないと、中々厳しいと思うな。コーディングするだけなら、いくらでもできるでしょうけど。
Re: (スコア:0)
なるほど。やはり普段自分がPC上で行なっているプログラミングなんかとは
全く別物のようですね。
実際に触って遊べるようなスパコン・エミュレータ的なものはどっかに無いのかな。
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:1)
最近のスパコンのほとんどはIAアーキ＆Linuxなので、エミュレータもなにもなく簡単に手に入りますよ。
プロセッサは Intel EM64Tがほとんど → http://www.top500.org/charts/list/37/procfam [top500.org]
OSはLinuxがほとんど → http://www.top500.org/charts/list/38/osfam [top500.org]
Interconnectは最近InfiniBandが増えてるけどGigabitEtherが最多 → http://www.top500.org/charts/list/37/conn [top500.org]
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:3, 興味深い)
最近のスパコンでのプログラミングの特殊性はアーキテクチャ/OS の特殊性じゃなくて、
上のnarunaru さんのコメント [srad.jp]のようにコア/ノード数が多すぎることに起因するんですよ。
# 一般的にどういう理解なのかは知らないです。あくまで自分の理解。
～数10並列で十分にスケーラビリティかだせても、数百とかそれ以上になると
narunaru さんの書いたように通信量が増えてきてそっちがネックになるとか、
計算自体の速度が速くなりすぎて通信のオーバーヘッドが無視できなくなるとか、
比較的軽い処理だったので並列化する必要がなかったはずのところがネックになるとか
その他もろもろでスケーラビリティが悪くなるってのが普通です。
スケールを大きくするほど問題が(増えていく/顕在化する)ってのが本質的な難しさだと思います。
そーゆーのを回避するために全てのコアに分散させて行っていた計算を
x %のコアだけで行い、残りの 100 - x % は同時進行できる別の計算をすることで
実質的な通信量を減らしたりする、みたいな面倒なマネをしたりするのは
もはや多分普通のこと。
# 大体ロードバランサ的なことを考えないといけなくなる。めんどい。
あとは一品物の巨大なものだとプログラムを書くときにスパコンのネットワーク構成
まで考えないといけないってこともあります。小さいクラスタなら全ノードが
一つのハブにぶら下がっているのが多分普通ですが、超大規模な奴だとまず間違いなく
そんなことにはなっていません。物理的に近所なノードとしかつながってないでしょう。
その場合、all to all みたいな通信をしようとすると小規模なクラスタの場合より
実質的に通信量が増えてしまいそうので、プログラミングするときにうまく考える必要が
あります。あとは上の narunaru さんのコメにもあるように、数万とかコアがあれば
確率的に使っている最中の故障確率も必然的に上がるので、そういうエラー時のデータ
保存も考える必要が発生するでしょう。小さいクラスタならこの辺の悩みとは無縁です。
# 考えてあってもあんまり害はないとは思いますが。
スパコンでまともにスケーラビリティが出るプログラムの開発ってムズいんですよ。
こんなふうに。真面目にやると汎用性がなくなりがちなのはまぁしょうがないと思います。
ちなみに自分はこーゆーのはやってないです。
つーか絶対やりたくないし、マトモにできそうにもない。
これってそういえば元記事の内容と関係無い気がしてきた。