脂肪プログラム-速度係数

映画「サイズが重要」2009年の写真

この記事は、マウスをクリックするよりもコンピューターの動作が遅くなったという事実の結果として、2016年4月に始まりました。 実際、これは多くのテスト（2010年以降の一部）と私の参加者との議論をまとめたものです。 これらは最終的な結論ではなく、中間的なポイントであり、何を探し、さらに掘り下げるべきかを示すため、完全に終了したとは言えません。

この名前は、2016年にちょうど10歳であったNicklaus Wirthの記事「Down with the Fat Programs」から一部引用されており、その関連性は失われていません-むしろ、それは新しいレベルに達しており、慣れていない-それを読んでください。

システムとプログラムのパフォーマンスに影響するさまざまな側面を考慮してください。

言語的側面
メモリの側面
現実世界の側面
非言語的要因
ヒューマンファクターの側面

言語的側面

a）プログラミング言語とコンパイラの影響

前のコメントで述べたように、「良い」言語を使用すると、速度にかなりの違いが生じます。

古き良きS.を基準点としてみましょう。アセンブラーは十分な勤勉さを使えばより良い結果を得られることは明らかですが、アセンブラーの世界とそれらに関連する高次微調整はアクセスできない理想のままです。

2つの方法でアスペクトの評価を検討してください：浮動小数点計算にあまり依存しないビジネスアプリケーションと、純粋な計算タスク。

次に、それらの間のグラデーションを通過します。

整数計算のテストはDhrystoneです（古くて悪いことは知っていますが、穴の深さを評価するのに非常に適しています-基本的な言語操作の良いセットがあります）。

ここに投稿したコピーと変更されたソースgithub.com/Siemargl/FatProgs
セグメントの極端な点は、最適化されたCプログラムと解釈されたPython3.6プログラムです（Pythonが嫌いではなく、以前の同様のテストですべてを失い、ポイントBであり、既に準備が整っているため）


Scimark2などの浮動小数点計算テスト（これも古く、たとえばパフォーマンスパッケージで引き続き使用されています）


卒業について。

Pythonや古いPHPなどの純粋なインタープリターを考慮しない場合、すべてのコンパイラーとほとんどのJITマシンはx2からx4の範囲に収まり、Javaでの最高のJITは最悪の場合でも2倍未満であり、コンパイルオプションCが正しくありません-FFT計算プログラムは、例えば、5倍遅くなります。

一方、 ここを見ると 、Javascriptの現代の世界では、インタープリターはあなたが思っているよりずっとあなたに近いです。

この係数を測定する方法は上記に示しています。

評価。 まだ多くの要因が先にあるので、純粋に計算上の問題の狭い円を除いて、この速度係数を重要ではないと評価します。

b）プログラミングパラダイムの影響

たとえば、C ++ /D。 これらの言語は、OOPとテンプレートメタプログラミングという2つの主要なパラダイムを追加します。 私は彼らに二甲虫を歌いません-これがパフォーマンスにどのように影響するか見てみましょう。

メタプログラミングを使用します。 テンプレート、マクロ、部分的にジェネリック（オブジェクトは最悪のカルマに属しますが）。 インライン関数が消え、コールの損失がなくなるため、パフォーマンスを損なうことなく、または速度を向上させることなく、テンプレートがコードにデプロイされます。 アプリケーションを脅かすのは、異なるデータ型の同じアルゴリズムのコピーが生成されるため、コードが肥大化することだけです。

OOPを使用する ここでの問題は、フレームワークからレンズを取り出すとすぐに、彼はあなたのプログラムで使用されていなくても、父親、ママ、およびすべての親relativeをプログラムに参加させるように「招待」します（リンカーとブートローダーは、したい）。 一緒に、ディスクから起動する時間、メモリ内およびプロセッサキャッシュ内の場所を消費します。 これは、メモリの側面にもあります。

私はほとんど忘れていました-OOPに加えて導入されたいくつかのテクニック、たとえば、例外やその他の高度なテクニックも完全に無料ではありません。

アスペクトの測定方法-Stepanovのテストがあり、コールを展開するときに最大2倍の加速と仮想コールで最大2％の損失を示しますが、コードの肥大化の影響を評価するのは非常に困難です。以下のメモリアスペクトを参照してください。

この速度係数の評価は、取るに足らないものから目立つものまであります。

c）バイトコードマシン（BCVM）

