アカウント名:
パスワード:
プログラミング言語やライブラリと言うよりも, むしろアルゴリズムレベルで異なってくると考えた方が良いでしょう. なぜならそれぞれで性能を落とす部分が異なってくるからです. 例えば
なんてことが考えられます. デュアルコアぐらいまでだとキャッシュへのヒット率とか, それ以前の計算処理でパイプラインの乱れを減らすことに注力すればほぼ問題ありません. メモリ共有型SMPで4CPUあたりから上になってくるとコンパイラやライブラリの出来が性能の大きな部分を占めるのですが, ここでコンパイラやライブラリの癖(例えば配列のサイズとか配列へのアクセス順, 条件判断のタイミングなど)を考慮することで大きな性能差がでます. そのためアルゴリズムを局所的に最適化することが必要になります. これ以上の構成では, 計算ノード間の通信速度やネットワークトポロジにバリエーションがあっても, 基本となるのは計算をできるだけノードの中で完結させ他のノードとの通信を減らすことです. そのためには問題をいかに分割・局所化するかといったことから検討しなければなりません. こうなるとプログラミングがどうこうというレベルじゃなくなって, 事象のモデル化なんてところから再出発が必要だったりします.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
質問です (スコア:2, 興味深い)
・インテルのCore2Duoのようなデュアルコア環境におけるプログラミング
・Sunとかが売ってる４～１６個ぐらいのマルチコアを対象とした処理の分散
・大学のスパコンみたいな複数のグリッドを繋げたホモジニアスなグリッドコンピューティング
・地球シミュレーターみたいなベクトル型プロセッサを繋げたお化け
・GIMPSのようにネットワークに繋がったコンピューター資源に処理を割り振る分散コンピューティング
こーいうのって全部別々の技術で別々のプログラミング言語が使われているんですか？
それともコアの数に依存しない分散処理ができるようなプログラムを書けば
ハードウェアの違いを隠蔽してくれるような素敵な手法があったりするものなんですか？
#アスロンよりもK6レベルのコアを100個ぐらい乗っけたパソコン?が欲しい。
ごめんなさい。
Re:質問です (スコア:4, 参考になる)
プログラミング言語やライブラリと言うよりも, むしろアルゴリズムレベルで異なってくると考えた方が良いでしょう. なぜならそれぞれで性能を落とす部分が異なってくるからです. 例えば
なんてことが考えられます. デュアルコアぐらいまでだとキャッシュへのヒット率とか, それ以前の計算処理でパイプラインの乱れを減らすことに注力すればほぼ問題ありません. メモリ共有型SMPで4CPUあたりから上になってくるとコンパイラやライブラリの出来が性能の大きな部分を占めるのですが, ここでコンパイラやライブラリの癖(例えば配列のサイズとか配列へのアクセス順, 条件判断のタイミングなど)を考慮することで大きな性能差がでます. そのためアルゴリズムを局所的に最適化することが必要になります. これ以上の構成では, 計算ノード間の通信速度やネットワークトポロジにバリエーションがあっても, 基本となるのは計算をできるだけノードの中で完結させ他のノードとの通信を減らすことです. そのためには問題をいかに分割・局所化するかといったことから検討しなければなりません. こうなるとプログラミングがどうこうというレベルじゃなくなって, 事象のモデル化なんてところから再出発が必要だったりします.
Re:質問です (スコア:3, 興味深い)
Javaで書かれたOpenGL(Java 3Dだったかも)を使ったソフトウェアを実行した場合、
ソフトウェア側で複数のCPUで処理するコードを書かずとも、
Java VM側で勝手に複数のCPUに処理を分散するような設計になっていたりして、
ソフトウェアを書く側がCPUが複数あるかどうか、を気にせずとも
複数のCPUによる処理能力を得られるようになっていました。
# このため、同じマシンで実行した場合、複数のCPUの利用を考慮してない
# C++で書かれたソフトウェアよりJavaで書かれたやつの方が早かった
マシン言語にコンパイルされるプログラミング言語であれば、
ライブラリなんかを使う事で、複数のCPUの恩恵を受けられる
ソフトウェアを複数のプラットフォーム向けに書ける可能性もあるとは思います。
中間コードになるプログラミング言語であれば、
バーチャルマシンの方でそれらに対応する事が可能なので（設計として）、
複数のCPUの恩恵を受けるのに、
コードを書く側がライブラリ等さえ気にする事がない、という可能性もあると思います。
Re:質問です (スコア:1, 興味深い)
>・インテルのCore2Duoのようなデュアルコア環境におけるプログラミング
>・Sunとかが売ってる４～１６個ぐらいのマルチコアを対象とした処理の分散
コレと
＃それこそJ2EEのマルチスレッドとかね。
>・地球シミュレーターみたいなベクトル型プロセッサを繋げたお化け
コレと
>・大学のスパコンみたいな複数のグリッドを繋げたホモジニアスなグリッドコンピューティング
>・GIMPSのようにネットワークに繋がったコンピューター資源に処理を割り振る分散コンピューティング
コレは明らかに別だと思うけど。
最後の二つにしても、フルオーダーで作ることが少なくないのでは。
たとえ言語自体が同じだったとしても、中の仕組みは一つ一つ異なると。
Re:質問です (スコア:1)
特定の処理を多数同時に動かすことは可能ですが
異なる処理をまとめて結果を出すとなると、タスク相関を意識した作りにならざるおえません
最初から超多数のプロセスにわけて動作するように作れば
有る意味物理CPUが少なくても動かせると言う話はありますが
タスクが多数存在する為のオーバーヘッドも発生し、プログラム事態も複雑になる可能性が高く
必要以上には行われないと思います
自動化できればなーって言うのはプログラマーと経営者の夢？それとも現実？
並列化プログラミング (スコア:1)
スパコンは自動ベクトル化対応のコンパイラがサポートされてるはずです。
科学技術計算では伝統的に Fortran [kyoto-u.ac.jp] が用いられて来ましたが、
Fortran90 以降、自動ベクトル化が行い易いような拡張 [kyoto-u.ac.jp]が言語仕様に加えられています。
マルチプロセッサの場合は OpenMP [wikipedia.org] を使う事が多いようです。
商用では少なくとも インテルコンパイラー [xlsoft.com]、VisualC++ 8.0 [microsoft.com] 等が対応しています。
gcc 系では例えば GOMP [gnu.org] 等が利用できるようです。
クラスター系は MPI [wikipedia.org] や PVM [wikipedia.org] 等のライブラリが良く使われているようです。
MPI のオープンな実装としては OpenMPI [open-mpi.org] があります。
数値計算に限って言えば BLAS [netlib.org]、ATLAS [sourceforge.net]、LAPACK [netlib.org]、FFTW [fftw.org] 等、
並列化もサポートした出来合いのライブラリが既に存在するので、これらを利用するのが一般的ではないかと思います。
uxi
Re:並列化プログラミング (スコア:1)
地球シミュレータでも使われてるらしい(？)ライブラリ。
階層的地球流体スペクトルモデル集 SPMODEL [nagare.or.jp]
uxi
Re:質問です (スコア:0)
コレを [impress.co.jp]ご所望ということですね。
開発元の http://www.orionmulti.com/ [orionmulti.com]
つながらないけどどうしちゃったのかな・・・
Re:質問です (スコア:0)
識者ではないけど。
おおざっぱにいえば、言語というより、方言とライブラリの組み合わせかな。システムの構成が変われば効率の良いやり方は変わるので、多くの場合、実機とプログラムの組み合わせ毎に個別の対応が必要です。
＃数値計算に限れば、言語の単純さと過去の蓄積もあって FORTRAN はまだまだ残ると思います。
＞ハードウェアの違いを隠蔽してくれるような素敵な手法があったりするものなんですか？
よくわかりませんが、計算機としての基本設計からやり直す必要がありそう。