問題タブ [grid-computing]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
0 に答える
321 参照

javascript - Web 上のグリッド コンピューティング

で Web サイトにアクセスしているときに、クライアント ブラウザーでビッグ データを計算することを考えましたweb worker

ご存じweb workerのように、メイン Web サイトに影響を与えないブラウザのバックエンドで安全なスレッドを実行するため、Web サイトはクライアント プロセッサを使用してクラッキングや拡張などを計算できます。

私はそれを無料のオープンソースサービスとして実装しようとしています.Webサイトはコードを取得します(Google Analyticsなどのようなものです) .、計算して結果をサーバーに送信します。

これについて 2 つの質問があります。

最初に: このアイデアについてどう思いますか? それは役に立つことができますか?

sencod: どうすれば Web ワーカーの CPU 使用率を判断できますか?それは可能ですか?(一部の人はコア i7 を持っているので、ブラウザーでより多くの Web ワーカーを実行できます)

0 投票する
2 に答える
95 参照

grid - gLite と OpenNebula の違い

gLite と OpenNebula の違いは何ですか? 構造と使い方の違いを意図しています。どちらをいつ使用し、いつもう一方を使用するのですか?

0 投票する
1 に答える
324 参照

hadoop - 単一のプロセスをクラスター全体に分散させる最良の方法

私はクラスター コンピューティングに非常に慣れていないので、クラスター コンピューティングに使用されるさまざまなソフトウェアについて、また特定のタスクに最適なソフトウェアについてもっと知りたいと思っていました。特に、私が解決しようとしている問題には、1 人のマネージャーが数百から数千のジョブの作成を担当するマネージャー/ワーカー タイプのシナリオが含まれます。各ジョブは比較的大きいですが、小さなフレーム単位で実行する必要があります。つまり、マネージャーは各ジョブに「1 フレーム進めて、私に報告してください」と指示します。1 つのフレームの実行は非常に短いため、Manager とワーカー マシン間のレイテンシはマイクロ秒単位で非常に小さくする必要があります。

ありがとうございました!出発点として、私が説明したシナリオに完全に適合しないものであっても、あらゆる情報をいただければ幸いです。これまでに調査したのは、Hadoop、HTCondor、および Akka です。

0 投票する
0 に答える
160 参照

python - Python サブプロセスのシステム時間使用量の削減

multiprocessing の pool.map( ... ) を使用して多数の計算を並行して実行する python スクリプトがあります。これらの各計算は、subprocess.popen( ... , stdin=PIPE, stdout=PIPE, stderr=PIPE ) を使用してプログラムを実行し、入力をダンプして読み取り、fortran プログラムの入力を設定する Python スクリプトで構成されます。出力。次に、スクリプトは出力を解析し、必要な数値を取得してから、次の実行のためにもう一度実行します。

とにかく、質問の理由に進みます。このスクリプトをグリッド エンジン システムに送信して、この膨大なパラメータ スペース スイープを 1000、12 コア (ほとんどのグリッドが 12 コアであるため、12 を選択) のタスクに分割します。1 つの 12 コア マシンで 1 つのタスクを実行すると、マシンの時間の約 1/3 がシステム処理に費やされ、残りの 2/3 がユーザー計算に費やされ、おそらく ECIS (前述の FORTRANコード)、ECIS の実行、および ECIS の出力の解析。ただし、5 つのタスクが 64 コアのマシンに送信され、その 60 のコアが使用されることがあります。そのマシンでは、時間の 40% がシステム処理に費やされ、1 ~ 2% がユーザー処理に費やされます。

まず第一に、すべてのシステム コールはどこから来ているのでしょうか。私は、ECIS を個別のスレッドごとに 1 回実行し、新しい入力をそれにパイプし続け、システム内ではるかに多くの時間を費やす (そして全体的に遅くなる) プログラムのバージョンを作成しようとしました。プロセスの作成と削除。次に、システム コールにかかる時間を減らすにはどうすればよいでしょうか。

推測では、プロセスから何かを取得するためにgfortranの出力バッファリングをオフにする必要があったため、プロセスを1回開いて入力を送信し続けるのが遅くなりました。ハプニング)。

これを開発した自宅のテスト マシンの OS は Fedora 14 です。グリッド マシンの OS は Red Hat の最新バージョンです。

-1 (システムのデフォルト)、0 (バッファなし)、1 (行ごと)、および 64Kb に設定して、bufsize をいじってみましたが、状況は変わらないようです。