解釈されたコードとコンパイルされたコードのパフォーマンスに関する一般的なステートメントを作成できますか？

企業が使用すべき推奨事項に到達するために、2つのテクノロジーを比較しています。テクノロジーBのコードがマシンコードにコンパイルされる間、テクノロジーAのコードは解釈されます。私の比較では、通訳プロセスの追加のオーバーヘッドがないため、一般にTech Bはより良いパフォーマンスを発揮すると述べています。また、プログラムはさまざまな方法で作成できるため、技術Aで作成されたプログラムは技術Bで作成されたプログラムよりも優れている可能性があると述べています。

レビューのためにこのレポートを提出したとき、レビュー担当者は、一般に解釈プロセスのオーバーヘッドがTech Bのパフォーマンスが優れていると結論付けるのに十分な大きさになる明確な理由はないと述べました。

だから私の質問は、コンパイル/解釈されたテクノロジーのパフォーマンスについて何か言うことができますか？コンパイルされたものが一般的に解釈されたものよりも速いと言える場合、どうすればレビュー担当者に私のポイントを納得させることができますか？

番号。

一般に、言語実装のパフォーマンスは、主に、それに費やされる金額、リソース、人材、研究、エンジニアリング、および開発に依存します。

具体的には、特定のプログラムのパフォーマンスは、主にそのアルゴリズムに置かれた思考の量に依存します。

いくつかありますが非常にそこに高速通訳、および生成するいくつかのコンパイラは非常に遅いコードが。

例えば、フォース理由の一つは、依然として人気があると同時に、ユーザプログラムのForthで書かれながら、ケースの多くでは、フォース解釈プログラムは、同等のコンパイルされたCプログラムよりも高速であるためであるプラスのForthインタプリタ書き込まCのCは、Cで書かれたユーザープログラムよりも小さい。

一般化と特定のシナリオは文字通り反対です。

あなたは自分自身に矛盾しているようです。一方では、インタープリター言語とコンパイル言語についての一般的な声明を出したいと思います。しかし、一方で、その一般的な声明を、テクノロジーAとテクノロジーBを含む具体的なシナリオに適用したいと考えています。

具体的なシナリオに何かを適用すると、それはもう一般化されません。だから、通訳言語が一般的に遅いという主張をすることができたとしても、あなたはまだあなたの主張をしていない。レビューアは一般化を気にしません。2つの非常に具体的なテクノロジーの分析を行っています。それは文字通り一般化の反対です。

経験則として、インタープリタープログラムはインタープリターのホスト言語でプログラムを記述するよりも約2倍から10倍遅く、より動的な言語のインタープリターは遅くなります。これは、解釈されたプログラムがすべての実際の作業を行う必要があるが、さらに解釈のオーバーヘッドがあるためです。

インタープリターの構造によっては、非常に大きな違いがあります。インタープリターの設計には、矛盾する2つの流派があります。1つは、オペコードをできるだけ小さくして最適化を容易にすること、もう1つは、オペコードをできるだけ大きくしてインタープリター内でより多くの作業を行うことです。プログラムの構造がインタープリターの哲学と一致する場合、オーバーヘッドは無視できます。

例えば、Perlはテキスト操作を指向したインタープリター言語です。テキスト操作を行う慣用的なPerlプログラムは、Cプログラムよりもそれほど遅くなく、場合によってはCプログラムよりもパフォーマンスが優れていることもあります（Perlが異なる文字列表現を使用し、さまざまなテキストおよびIO関連の最適化が組み込まれている可能性があります）。ただし、Perlでの数値演算処理は、耐え難いほど遅くなります。インクリメント++xは単一のアセンブリ命令ですが、Perlインタープリターの複数のポインタートラバーサルとブランチを伴います。最近、CPUにバインドされたPerlスクリプトをC ++に移植し、コンパイラの最適化レベルに応じて7〜20倍の高速化を実現しました。

洗練された最適化されたインタプリタは、最適化されていない素朴なコンパイラよりもかなり優れている場合があるため、ここでは最適化について話すことが重要です。最適化コンパイラの作成は難しく、多くの労力を必要とするため、「テクノロジーB」がこのレベルの成熟度を持っている可能性は低いです。

