アカウント名:
パスワード:
同一ノード内の並列化にはOpenACChttp://www.openacc-standard.org/ [openacc-standard.org]とかOpenMPといったものがあるし、ノード間ではOpenMPIといった規格があってこれらは普通のPCでも使えなくはない状況。敷居が下がってきてるんで、割と普通のプログラマなら少し頑張ればスーパーコンピュータでコードが書けるようになりつつあるんじゃないかな。
こんなこと書くと、いや物凄いスキルが要るんだ無理無理絶対無理という人も出るに違いないけれども専用のスキルをもった職人しかコードが書けないスーパーコンピュータってのも意味ないですよ正直。
アプリケーションを書いて使う人がいるいないの問題ではなくて、中規模のシステムを、きちんと性能を引き出せる形で構築したり、要求水準に合わせたコストで維持管理できるような、そういう人材がいるいないの問題なのです。
一見すると中規模というのは大規模と小規模のノウハウを折衷すれば良いように思えて、実際に使う人はもちろん商業的に管理やってる人ですら、その程度の認識しか持っていないことが多いですが、
アホみたいに金を注ぎ込む一品もののシステムとも、問題おこしてなければ問題ない並鯖とも違うアーキテクトやマネージメントが本来は必要で、そこに気がついてしまった不幸なユーザーが、そういう人材の不足に気がついて嘆いているというストーリーなのです。
こういう流れになると、middleがミドルウェアとかライブラリの意味でも話が通じる気が。
そんな気がするけど実際のところFORTRANが使えないと使い物にならないよ
なんだかこのやりとりってFORTRAN黎明期を彷彿とさせますね。
「実際のところアセンブラが…」だったわけね。結局のところ自分のやり方を決して変えようとしない連中はいつの時代にもいて、そいつらを説得しようなんて考えるのは時間の無駄と。
> 結局のところ自分のやり方を決して変えようとしない連中はいつの時代にもいて、> そいつらを説得しようなんて考えるのは時間の無駄と。
そーそー。
こんなとこに、こんな書き込みしてるのと同じくらい時間の無駄だ。
潤沢に技術者を投入できるハイエンド、普通のプログラマが少し頑張ればなんとかなるローエンド、その中間のミドルレンジを支える技術をもった人材が不足。という話題でしょう。
企業のCAEの多くは商用ソフトの利用が主で、ハードウェアもソフトが動くものという縛りで調達することが多いです。自社で超並列に最適化した独自のソフトを作っているところもあるけど、シミュレーターは作れば良いというものでなくて実世界とのマッチングとか、膨大なノウハウが必要になります。
必要となるスキルも、それこそ雲泥の差で分布するので、なかなか一括りでは難しいと思います。
道楽で使ってみた事はあるけど、個人で試しに使ってみるレベルだと、頑張っても10ノードに届かないでしょ。既存のアルゴリズムを、スパコン用に置き換えたりするには、数学的センスと専門教育が必要だと思うよ。
単独のPCで動作させているときと違ってノード間の通信コストが大きい分、ノード間の通信を減らすような最適化も必要。1~数スレッドでしか動かしていないロジックを分解して、数百~数千スレッドにばらす事も必要。場合によってはこの過程で根本的なアルゴリズムの変更も必要だったりする。途中でノードが死んだりした場合とかを想定して、計算途中データの保存とかも考えなきゃいけない。トランザクション数もデータ量も生半可な量じゃない。
そのあたりのノウハウはスパコン固有のものだし、専門にやっている人が設計しないと、中々厳しいと思うな。コーディングするだけなら、いくらでもできるでしょうけど。
なるほど。やはり普段自分が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 さんのコメにもあるように、数万とかコアがあれば確率的に使っている最中の故障確率も必然的に上がるので、そういうエラー時のデータ保存も考える必要が発生するでしょう。小さいクラスタならこの辺の悩みとは無縁です。
# 考えてあってもあんまり害はないとは思いますが。
スパコンでまともにスケーラビリティが出るプログラムの開発ってムズいんですよ。こんなふうに。真面目にやると汎用性がなくなりがちなのはまぁしょうがないと思います。
ちなみに自分はこーゆーのはやってないです。つーか絶対やりたくないし、マトモにできそうにもない。これってそういえば元記事の内容と関係無い気がしてきた。
普通のPC+GPGPUでもパフォーマンスを引き出そうとすると結構スキルがいるんじゃないなかなあ
処理の内容によるでしょうね単なるプログラマのレベルでは歯が立たなくて、アルゴリズムそのものを詳細に理解していなければ駄目な場合もあるし工学分野では難しいこと言わずに使えるベクトル型スパコンの方がありがたいことが多いんですけど
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
スーパーコンピュータも使いやすくなるんじゃ (スコア:3)
同一ノード内の並列化にはOpenACC
http://www.openacc-standard.org/ [openacc-standard.org]
とかOpenMPといったものがあるし、ノード間ではOpenMPIといった規格があって
これらは普通のPCでも使えなくはない状況。
敷居が下がってきてるんで、割と普通のプログラマなら少し頑張ればスーパーコンピュータで
コードが書けるようになりつつあるんじゃないかな。
こんなこと書くと、いや物凄いスキルが要るんだ無理無理絶対無理という人も出るに違いないけれども
専用のスキルをもった職人しかコードが書けないスーパーコンピュータってのも意味ないですよ正直。
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:2, 参考になる)
アプリケーションを書いて使う人がいるいないの問題ではなくて、中規模のシステムを、きちんと性能を引き出せる形で構築したり、要求水準に合わせたコストで維持管理できるような、そういう人材がいるいないの問題なのです。
一見すると中規模というのは大規模と小規模のノウハウを折衷すれば良いように思えて、実際に使う人はもちろん商業的に管理やってる人ですら、その程度の認識しか持っていないことが多いですが、
アホみたいに金を注ぎ込む一品もののシステムとも、問題おこしてなければ問題ない並鯖とも違うアーキテクトやマネージメントが本来は必要で、そこに気がついてしまった不幸なユーザーが、そういう人材の不足に気がついて嘆いているというストーリーなのです。
Re: (スコア:0)
こういう流れになると、middleがミドルウェアとかライブラリの意味でも話が通じる気が。
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:1)
そんな気がするけど実際のところFORTRANが使えないと使い物にならないよ
Re: (スコア:0)
なんだかこのやりとりってFORTRAN黎明期を彷彿とさせますね。
Re: (スコア:0)
「実際のところアセンブラが…」だったわけね。
結局のところ自分のやり方を決して変えようとしない連中はいつの時代にもいて、そいつらを説得しようなんて考えるのは時間の無駄と。
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:2)
> 結局のところ自分のやり方を決して変えようとしない連中はいつの時代にもいて、
> そいつらを説得しようなんて考えるのは時間の無駄と。
そーそー。
こんなとこに、こんな書き込みしてるのと同じくらい
時間の無駄だ。
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:1)
潤沢に技術者を投入できるハイエンド、
普通のプログラマが少し頑張ればなんとかなるローエンド、
その中間のミドルレンジを支える技術をもった人材が不足。という話題でしょう。
企業のCAEの多くは商用ソフトの利用が主で、ハードウェアもソフトが動くものという縛りで調達することが多いです。
自社で超並列に最適化した独自のソフトを作っているところもあるけど、シミュレーターは作れば良いというものでなくて
実世界とのマッチングとか、膨大なノウハウが必要になります。
必要となるスキルも、それこそ雲泥の差で分布するので、なかなか一括りでは難しいと思います。
Re:スーパーコンピュータも使いやすくなるんじゃ (スコア:1)
道楽で使ってみた事はあるけど、個人で試しに使ってみるレベルだと、頑張っても10ノードに届かないでしょ。既存のアルゴリズムを、スパコン用に置き換えたりするには、数学的センスと専門教育が必要だと思うよ。
単独のPCで動作させているときと違ってノード間の通信コストが大きい分、ノード間の通信を減らすような最適化も必要。
1~数スレッドでしか動かしていないロジックを分解して、数百~数千スレッドにばらす事も必要。
場合によってはこの過程で根本的なアルゴリズムの変更も必要だったりする。
途中でノードが死んだりした場合とかを想定して、計算途中データの保存とかも考えなきゃいけない。トランザクション数もデータ量も生半可な量じゃない。
そのあたりのノウハウはスパコン固有のものだし、専門にやっている人が設計しないと、中々厳しいと思うな。コーディングするだけなら、いくらでもできるでしょうけど。
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 さんのコメにもあるように、数万とかコアがあれば
確率的に使っている最中の故障確率も必然的に上がるので、そういうエラー時のデータ
保存も考える必要が発生するでしょう。小さいクラスタならこの辺の悩みとは無縁です。
# 考えてあってもあんまり害はないとは思いますが。
スパコンでまともにスケーラビリティが出るプログラムの開発ってムズいんですよ。
こんなふうに。真面目にやると汎用性がなくなりがちなのはまぁしょうがないと思います。
ちなみに自分はこーゆーのはやってないです。
つーか絶対やりたくないし、マトモにできそうにもない。
これってそういえば元記事の内容と関係無い気がしてきた。
Re: (スコア:0)
普通のPC+GPGPUでもパフォーマンスを引き出そうとすると結構スキルがいるんじゃないなかなあ
Re: (スコア:0)
処理の内容によるでしょうね
単なるプログラマのレベルでは歯が立たなくて、アルゴリズムそのものを詳細に理解していなければ駄目な場合もあるし
工学分野では難しいこと言わずに使えるベクトル型スパコンの方がありがたいことが多いんですけど