これらは、マシンコードコンパイラとインタープリタの間のパフォーマンスの真ん中にあり、最初に近いものです。

ここで、中間バイトコードがJITまたはAOTによってコンパイルされるか、解釈されるかにかかわらず、違いは重要です。 BCVMが別の言語用に設計されていて、コードの一部をこのマシンのPiコードに変換できない場合にも、大文字と小文字が混在する可能性があります。

いずれの場合も、ロード時間またはメモリのいずれかで支払います。 たとえば、Java JITは約100MBのメモリを必要としますが、これは不可欠ですが、結果のコードは非常に高速でSIMDを使用します（先日TFTに関する記事でテストされました）

測定方法-テストを使用します。多くの場合、インターネット上で次のようなものを探します。

この速度係数の評価-JITが良い場合は重要ではありませんが、メモリの側面はプラスですが、バイトマシンがインタープリターまたは他の誰かの場合は悲しいかな。

メモリの側面

a）スタッキング

-費用はかかりません。動的メモリの管理者へのアピールは、多くの場合、すでにシステムコールを引き出します。 ガベージコレクターとメモリの断片化と相まって、年中無休のシステムでは問題になる可能性があります。

言語でヒープを使用せずに一時的なローカルオブジェクトを作成できる場合は、メリットがあります。

テストで測定すると、それ自体は少し費用がかかりますが、以下の側面を引き出すことができます。

b）ガベージコレクター（GC）

-それが初心者にとっての祝福なのか、それとも「大きなもの」にとっての呪いなのかは明確ではありませんが、時には戦わなければならないので、マイナスの要因です。

テストによる測定は難しく、BCVMツールによるGC動作の複雑な診断が必要です。

要因の評価-大規模システムの場合、予測できない重大な遅延が発生する可能性があります。

c）動的ローディング

プログラムで新しいウィンドウを開くなど、新しいクラスを起動すると、2つのことが起こります-マシンコードの場合はリンクされたコードを、BCVMの場合はフレームワークをロードする必要があります-（OOPとそのすべての親類の母を見て）ダウンロードしたコードでJITを実行します

実際にBCVMを確認します-簡単なテストを実行できます-ファイルのロードを実行し、インターフェイスを集中的に登ります-そして、プログラムはスワップ速度で動作します。
完全なテストは困難です。ロード時間のみを測定し、プログラムの潜在的な最大食欲-LinuxのVSZメモリのサイズとWindowsの「専用仮想メモリ」カウンタを調べるのは簡単です。 もう少し役立つのは、ハードページフォールトの統計を調べることです。

問題は安価なメモリとプリロードの量によって解決されるように思えますが、1つのプログラムが数十MBを余分に消費する場合、典型的なシステムではそれらが数十個あります。
影響評価-予測不可能な遅延の可能性。

d）CPUキャッシュ

プログラムだけでなく、より多くのコードが実行され、データが処理されるほど、プロセッサキャッシュサイズの影響が強くなります。 さらに、多数のテンプレートとジェネリック、およびJITにキャッシュが必要になります。

テスト-同じプログラムを異なる種類のキャッシュサイズで同じタイプのプロセッサで実行する必要がありますが、これは誰もが利用できるわけではありません。

影響-評価が難しい。 この記事では、キャッシュ内のデータをローカライズすると、速度が向上することがあると主張しています。

現実世界の側面

a）システムコール

異なるプラットフォームでは、システムコールのコストが異なる場合があります。たとえば、ミューテックスやスレッドの作成などです。 したがって、速度の差は、この要因のためにのみ発生する場合があります。 最近のHabré の例の 1つ。

測定-異なるプラットフォームでのテスト。 影響評価-特定のタスクを除き、重要ではないプログラミング言語の選択方法について。

b）抽象的なパフォーマンスはどれほど重要ですか？

ほとんどの場合、使用する必要がある実際のハードウェアは常に低速です。 または、ユーザーの反応に十分な速度です。 または、遅延のためにサイトが十分に訪問されていません。

c）鉄の影響

おそらく、ARMプロセッサを使用していて、浮動小数点の問題がすべてあります。
おそらく、複雑なアルゴリズムに対応できない厳しいメモリ制限があります。
おそらくネットワークが遅いか不安定です。
ビデオアクセラレータは、機能の点で非常に特殊な場合があります。
レイアウトの予備テストが必要です。
影響は非常に強い場合があります。
評価-たとえば、これは電話のバッテリーであり、メモリとギガヘルツに給電する必要があります。