（注：Computer Language Benchmarks Gameサイトは複雑な構造を持っていますが、1つの問題のタイミングの表に到達すると、さまざまな言語のパフォーマンスがいたるところにあることに気付くでしょう。多くの場合、明確なパフォーマンスの境界はありません。サイトの最も重要な部分はベンチマーク結果ではなく、有意義なベンチマークがいかに難しいかについての議論です。

技術を選択する場合、言語ランタイム自体のパフォーマンスは完全に無関係です。技術がベースラインの制約を満たすことが重要である可能性が高くなります（予算は$ xです。yyyy-mm-ddの前に配信できる必要があり、さまざまな非機能要件を満たす必要があります）。総所有コスト（開発者の生産性、ハードウェアコスト、ビジネスチャンスコスト、バグのリスクと技術の予期しない制約、メンテナンスコスト、トレーニングおよび雇用コストなど）。例えば、市場投入までの時間が最も重要な要素である業界では、開発者の生産性が最高の技術が最適です。大規模な組織では、保守性と長期的なコストがより興味深い場合があります。

コンパイルされた/解釈された技術のパフォーマンスについて何かを言うことができます。ただし、最初に「パフォーマンス」を定義する必要があります。計算が簡単な組み込みシステムを構築している場合、「パフォーマンス」はメモリ使用量の側面に傾いている可能性があります。一方、大きなデータセットで動作する計算が複雑なシステムは、JVMまたは.NETからのメモリオーバーヘッドが無視できるため、単位時間あたりの計算数で「パフォーマンス」を定義します。

「パフォーマンス」が何であるかを決定したら、「500億のオブジェクトをいつでもメモリに格納し、解釈されたtechAは内部管理のために各オブジェクトに追加の8バイトを追加します。これは400GBのメモリオーバーヘッドに相当します。このデータを追加しないtechBと比較して」

これは技術的な質問であり、すでに多くの優れた技術的回答が得られていますが、あなたの状況のわずかに異なる側面を指摘したいと思います。技術的および/またはパフォーマンス上の理由で。

このようなものの技術的な側面は、AとBの間の決定のほんの一部です。他にも考慮すべき要素がたくさんあります。

• ライセンス費用はかかりますか？たとえば、SQL Serverマシンのクラスターを使用する場合と、PostgreSQLマシンのクラスターを使用する場合には、相当額を支払う必要があります。
• そのテクノロジー（スタック）とそのエコシステムに精通した従業員がいますか？はいの場合、利用可能ですか？いいえの場合、いくつか雇うことができますか？費用はいくらですか？または、既存のものをトレーニングしますか？費用はいくらですか？
• クライアントは何を望んでいますか？これは多くの場合問題になる可能性があります。
• 私が推奨する技術は実稼働で使用する準備ができていますか？または、それはおそらく死ぬかもしれない現在の誇大広告ですか？（たとえば、Node.jsが最初に登場したときを考えてください）
• 私がお勧めする技術は、既存のアーキテクチャまたは私が念頭に置いていたアーキテクチャにうまく適合しますか？または、それらをシームレスに連携させることで多くのお金を費やす必要がありますか？
• そして、あなたの特定の状況に依存するさらに多くの側面。

あなたが見ることができるように、そのような決定を下すときに考慮するべきもののトンがあります。

これがあなたの質問に具体的に答えているわけではないことは知っていますが、あなたの状況やそのような決定の詳細について、より全体像が見えると思います。

部分評価は、関連するインタープリターとコンパイラーに関連する概念的なフレームワークです。

解釈されたコードとコンパイルされたコードのパフォーマンスに関する一般的なステートメントを作成できますか？

プログラミング言語は仕様です（R5RSやn1570などのレポートに記述されています）。彼らはいないソフトウェアなので、それもの話をする意味がありませんパフォーマンス。ただし、一部のプログラミング言語には、インタープリターやコンパイラーなど、いくつかの実装があります。

