タグ付けされた質問 「hpc」

私の計算科学のPhDプログラムでは、ほぼすべてC ++とFortranで作業しています。一部の教授は他の教授よりも一方を好むようです。特定の状況において、どちらが「優れている」のか、一方が他方より優れているのか疑問に思っています。

56 hpc  fortran  c++  languages 

vector<vector<double>>（std を使用して）高性能の科学計算コードのマトリックスクラスを形成するのは良い考えですか？ 答えがノーの場合。どうして？ありがとう

37 hpc  c++ 

top500の調査から、業界がプロセッシングコアの指数関数的な増加に向かっていることは明らかです。最大のスーパーコンピューターはすべてノード間の通信にMPIを使用しますが、ノード上の並列処理の明確な傾向は見られませんが、単一のMPIプロセスを各コアに自動的にマッピングする最も単純な（ただし、必ずしも効率的ではない）コンパイラ、OpenMP、pthreads、CUDA、Cilk、およびOpenCLからの並列化。 私は、世界最大のスーパーコンピューターで使用される可能性のあるコードを維持および開発する科学者グループの1人です。開発者の時間が限られていると仮定して、世界で最も強力なマシンのパフォーマンスを活用できるように、自分自身を将来的に保証するにはどうすればよいですか プロセス相互接続アーキテクチャについて、どのような仮定を立てるべきですか？メニーコア時代に入ると、どのようなパラダイムが苦しむでしょうか？パーティション化されたグローバルアドレス空間の言語は、ペタスケールのマシンで「生産中」に利用できますか？

36 exascale  programming-paradigms  hpc 

プログラマーの観点から、2013年後半のCUDAとOpenCLはどのように比較されますか？私のグループは、GPUコンピューティングを利用しようと考えています。OpenCLのみをサポートし、CUDAはサポートしないハードウェアを選択することにより、自分自身を大幅に制限することになるでしょうか？ もう少し具体的に言うと、次の仮定は正しいですか？ CUDAで可能なことはすべてOpenCLでも可能です ライブラリを使用していない限り、特定のタスクはどちらのライブラリでも実行するのがそれほど簡単ではありません（またはより困難ではありません） CUDAの主な利点は、ライブラリの可用性です どちらも3つのメインプラットフォーム（Win / OSX / Linux）をすべてサポートしています。

34 hpc  gpu  cuda  opencl 

およそアンAmazon EC2の計算クラスタ費$ 800- $ 3年にわたって物理CPUコアあたり（デューティ・サイクルに応じて）1000年。私たちの最後のハードウェア取得で、私のラボはAmazonのクラスターと非常によく似た48コア相当のハードウェアを1コアあたり約300ドルでピックアップしました。 ここに何かが足りませんか？分子動力学シミュレーションなどの高CPUタスクのためにクラウドにクラスターを構築することが経済的に意味のある状況はありますか？それとも、自分でダングマシンを構築してベビーシッターをするだけの方がいいのでしょうか。 （私の研究室では、サーバールームで電気料金を支払っていません（少なくとも直接ではありませんが、この利点があっても、Amazonは依然として非常に高価なようです）。

23 cloud-computing  hpc 

OpenCLプログラミングパラダイムは、異種コンピューティング向けのロイヤリティフリーのオープン標準になることを約束します。OpenCLに基づいたソフトウェアの開発に時間を投資すべきですか？長所短所？

22 hpc  programming-paradigms 

私の研究室での個人的な経験から始めます。ifort 9と10日に戻って、-O3とプロセッサ固有のフラグ（たとえば、-xW -xSSE4.2）を使用してコンパイルする最適化に非常に積極的でした。しかし、ifort 11から始めて、次のことに気付き始めました 。1.結果にいくつかの矛盾があります（セマンティクスが保持されなかったため） 2. -O2に比べて小さいゲイン。 そのため、現在は、通常-O2と-xhostを使用してコンパイルするだけです。ifort 11でより良い提案がありますか？ifort 12に移行すると、これは再び変わりますか？前もって感謝します。

21 performance  hpc  compiling  fortran 

ゼロから並列科学計算ソフトウェアを開発したいです。どの言語から始めるべきかを考えてみたい。このプログラムは、txtファイルへのデータの読み取り/書き込みと、多くのLU分解およびスパース線形ソルバーの使用を伴う大量の計算を並行して実行します。私が考えていたソリューションの候補は、OpenMPまたはco-arrayを備えたFortran 2003/2008、openmp cilk +またはTBB、pythonを備えたC ++です。その他の文書化された提案は大歓迎です！私はC、Fortran、Javaを（この順序で）よく知っています。私はPythonでいくつかのスクリプトを作成しましたが、基本的なものです。 fortranは非常に高速ですが、保守や並列化が難しいことは知っています。私が好きなPythonなどの外部ライブラリを使用しない限り、C ++は遅いと言われていますが、フルスケールの産業レベルのソフトウェアを書くことは現実的ですか？ ソフトウェアは、大量のデータを処理でき、科学計算で効果的である必要があります。パフォーマンスが重要です。 背景については、Fortranで書かれた動作するソフトウェアが既にあります。多くの人々が長年にわたって開発に関わっており、コードは本当に汚れています。コードの維持と並列化は悪夢であることが証明されており、代替案を考えています。 ペトロス