非言語的要因

アルゴリズムがすべてを決定します。 たとえば、SQLは言語の計算特性の点では失われます（これは通常のインタープリターです）が、その優れた数学ハードウェアと長いデータアクセス時間のために、全体的に良好に見えます。 ただし、特定のケースでは、過度に一般化されたSQLアプローチでは、M / CacheやNoSQLソリューションなどの直接的なナビゲーションが失われます。

なめらかなライブラリは、特定の言語の欠点を軽減します。タスクを完了するのにかかる時間の大部分を占め、考えないようにします。これらは数学ライブラリであり、ほとんどの場合、ランタイムライブラリです。

テストと評価-質の高い教育のみが、ここでアルゴリズムを理解するのに役立ちます。

ヒューマンファクターの側面

言語の無知、すぐに正確に書くのが面倒、高すぎる抽象度はすべての面で不十分な決定につながります-たとえば、データ構造を再編成するよりも標準のイテレータを使用してアレイまたはデータベース全体を反復する方が簡単な場合があります。
無限に多くの例があります。

そして、それで何をすることが提案されていますか？

最初の答えは何もありません。 作業制限、継承されたコード、または単に経験不足に制約されている場合。

2番目の答えはアセンブラーでの書き込みです。システムとAPIにはネイティブツールのみを使用します。

あなたが怠tooすぎるなら、それは難しすぎます、そしてあなたには選択肢があります-私はプログラマーの楽園から秋までの次の一連のステップを提供します：

NULL Cを使用する Pure Cは、メモリ内のランタイムライブラリ（libc）のサイズだけプログラムを増やし、最新のオプティマイザーは実行可能コードを損ないません。

実際、Cを取る必要はありません-コンパイルされた言語はあなたの好みに合っています-ADA、Modula、Oberon、さらにPascal / Delphi、できれば最適化

-1。 メタプログラミングを使用します。 テンプレート、マクロ、一部ジェネリック（OOPはすでに最悪のカルマに属しますが）。 テンプレートは、パフォーマンスを損なうことなくコードにデプロイされます。 それらの使用を脅かすのは、異なるデータ型の同じアルゴリズムのコードのコピーが生成されるため、コードが肥大化することだけです。

-2。 コンパイル済みオブジェクト言語C ++、D、Rust、Goを使用します。 何がそんなに悪いの？ 一方では、オブジェクトのファッションはすでにどこでも通用しており、多くの地味な開発者は、オブジェクトアプローチを批判していますが、開発の決定的な利点は得られません。 一方、実証済みの大規模な慣らしフレームワーク。 問題は、プログラムで使用されていない場合でも、ほとんどのフレームワークのオブジェクトがリンクされることです。 おっと、実行可能ファイルが10メガバイトを超えました。 これらのメガバイトは、ディスク、メモリ、およびプロセッサキャッシュを占有します。 関数呼び出しのオーバーヘッドは数パーセントで測定されますが、プロセッサーのキャッシュ占有率の影響を測定することは困難です。

-1024。 通訳言語。 PHP、CPython、一部Javascript。 彼らのおかげで、ブラウザセッションは100メガバイトを超え、100倍の計算速度の低下は正常なことです。

-パイ。 仮想マシン。 これらは、.NETプラットフォームまたはJavaプラットフォームに基づく中間バイトコードを持つ言語です。まあ、PyPyとV8もここに含めることができます。 あなたはいつもあなたと一緒にバイトマシンを運んでいます-それはディスク上であなたと一緒に、それはメモリ内であなたと一緒です。 ただし、テストを信じている場合、すべてがほぼ正常であるように見えます-計算の損失は数十パーセント、最悪の場合は最大100％です。 原則として、テストのみが仮想マシン自体のダウンロード速度を考慮しません。 そして、これはメモリ、メモリ、そして再びメモリ、数十および数百メガバイトです。
開発者自身がこの問題を知っており、ネイティブコードへのコンパイルの方向に向かっています。 これは、AndroidのDalvikaやMicrosoftの.NET Nativeの代わりにARTです。

PSさて、最後の例として、機能が似ている3つのユーザープログラムが目の前にあります。

1つはC ++ / Qt / Webkitで書かれています
C＃.NET 4.5の別の
Python3 / wxの3番目

以下は、それらの中で最も応答性の高いものです-Pythonでは、ドットネットでは最も遅いです。

結論-多くの側面があり、1つだけを考慮することは役に立たない。