Cのような伝統的にコンパイルされた言語（つまり、実装がしばしばコンパイラーである言語）でさえ、一部の部分はしばしば解釈されます。例えば、フォーマット制御文字列のprintf（C標準で定義された）であることが多い（により「解釈」C標準ライブラリ有し、printf 機能可変引数の技術を使用して）が、いくつかのコンパイラ（含むGCCは）-inことができ、限られた特定ケース-それを最適化し、低レベルの呼び出しに「コンパイル」します。

また、一部の実装は、「インタープリター」内であっても、JITコンパイル手法を使用しています（実行時にマシンコードを生成します）。良い例はluajitです。他の実装（Python、Ocaml、Java、Parrot、Luaなど）は、ソースコードをバイトコードに変換してから解釈します。

SBCLは、Common Lispの「コンパイラ」であり、すべてのREPLインタラクション（および呼び出しevalなど）をマシンコードに動的に変換します。通訳だと感じます。ブラウザ（たとえばv8）でのJavaScript実装のほとんどは、JITコンパイル技術を使用しています。

言い換えれば、インタープリターとコンパイラーの違いは非常に曖昧で（実際には両方の間に連続性があります）、実際には、ほとんどのプログラミング言語の実装には、インタープリターとコンパイラー（少なくともバイトコードまで）の両方のファセットが含まれていることがよくあります。

実装は、ほとんどの「コンパイラ」または「インタープリター」のような手法を使用することとは無関係に、高速または低速にすることができます。

一部の言語特性は、解釈アプローチを支持しています（プログラム全体の分析を通じてのみ効率的にコンパイルできます）。

以下のためにいくつかの問題の種類、一部でソフトウェアを設計メタプログラミングアプローチすることは価値があり、重要なスピードアップを提供します。特定の入力があると、プログラムはそれを処理するための特別なコードを動的に生成することを想像できます。これはCまたはC ++ でも可能です（JITライブラリを使用するか、Cコードを生成し、動的にロードされるプラグインとしてコンパイルします）。

参照してくださいこの関連のPythonに関する質問をし、その

のようなコードの場合A = A + B、1つまたは2つのマシン命令にコンパイルでき、それぞれが特定のサイクル数を要します。単純な理由により、通訳者はそのサイクル数で同じことを行うことはできません。

インタープリターは、独自の命令セットも実行します（バイトコード、pコード、中間言語など）。ADDのようなバイトコードを検出するたびに、それを何らかの方法で検索し、追加を行うコードに分岐する必要があります。

次のそれを見ている時は、それがなければなら繰り返し、その検索をしない限り、それは前のルックアップを覚えておく方法があります。以前のルックアップを記憶する方法がある場合、それはもはや「インタープリター」と呼ぶものではなく、ジャストインタイムコンパイラー、またはJITterです。

一方...

のようなコードの場合callSomeFunction( ... some args ...)、そのコードを入力してから終了するまでに何サイクルかかりますか？それはすべて内部で起こることに依存しcallSomeFunctionます。たとえそれcallSomeFunctionがコンパイルされたとしても、それは数個である可能性があり、数兆である可能性があります。多くの場合、そのコード行の解釈コストを議論する意味はありません。お金は他の場所にあります。

インタプリタ言語には、コンパイルする必要がないなど、独自の値があることを忘れないでください。（表面構文のバイトコードへの「コンパイル」には、わずかな時間がかかります。たとえば、RやMATLABを使用してください。）

また、インテリジェントレベルのプログラミングには柔軟性が必要です。Minsky's Society of Mindの Chapter 6.4 B -Brainsには、世界を扱うAプログラムがあり、Aプログラムを扱うBプログラムがあり、さらにレベルがあります。他のプログラムを作成および管理するプログラムは、解釈システムでより簡単に実行できます。