18 python  hpc  c++  fortran  simulation 

私自身の仕事の多くは、アルゴリズムのスケーリングを改善することを中心にしています。並列スケーリングおよび/または並列効率を示す好ましい方法の1つは、アルゴリズム/コードのパフォーマンスをコア数にわたってプロットすることです。 ここで、軸はコアの数を表し、軸は何らかのメトリック（単位時間ごとに実行される作業など）を表します。異なる曲線は、64コアでそれぞれ20％、40％、60％、80％、100％の並列効率を示しています。yバツバツxyyy しかし残念なことに、多くの刊行物に、これらの結果がでプロットされている対数で結果例えば、スケーリング本またはこの論文。これらのログ-ログプロットの問題は、実際の並列スケーリング/効率を評価することが非常に難しいことです。たとえば、 上記と同じプロットですが、log-logスケーリングを使用しています。60％、80％、または100％の並列効率の結果に大きな違いはないことに注意してください。ここでこれについてもう少し広範囲に書いた。 そこで、ここに私の質問があります：log-logスケーリングで結果を表示する理由は何ですか？私は定期的に線形スケーリングを使用して自分の結果を表示し、レフリーから定期的に私のスケーリング/効率の結果は他の人の（ログ-ログ）結果ほど良く見えないと言っていますが、私の人生ではプロットスタイルを切り替える必要がある理由がわかりません。

17 parallel-computing  hpc  scaling  plotting 

24個のIntel Xeon CPUを含むノードで構成されるUbuntu Linuxクラスターで分子動力学（MD）コードGROMACSを実行しました。私の特定の関心のある点は、浮動小数点演算の精度に多少敏感であることが判明したため、GROMACSは、倍精度の計算コストが高いにもかかわらず、単精度ではなく倍精度で実行する必要がありました。そのため、クラスターでは、GROMACSを倍精度でコンパイルしました。 CPUに対して相対的な高速化（「GPUアクセラレーション」）が行われる可能性があるため、GPUの購入を検討しています。ただし、倍精度演算を実行できるGPUが必要です。そのようなハードウェアが市販されているかどうか知っていますか？GROMACSメーリングリストの最近の投稿は、倍精度のGPUは市販されていないことを示唆しています： ハードウェアはそれをサポートしていません[倍精度演算]まだ知らない。 このウィキペディアのページは、倍精度GPUは非効率的である可能性があるため、一般的でないことを示唆しているようです。 Nvidia GPUでの浮動小数点の実装は、ほとんどがIEEEに準拠しています。ただし、これはすべてのベンダーに当てはまるわけではありません。これは、いくつかの科学的応用にとって重要であると考えられている正確さに影響を及ぼします。CPUでは64ビット浮動小数点値（倍精度浮動小数点数）が一般的に使用可能ですが、これらはGPUでは普遍的にサポートされていません。一部のGPUアーキテクチャはIEEE準拠を犠牲にし、他のGPUアーキテクチャは倍精度を完全に欠いています。GPUで倍精度浮動小数点値をエミュレートする努力がありました。ただし、速度のトレードオフは、そもそもGPUに計算をオフロードする利点を無効にします。 このNVIDIA Teslaページは、チャートの「ピークの倍精度浮動小数点パフォーマンス」を参照する際に、実際には、GPUで倍精度計算を実行できることを示唆しているようです（計算コストは​​高くなりますが）。 だから、私は何を信じるべきですか？この問題の経験はありますか？

17 hpc  floating-point  molecular-dynamics  gpu 

OS Xのd明期に戻って、少なくともMacの世界では（当時は科学計算には程遠い場所でした）、科学計算とHPCアプリケーションのプラットフォームとしてのMac OSについて、かなりの騒ぎがありました。 XGridは箱から出して、Virginia TechにはMacベースのコンピューティングクラスターがあり、Stanfordはクールなことなどをしていました。 しかし最近では、物事は静かになっています。Macresearch.orgのサイトは、本質的にスパマーゾンビで満たされたゴーストタウンであり、XServeは死んでおり、非常に多くのマーケティング資料などは、Intelプロセッサ以前の分野のものでさえあるようです。しかし、XGridはまだ存在し、* nix OS全体の基盤はそこにあり、プラットフォームはPython、R、およびいくつかの新しい言語の間で適切にサポートされているようです。 だから、私よりもこれについてもっと知っている人から... OS Xの運賃は？科学計算用の実行可能なクライアント側コンピューターですか？それらをサーバー/クラスター/などとして使用しています。XGridまたはそのような何かを介して単にノベルティアプリケーション？

