タグ付けされた質問 「parallel-computing」

複数のプロセッサの同時使用を利用して計算問題を解決する研究。

4
「ジュリア」科学計算言語プロジェクトはどれくらい成熟していますか？
現在使用しているC ++およびPythonの（部分的な）代替として、数値/シミュレーションモデリングプロジェクトに使用する新しい言語の学習を検討しています。ジュリアに出会いました。それが主張するすべてを行うと、高レベルの科学計算ライブラリコード（PyPlotを含む）にアクセスでき、Cと同様の速度でforループを実行できるため、すべてのプロジェクトでC ++ と Pythonの両方を置き換えることができます。また、他の言語のいずれにも存在しない適切なコルーチンのようなものからも恩恵を受けるでしょう。 しかし、それは比較的新しいプロジェクトであり、現在バージョン0.xであり、日々使用する準備が整っていないというさまざまな警告（過去のさまざまな日付に投稿されています）が見つかりました。したがって、この段階でこの言語を学ぶために時間をかけることを個人的に検討する必要があるかどうかを評価するために、プロジェクトのステータスに関する情報（2014年2月、または回答が投稿されるたび）が欲しいです。 Juliaプロジェクトに関する特定の関連する事実に焦点を当てた回答をいただければ幸いです。他のプロジェクトでの経験に基づく意見にはあまり興味がありません。 特に、Geoff Oxberryのコメントは、Julia APIがまだ流動的であり、コードが変更されたときに更新する必要があることを示唆しています。APIのどの領域が安定しており、どの領域が変更される可能性があるのか​​、これがどの程度であるかを知りたいと思います。 私は通常、線形代数（固有問題の解決など）、多くの変数を含むODEの数値積分、PyPlotおよび/またはOpenGLを使用したプロット、および低レベルCスタイルの数値計算（たとえば、モンテカルロシミュレーション） ）。ジュリアのライブラリシステムは、これらの分野で完全に開発されていますか？特に、APIはこれらのタイプのアクティビティに対して多かれ少なかれ安定していますか、それともJuliaの新しいバージョンにアップグレードした後、私の古いコードが壊れる傾向があると思いますか？ 最後に、現在ジュリアを深刻な仕事に使用するかどうかを決定する際に検討する価値がある他の問題はありますか？
3
並列ODEメソッドの最新技術とは何ですか？
現在、ODE統合のための並列メソッドを検討しています。さまざまなアプローチを説明する新しい文献や古い文献がたくさんありますが、最近の調査や一般的なトピックを説明する概要記事は見つかりませんでした。 Burrageによる本[1]がありますが、それはほぼ20年前であり、したがって、パラリアルアルゴリズムのようなより現代的なアイデアの多くをカバーしていません。 [1] K.バラージ、常微分方程式の並列法および逐次法、クラレンドンプレス、オックスフォード、1995
2
OpenCLの数学ライブラリ？
科学コードでOpenCLを使用しようとした人からの情報を探しています。誰もが（最近）ViennaCLを試しましたか？もしそうなら、それはどのようにカスプと比較されますか？ 何についてOCLTools？約束どおりですか？もしそうなら、それはOpenCLで数学カーネルを書き始めるための実行可能な方法でしょうか？
7
Pythonでforループを並列化する
MatlabのparforのようなPythonのツールはありますか？このスレッドを見つけましたが、4年前です。ここの誰かが最近の経験を持っているかもしれないと思った。 並列化するタイプの例を次に示します。 X = np.random.normal(size=(10, 3)) F = np.zeros((10, )) for i in range(10): F[i] = my_function(X[i,:]) どこmy_function取りndarrayのサイズの(1,3)スカラを返します。 少なくとも、複数のコアを同時に使用したい--- parforのように。つまり、8〜16コアの共有メモリシステムを想定しています。
8
並列デバッグにはどのソフトウェアが適していますか？
現在、並列コードを実行していませんが、将来OpenMPとMPIのハイブリッドを使用して並列コードを実行する予定です。デバッガーは、シリアルプロジェクトを実行するときに非常に貴重なツールでした。 並列ソフトウェアのデバッグに使用する並列デバッガー（または複数のデバッガー）をお勧めできますか？フリーソフトウェアが望ましいが、効果的な商用ソフトウェアについて言及することをheしないでください。
3
パラレルI / Oオプション、特にパラレルHDF5
簡単に並列化できるアプリケーションがありますが、そのパフォーマンスは大部分がI / Oバウンドです。アプリケーションは、通常2〜5 GBのサイズのファイルに格納されている単一の入力配列を読み取ります（ただし、この数値は将来的に増加する予定です）。典型的な計算では、その配列の各行または列に同じ操作が適用されます。CPUを大量に使用する操作では、約100プロセッサまで非常に優れたスケーリングが得られますが、遅い操作ではI / Oおよび関連する通信（NFSアクセス）が支配的であり、少数のプロセッサしか効率的に使用できません。 そのような状況で効率的でポータブルな（理想的には移植性の高い）オプションは何ですか？並列HDF5は有望なようです。誰かがそれを実際に体験したことがありますか？ MPI-I / Oは検討する価値があるでしょうか？特定のファイルレイアウトで効率的に動作することはできますか、それともすべてを適応させる必要がありますか？
4
構造化グリッドアダプティブメッシュリファインメント用の汎用ライブラリはありますか？
この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 アダプティブメッシュリファインメント（AMR）は、PDEの数値解法で大きく変化する空間スケールの問題に対処するための一般的な手法です。構造化グリッド上のAMRにはどのような汎用ライブラリが存在しますか？理想的には、ライブラリがアダプティブメッシュのみを処理し、物理学と離散化（有限差分/ボリューム/要素）を提供する、PETScの精神にあるものが欲しいです。 理想的なライブラリは モジュラー：コードの記述方法やデータ構造の量が多すぎる 一般：私が使用している離散化の種類は気にしません 効率的：オーバーヘッドがかかりすぎない 並列で拡張性の高い これらの基準のサブセットのみに適合するライブラリは、引き続き関心の対象となります。 補遺：Donna CalhounのAMRパッケージの広範なリストは知っていますが、上記の基準に適合するパッケージはどれか（もしあれば）わかりません。だから、私は主に、それらの用語でどのように評価するかについて、1つまたは（より良い）さらに多くのパッケージで実際の経験を持っている人々から聞くことに興味があります。
3
対数並列スケーリング/効率プロット
私自身の仕事の多くは、アルゴリズムのスケーリングを改善することを中心にしています。並列スケーリングおよび/または並列効率を示す好ましい方法の1つは、アルゴリズム/コードのパフォーマンスをコア数にわたってプロットすることです。 ここで、軸はコアの数を表し、軸は何らかのメトリック（単位時間ごとに実行される作業など）を表します。異なる曲線は、64コアでそれぞれ20％、40％、60％、80％、100％の並列効率を示しています。yバツバツxyyy しかし残念なことに、多くの刊行物に、これらの結果がでプロットされている対数で結果例えば、スケーリング本またはこの論文。これらのログ-ログプロットの問題は、実際の並列スケーリング/効率を評価することが非常に難しいことです。たとえば、 上記と同じプロットですが、log-logスケーリングを使用しています。60％、80％、または100％の並列効率の結果に大きな違いはないことに注意してください。ここでこれについてもう少し広範囲に書いた。 そこで、ここに私の質問があります：log-logスケーリングで結果を表示する理由は何ですか？私は定期的に線形スケーリングを使用して自分の結果を表示し、レフリーから定期的に私のスケーリング/効率の結果は他の人の（ログ-ログ）結果ほど良く見えないと言っていますが、私の人生ではプロットスタイルを切り替える必要がある理由がわかりません。
5
並列簡約のために数値の非結合性に対処する方法は？
並列簡約では、対応する操作が結合的であると仮定します。浮動小数点数の追加については、この仮定に違反しています。なぜ私がこれを気にするのか尋ねるかもしれません。まあ、それは結果の再現性を低下させます。また、シミュレートされたアニーリングを使用して、このような非再現性のある結果を生成するサブルーチンを最適化（またはパラメーターに適合）すると、さらに悪化します。 この問題に対処する一般的な方法は何ですか？次の戦略について何が言えますか？ 非再現性を気にしないでください。 浮動小数点数と加算で並列リダクションを使用しないでください。 適切なサイズのワークパッケージを再現可能な方法で作成し、最終的な縮小を手作業で行います。 加算に高精度を使用します（ただし、すべてのコンパイラが高精度の浮動小数点型を提供するわけではありません）。
5
優れた使いやすい高品質のオープンソースCFDソルバーはありますか？
私の論文は、燃焼のモデル削減のための数値的手法の開発です。私は燃焼シミュレーションの化学部分で純粋にメソッドを実行し、0-Dシミュレーション（フローなし）のケーススタディをたくさん持っています。私が望んでいるのは、フローを含むシミュレーション、できれば2次元または3次元シミュレーションを実行することです。 計算要件が高いため、これらのシミュレーションは並行する必要があります。また、ChemkinやCanteraなどの化学ソルバーとインターフェイスできるものが必要です。これにはソースコードがあります。（ChemkinはFortran 77にあり、CanteraはC ++にあります。） 理想的なケースでは、私のgradプログラムといくつかのCFDパッケージから得た流体力学の基本的な知識を使用してフローパターンを指定し、ケミストリーを追加して実行できます。必要に応じて、以前の共同研究者が使用した実験セットアップに基づいた単純なケーススタディのために、流体の動きと化学を支配する方程式を設定できますが、それを非常に簡単にするパッケージ。2〜3週間は喜んで使用します。この要件がPETScまたはTrilinosを除外するかどうかはわかりません。これ以上費やさなければならない場合は、ケーススタディ用のCFDコードを提供する共同作業者がいるので、後まで延期します。 CFDパッケージを使用したり、CFDコードを記述した経験がある人はいますか？私が使用したいと思うことの1つはStrang splittingですが、私はCFDやPDEの専門家ではありません。モデル縮小のための化学と数値的方法を研究しています。また、推奨ソフトウェアを使用して速度を上げるのにかかった時間についてコメントしてください。 @FrenchKheldarは、私が解決したい問題の特徴に言及するべきであるということを指摘しています。 理想的な（完全な）ガス、単相 圧縮性 層流が不可欠です。乱流はプラスです。（CFDでの数値手法の以前の研究からの乱流については少し知っていますが、CFDソルバーの仕事はしていません。物理については少しだけ知っています。） ゼロマッハ数の公式は大丈夫です（衝撃や超音速の流れは気にしません） 燃焼化学、SoretおよびDufourフラックスを無視し、拡散をFickianとして扱う ジオメトリは単純なものにすることができます インターフェースコードを書くことはできますが、書く必要が少ないほど良いです。@FrenchKheldarは、CanteraにはFortranとPythonのバインディングがあることも指摘しています。私は現在、ラピッドプロトタイピングのためにCantera Pythonバインディングを使用しているので、それらにも満足しています。
5
非常に高価な目的関数を持つ問題の並列最適化アルゴリズム
10〜20個の変数の関数を最適化しています。悪いニュースは、各関数の評価が高価で、約30分のシリアル計算であるということです。幸いなことに、数十の計算ノードを自由に使用できるクラスターがあります。 したがって、質問：その計算能力をすべて効率的に使用できる最適化アルゴリズムはありますか？ スペクトルの片側には徹底的な検索があります。検索空間全体を細かいグリッドに分割し、各グリッド点で関数を個別に計算します。これは確かに非常に並列計算ですが、アルゴリズムは恐ろしく非効率的です。 スペクトルの反対側には、準ニュートンアルゴリズムがあります。以前の履歴に基づいて、パラメータの次の推定値をインテリジェントに更新します。これは効率的なアルゴリズムですが、並列化する方法がわかりません。「以前の履歴に基づいたパラメーターの推定」という概念は、シリアル計算のように聞こえます。 二次アルゴリズムは中間のどこかにあるように見えます。値の束を並列に計算することで初期の「代理モデル」を構築できますが、残りの反復が並列化可能かどうかはわかりません。 クラスター上でどのような種類のグラジエントフリー最適化方法がうまく機能するかについての提案はありますか？また、現在利用可能な最適化アルゴリズムの並列実装はありますか？
3
粒子分解およびドメイン分解の並列化アルゴリズムの長所と短所は何ですか？
GromacsやDL_POLYなどのいくつかのソフトウェアパッケージを使用して、分子動力学（MD）シミュレーションを実行しています。 Gromacsは、粒子分解アルゴリズムとドメイン分解アルゴリズムの両方をサポートするようになりました。デフォルトでは、Gromacsシミュレーションはドメイン分解を使用しますが、長年、最近まで、粒子分解はGromacsで実装された唯一の方法でした。Gromacsの論文の1つ（DOI 10.1002 / jcc.20291）で、著者は粒子分解の最初の選択の理由を示しています。 「初期の設計決定は、プロセッサに作業を分散するためにドメイン分解ではなく粒子分解を使用する選択でした。後者の場合、空間ドメインはプロセッサに割り当てられます。ドメイン分解は、線形システムのサイズが相互作用の範囲を大幅に超える場合にのみ適切な選択です（分子動力学ではほとんどありません）。粒子分解では、各プロセッサが力と座標/速度の更新を計算しますプロセッサに均等に分散された事前計算されたネイバーリストを使用して、割り当てられたパーティクルの一部に対して。F私はjF私jF_{ij}粒子 と間のペア相互作用から生じるは、粒子と 両方の速度更新に必要です。私私ijjj私私ijjj、一度だけ計算され、他のプロセッサに伝達されます。すべてのプロセッサは、ストレージを必要な座標に制限するのではなく、システムの完全な座標セットをローカルメモリに保持します。これはより単純で通信のオーバーヘッドを節約しますが、メモリクレームは通常、何百万ものパーティクルであっても制限要因ではありません。一方、近隣リストは、最大1000倍の数のパーティクルを含むことができ、プロセッサに分散されます。通信は本質的に、座標の送信とプロセッサリングの周りのタイムステップごとに1回の強制に制限されます。これらの選択肢は、長期にわたって堅牢であり、最新のプロセッサクラスタに簡単に適用できることが実証されています。」 「ドメイン分解は、線形システムのサイズが相互作用の範囲を大幅に超える場合にのみより良い選択です。これは分子動力学ではめったにありません」という文の「線形システムのサイズ」とはどういう意味ですか？上記の段落から、粒子の分解には、ドメインの境界を越えて移動する粒子を処理する必要がないという利点があります。むしろ、システム構成全体を保存するのに十分なメモリが各プロセッサに必要です。したがって、ドメイン分解は非常に好ましくないように見えますが、粒子分解は非常に好ましいように見えます。 これは非常に複雑な質問（そしておそらく多くの本の主題）であると確信していますが、基本的に、粒子の分解が非常に好ましいと思われる場合、ドメイン分解を使用する必要があるのはなぜですか？ システムのサイズが非常に大きい場合（各プロセッサに構成全体を保存するのが困難または不可能になる場合）、ドメインの分解は適切ですか？上記の引用された段落に基づいて、ドメイン分解が最近、Gromacsのデフォルトの並列化アルゴリズムである理由がわかりません。 DL_POLY（バージョン4）もドメイン分解を使用しているようです。バージョン4のマニュアルから： 「この方法での構成データの分割は、シミュレーションセル内の原子の位置に基づいています。このようなシステムデータの幾何学的割り当ては、DDアルゴリズムの特徴です。この戦略が効率的に機能するために、システムは合理的に均一な密度を持たなければならないので、各プロセッサには原子データのほぼ等しい部分が割り当てられます（可能な限り）。この方法は概念的には簡単ですが、プログラミングは難しく、効率が最も高い大規模なシミュレーションに特に適しています。 ... DD戦略の場合、SHAKE（RATTLE）アルゴリズムはDL_POLY ClassicのReplicated Dataメソッドよりも単純です。この場合、原子位置のグローバルな更新（マージとスプライシング）が必要です。 これにより、実装が困難になる可能性がありますが、より効率的になる可能性があるため、ドメイン分解が良好であるかのように聞こえます。 一方、以前のバージョン（DL_POLY Classic）は複製されたデータの並列化を使用していました。これは、パーティクル分解の別名と思われます。そのバージョンのマニュアルから： レプリケートデータ（RD）戦略は、MDで並列化を実現するいくつかの方法の1つです。その名前は、並列コンピューターの各ノード上の構成データの複製に由来します（すなわち、原子座標、速度 定義する配列、およびを強制しますすべてr私r私\textbf{r}_iv私v私\textbf{v}_if私f私\textbf{f}_iNNNシミュレートされたシステム内の原子は、すべての処理ノードで再現されます）。この戦略では、力の計算と運動方程式の統合のほとんどは、ノード間で簡単かつ均等に共有でき、大部分は各ノードで独立して処理できます。この方法は、プログラムが比較的簡単であり、かなり効率的です。さらに、単一のプロセッサで非常に簡単に実行できるように「折りたたみ」できます。ただし、この戦略はメモリを大量に消費し、通信のオーバーヘッドが高くなる可能性がありますが、全体的に見て、幅広いアプリケーションで成功することが実証されています。 この段落は一般に、この質問の最初の段落と一致しているように見えますが、複製されたデータ/粒子の分解には「高い通信オーバーヘッド」があると書かれています。Gromacsの論文のパラグラフは、その逆を言っているようです。つまり、粒子分解は、ドメイン分解よりも通信のオーバーヘッドが少ないため、好ましいと言えます。 何か考えはありますか？
3
行列ベクトル乗算のスケーリングが行われないのはなぜですか？
長い投稿で申し訳ありませんが、最初の段階で関連があると思ったものをすべて含めたかったのです。 私が欲しいもの Krylov Subspace Methods for Dense Matricesの並列バージョンを実装しています。主にGMRES、QMRおよびCG。（プロファイリング後）私のDGEMVルーチンは哀れなことに気付きました。それで、私はそれを分離することによってそれに集中することに決めました。12コアのマシンで実行してみましたが、以下の結果は4コアのIntel i3ラップトップ用です。傾向に大きな違いはありません。 私のKMP_AFFINITY=VERBOSE出力はここにあります。 私は小さなコードを書きました： size_N = 15000 A = randomly_generated_dense_matrix(size_N,size_N); %Condition Number is not bad b = randomly_generated_dense_vector(size_N); for it=1:n_times %n_times I kept at 50 x = Matrix_Vector_Multi(A,b); end これは、50回の反復でCGの動作をシミュレートすると思います。 私が試したもの： 翻訳 私はもともとFortranでコードを書いていました。C、MATLAB、Python（Numpy）に翻訳しました。言うまでもなく、MATLABとPythonは恐ろしいものでした。驚くべきことに、上記の値ではCはFORTRANよりも1〜2秒優れていました。一貫して。 プロファイリング 実行するコードのプロファイルを作成し、46.075数秒間実行しました。これは、MKL_DYNAMICがに設定されFALSE、すべてのコアが使用されていたときです。MKL_DYNAMICをtrueとして使用した場合、特定の時点で使用されていたコアの数は（およそ）半分だけです。詳細は次のとおりです。 Address Line Assembly CPU Time 0x5cb51c mulpd %xmm9, …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.