Lispでは、(+ A B)AとBを追加するために書くことができますが、一度書かれると、それを実行するかしないかの選択しかありません。また(eval (list '+ 'A 'B))、プログラムを構築して実行するプログラムを作成することもできます。別の何かを構築できます。

プログラムの主題は別のプログラムです。これはインタープリター言語で書く方が簡単です（ただし、Jörgが指摘しているように、新しいバージョンのLispは、evalオンザフライでコンパイルされるため、インタープリターの速度のペナルティはありません）。

種類によって異なりますが、一般的なルールとしては、JITを使用する場合でも静的にコンパイルする場合でも、多くの計算集中型タスクの環境はより高速になります（同じ言語を単純にするため）。

理由の一部は、インタープリター言語にはインタープリターループが必要であるということです。ループは、命令を読み取り、適切なアクションを選択して実行するループです。PythonまたはJavaバイトコードの解釈のような最良の場合（古い JVMが行ったように）、いくつかの命令のオーバーヘッドがあり、分岐予測で大混乱を引き起こしました-最後の予測なしでは、予測ミスによる大きなペナルティが予想されます。非常に愚かなJITでさえ、これを大幅に高速化するはずです。

つまり、解釈された言語はチートするかもしれません。たとえば、Matlabは行列乗算用に最適化されたルーチンを使用しており、GPUでコードを実行できる変更はほとんどありません（免責事項：私はnVidiaで働いています-ここで表明された意見は私のものであり、雇用主の見解を表すものではありません）。そうすれば、詳細を気にすることなく短く強力な高レベルのコードを書くことができます-誰かがそれを気にし、低レベル言語で最適化するために時間とリソースを注ぎました。それについて継承されたものはなく、たとえば、MatlabがコードをJITすることを妨げませんが、多くの場合、高レベルルーチンを呼び出すオーバーヘッドが低レベルルーチンで費やされる時間と比べて最小であるため、理由はありません。

TL; DR-コンパイルされたプログラムは、解釈されたプログラムよりもパフォーマンスが大幅に向上します（リンゴ同士の比較については、PyPy Speedを参照してください）。ただし、実行可能ファイルの速度は問題の一部にすぎず、全体的な速度にあまり寄与しない可能性があります（ほとんどの時間がライブラリで費やされている場合）。実装も重要です。

それは仮定ですが、あなたの仮定は十分に根拠があります。

コンパイルされたコードが解釈されたコードよりも高速でなければならない理由については説明しません。コンピューターの動作を知っていれば、それは明らかです。違いは、特定の種類の問題では数桁になる場合があります。あなたのレビュアーがその一般的なケースに真剣に異議を唱えた場合、彼らは何について話しているのかわかりません。

ただし、ポイントがあるのは、開発しているアプリケーションのタイプに違いがあるかどうかです。ほとんどがI / Oであるか、ほとんどがコンパイルされたライブラリを呼び出しており、計算量が多くない場合、解釈プロセスのオーバーヘッドは実際に取るに足らないものになる可能性があります。

しかし、私の投稿のポイントはこれです。ITエキスパートとして、物事がどのように機能するかについての一般的な知識に基づいて簡単な決定を下すように呼ばれることがよくあります。特定のテストを行うと、より正確な回答が得られる場合がありますが、コストが高くなり、最初にそこに到達することはありません。

しかし、時々あなたは捕まってしまいます。それは私に起こった。あなたは良い仮定をし、それからあなたはあなたが世界の愚かさを考慮に入れなかったことに気付く。

しかし、私の好きなディルバートの漫画ほどよく説明できません。これ以上に賢いことの危険性を示すものはありません。

TL; DR：あなたは正しいはずですが、念のため実世界を確認してください。

少し変わったものを使用しない限り、問題はインタープリター言語Aとコンパイル済み言語Bのパフォーマンスにありません。

あなた/あなたのチームがBではなくAを知っており、BよりもAでより良いコードを書くと、BよりもAではるかに優れたパフォーマンスを得ることができるためです。あなたが1つの言語を経験し、言語/ライブラリがあなたが必要とする仕事、それに固執する。

さまざまな言語の正規表現に関するリンクを次に示します。コンパイルされているかどうかにかかわらず、一部の言語では正規表現がより適切に実装されていることがわかります。http：//benchmarksgame.alioth.debian.org/u64q/performance.php？test = regexdna

1つがコンパイルされ、もう1つが解釈されるという事実だけに基づいて、2つのテクノロジーのパフォーマンスについて話すのは良い考えではないと思います。他の回答で述べたように、アプリケーションの領域（一部の言語は、一部の操作を非常に迅速に実行し、他のことをより遅く実行するように最適化される場合があります）およびその技術を使用しようとしている人々の経験に依存する場合があります。

優れたインタープリター言語コーダーを使い、慣れていないテクノロジーを提供すると、パフォーマンスが向上すると期待するのは合理的ではないと思います-理論的には後者の方がパフォーマンスが向上するかもしれませんが、実際には、必要なスキルと経験がなければ、最適化の機会をすべて使用することはできません。

シリコンバレーの有名な従業員の1人から、熟練した開発者に複雑で高度に最適化されたコードを維持するだけでなく、より高価で面倒な言語を好むことも聞いた効率の低い実装に対処するためにリグを追加購入するので、テクノロジーを選択する際にも考慮する必要があります。

かつて、大きな決断を正当化するために同様の抜本的な声明を出さなければなりませんでした。

第一に、彼らは謙虚なエンジニアを信じたくないかもしれないので、私はいくつかの同等のベンチマークテストを見つけて引用しました。マイクロソフトのような人々や有名な大学からの彼らの多くがあります。そして、彼らは次のようなことを言うでしょう：メソッドAは、変数XとYに応じて、メソッドBよりも3〜10倍高速です。

第二に、問題のコードの代表的なチャンク、または既に持っている類似のものを使用して、独自のベンチマークを実行することができます。一晩1000回実行すると、実際に測定可能な違いがあります。

この時点で、AとBの違い（または欠落）は非常に明確になり、提示するだけで済みます。そのため、可能な場合は図を使用して結果を明確に書式設定し、すべての仮定を示し、使用するすべてのデータを定義します。

私は、動的言語には静的にコンパイルされた言語よりも利点があると主張します。「ランタイム最適化」

これが、JavaがC ++よりも高速になる理由の1つです。

はい、動的に型付けされた言語をロードすると、常に翻訳のコストがかかり、不利になります。しかし、一度実行されると、インタープリターは静的言語には決してないランタイム情報を使用して、頻繁なコードパスをプロファイリングおよび強化できます。

注：まあ、Javaはインタプリタ言語であり、動的な言語ではありません。しかし、それはランタイム情報でスピードアップできることの良い例です

...また、プログラムはさまざまな方法で記述できるため、技術Aで記述されたプログラムは技術Bで記述されたプログラムよりも優れている可能性があると述べています。

レビューのためにこのレポートを提出したとき、レビュー担当者は、一般に解釈プロセスのオーバーヘッドがTech Bのパフォーマンスが優れていると結論付けるのに十分な大きさになる明確な理由はないと述べました。...

これは私のアプローチでしょう：

一般に、インタープリターはコンパイルされるため、低レベルで見た場合、すべてのインタープリターテクノロジーはコンパイルされたテクノロジーにすぎません。したがって、コンパイルされたテクノロジはより多く、より多くの可能性を秘めているので、あなたが賢い場合（一般的にはそうです）悪化することはありません。コンパイル時に利用可能な情報の量と、実行時にのみ利用可能な情報の量、およびコンパイラーとインタープリターがどれだけ優れているかに依存しますが、理論的には、適切なコンパイラーを備えたインタープリターのパフォーマンスと少なくとも同等になることが理論的に常に可能でなければなりません、インタプリタがコンパイラによって作成されているからです。それが可能であるということは、あなたの技術AとBがそうであるという意味ではありません。

実際には、コンパイルされたシステムと解釈されたシステムを比較する場合に利用可能なすべてのベンチマークについてレビュー担当者に伝えてください。次に、最適化されたAssemblyコーディングされた特定のアルゴリズムに勝るインタープリターを提案するように彼に依頼します。

2つの特定の技術AとBを比較する場合、このような一般的なステートメントはまったく役に立たないことを付け加える必要があります。AとBの選択は、それらが解釈またはコンパイルされる場合よりもはるかに重要です。