対数並列スケーリング/効率プロット

私自身の仕事の多くは、アルゴリズムのスケーリングを改善することを中心にしています。並列スケーリングおよび/または並列効率を示す好ましい方法の1つは、アルゴリズム/コードのパフォーマンスをコア数にわたってプロットすることです。

ここで、軸はコアの数を表し、軸は何らかのメトリック（単位時間ごとに実行される作業など）を表します。異なる曲線は、64コアでそれぞれ20％、40％、60％、80％、100％の並列効率を示しています。$x$$y$

しかし残念なことに、多くの刊行物に、これらの結果がでプロットされている対数で結果例えば、スケーリング本またはこの論文。これらのログ-ログプロットの問題は、実際の並列スケーリング/効率を評価することが非常に難しいことです。たとえば、

上記と同じプロットですが、log-logスケーリングを使用しています。60％、80％、または100％の並列効率の結果に大きな違いはないことに注意してください。ここでこれについてもう少し広範囲に書いた。

そこで、ここに私の質問があります：log-logスケーリングで結果を表示する理由は何ですか？私は定期的に線形スケーリングを使用して自分の結果を表示し、レフリーから定期的に私のスケーリング/効率の結果は他の人の（ログ-ログ）結果ほど良く見えないと言っていますが、私の人生ではプロットスタイルを切り替える必要がある理由がわかりません。

現在、多くの比較可能なプロットを含む論文を書いていますが、ほぼ同じ問題がありました。この論文は、BlueGeneで1から最大100kの範囲のコア数で異なるアルゴリズムのスケーリングを比較することについてです。この状況でloglog-plotsを使用する理由は、関与する桁数です。線形スケールで6桁の大きさをプロットする方法はありません。

そして実際、loglogのコア数で時間をプロットするとき、次のプロットでわかるように、アルゴリズムはあまり区別できません。

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$

片対数スケールで相対的な並列効率をプロットすると、アルゴリズムのスケーリングが非常に明確に示され、アルゴリズムが互いに相対的にどのように実行されるかが示されます。

ゲオルグ・ヘイガーは、これについて「大衆を欺く-スタント3：ログスケールはあなたの友人です」と書いています。

強力なスケーリングのログ-ログプロットがハイエンドであまり識別されないことは事実ですが、より多くの桁にわたるスケーリングを示すことができます。これが有用な理由を確認するには、定期的な改良を伴う3D問題を検討してください。線形スケールでは、1024コア、8192コア、65536コアなど、約2桁にわたって合理的にパフォーマンスを表示できます。読者がプロットからあなたがより小さな何かを実行したかどうかを知ることは不可能であり、現実的には、プロットはほとんどの場合、最大の2つの実行を比較します。

ここで、メモリにコアあたり100万グリッドセルを収めることができると仮定すると、これは8倍の強力なスケーリングを2回行った後でも、コアあたり16kセルを持つことができることを意味しています。それはまだかなりのサブドメインサイズであり、多くのアルゴリズムがそこで効率的に実行されることが期待できます。チャートの視覚スペクトル（1024〜65536コア）をカバーしましたが、強力なスケーリングが困難になる体制には入っていません。

代わりに、コアあたり100万グリッドセルの16コアから始めたとします。これで、65536コアにスケールアウトすると、コアあたり244セルしかなくなり、さらに識別しやすくなります。対数軸は、16コアから65536コアまでのスペクトルを明確に表す唯一の方法です。もちろん、直線軸を使用し、「図では16、128、および1024コアのデータポイントが重複している」というキャプションを使用できますが、図自体ではなく単語を使用して表示しています。

ログ-ログスケールを使用すると、単一ノードまたはラックを超えて移動するなどのマシン属性からスケーリングを「回復」することもできます。これが望ましいかどうかはあなた次第です。

私はジェドが彼の応答で言わなければならないすべてに同意しますが、私は以下を加えたかったです。私は、Martin Berzinsと彼の同僚がUintahフレームワークのスケーリングを示す方法のファンになりました。それらは、対数軸上にコードの弱いスケーリングと強いスケーリングをプロットします（メソッドのステップごとの実行時間を使用）。コードがどれだけうまくスケーリングするかを示していると思います（ただし、完全なスケーリングからの逸脱を判断するのは少し難しいです）。たとえば、このペーパーの7ページと8ページの図7と8を参照してください。また、各スケーリングの数値に対応する数字の表も提供します。

これの利点は、数値を提供した後は、レビュー担当者が発言できることは多くないことです（少なくとも、反論できないほど多くはありません）。

* J。ルイジェンズ、M。ベルジン。「Uintahのパフォーマンスの改善：大規模な適応メッシュ計算フレームワーク」、第24回IEEE国際並列分散処理シンポジウム（IPDPS10）の議事録、ジョージア州アトランタ、1-10ページ。2010. DOI：10.1109 / IPDPS.2010.5470437