17 software  hpc 

私たちのワークグループは、建物のエネルギー性能をシミュレートするデスクトップアプリケーションを作成します。これは.NETアプリケーションであり、ユーザーが多くのシミュレーションを実行している場合、かなり時間がかかる可能性があります。シミュレーションは完全に並列化可能で、「オフィス」には非常に重要なHPCコンピューティングリソースがあります。 私たちが持っていたアイデアの1つは、ユーザーが非常に長時間実行されることがわかっているシミュレーションをオフロードできるようにすることです（個々のシミュレーションは約30〜120秒実行され、多数のシミュレーションの実行には数日かかることがあります）。誰もこれをやったことがありますか？もしそうなら、仕事を簡単にするためにライブラリを使用しましたか？努力する価値はありましたか？ 追加するために編集： シミュレーションをオフロードするための個々のタスクは次のようになります ファイルのパッケージ化（約5Mb）、 サーバーにアップロードし、 パッケージを個別のシミュレーションに分解し（それぞれ約30〜120秒かかり、完全に並列化可能）、シミュレーションの数は、ユーザーが選択したオプション（断熱、建物の向きなど）の関数であり、選択の最悪の場合可能なオプションはすべて、約1E50のシミュレーションになります。100〜1E5のシミュレーションを実行することは不明ではありませんが、ユーザーの大半は10未満で実行されます。 完了したシミュレーションを再組み立てし、現在よりはるかに大きなファイルをダウンロードします。 私たちのグループはこれが初めてなので、どのインターフェイスを使用するのかわかりません。予算が削減されると、すぐに完成するかもしれませんが、次の人（もしあれば）が保守しやすい必要があります。 このアプリは既に.NET 4を使用しており、ユーザーが所有するすべてのコアを使用するように拡張できます（開発マシンには8つのコアがあります）。

17 hpc  partitioning 

この質問は計算に関連しているため、ここに投稿することにしました。うまくいけば、それが適切とみなされるでしょう。 大気モデルと海洋モデルを実行し始めたばかりですが、現在のデスクトップよりも多くのコア、メモリ、ディスクスペースが必要であることに気付きました。私の教育機関には高性能コンピューティングサービスがあり、研究者はコアあたり月額固定価格でコアをレンタルできます。私の研究グループでは誰もこのサービスを使用していませんが、代わりに強化されたマシンでジョブを実行しています。ただし、部門内の他のいくつかの研究グループは資金をプールし、コンピューティングサービスを利用しています。 次に、60 GBのRAMを搭載した新しいマシンを購入するか、コンピューティングサービスからコアをレンタルするかを決定する必要があります。この決定を行う際に考慮すべき要素は何ですか？専用のマシンを購入するよりも、コンピューティングサービスを使用する利点は何ですか？

16 hpc 

私がMPIで最も嫌いなのは、データ型（データマップ/マスク）を扱うことです。なぜなら、それらはオブジェクト指向のC ++にうまく適合しないからです。boost::mpiただし、WebサイトからはMPI 1.1のみをサポートしています。 boost :: mpiは、標準のメッセージパッシングインターフェイスに対するC ++フレンドリーなインターフェイスです。Boost.MPIは、Boost.Serializationライブラリを使用して、ユーザー定義型のMPIデータ型を構築できます。 boost::mpi本格的な科学コンピューティングの経験はありますか？お勧めしますか？問題（スケーリングの問題、コンパイラの問題、エラー、実装されていない機能、いくつかのmpi 2.2機能の必要性）がありましたか？ boost::mpiC ++のMPI C実装を使用する代わりに使用についてコメントできますか？両方を組み合わせることができます（可能な場合はboost :: mpiを使用し、他の場所ではC-MPIを使用します）。 を使用して大きな科学的コードを知っていboost::mpiますか？

16 hpc  c++  mpi 

Valgrind + Callgrindを使用して、作成したソルバーのプロファイルを作成しています。Valgrindユーザーマニュアルに記載されているように、コンパイラーのデバッグオプションを使用してコードをコンパイルしました。 「デバッグ情報がなければ、Valgrindの最良のツールは、特定のコードがどの機能に属するかを推測するため、エラーメッセージとプロファイリング出力の両方がほとんど役に立たなくなります。-gを使用すると、関連するソースコード行。」 Valgrindマニュアル デバッグオプションを使用してコンパイルすると、コードの実行速度が大幅に低下します。CFDコードは、デバッグフラグを付けてコンパイルした場合でも、非常に遅くなります。Valgrindを使用すると、40倍遅くなります（マニュアル1を参照）。 コードプロファイリング（ベンチマークではなくプロファイリング）にどのツールを使用していますか？ コードを実行する時間（統計：時間ステップ数）。 ケースの大きさ（ケースがキャッシュに収まる場合、ソルバーは桁違いに高速ですが、メモリ関連のプロセスを見逃すことになります）

16 hpc