Ruby / Pythonのような動的言語は、パフォーマンスのようなC / C ++に到達できますか？

Rubyのような動的言語用のコンパイラをビルドして、C / C ++と同等の性能を比較することは可能でしょうか？私がコンパイラについて理解していることから、Rubyを例にとると、Rubyがリフレクションを処理する方法、整数から大きな整数への自動型変換などの機能、および静的型付けの欠如が効率的なコンパイラを構築するため、Rubyコードのコンパイルは効率的ではありませんRubyの場合は非常に困難です。

Rubyやその他の動的言語をC / C ++に非常に近い性能を発揮するバイナリにコンパイルできるコンパイラを構築することは可能ですか？PyPy / RubiniusなどのJITコンパイラが最終的にパフォーマンスでC / C ++と一致する、または一致しないという根本的な理由はありますか？

注：「パフォーマンス」はあいまいになる可能性があることを理解しているので、それを明確にするために、パフォーマンスYでC / C ++でXを実行できる場合、Yに近いパフォーマンスでRuby / PythonでXを実行できますか？Xは、デバイスドライバーやOSコードからWebアプリケーションまですべてです。

「はい」と言ったすべての人に、設計上、答えが「いいえ」であるという反論点を提示します。これらの言語は、静的にコンパイルされた言語のパフォーマンスと一致することはありません。

Kosは、動的言語には実行時のシステムに関する詳細情報があり、コードを最適化するために使用できるという（非常に有効な）ポイントを提供しました。

ただし、コインにはもう1つの側面があります。この追加情報を追跡する必要があります。現代のアーキテクチャでは、これはパフォーマンスを犠牲にします。

ウィリアムエドワーズは議論の素晴らしい概要を提供します。

特に、Kosが言及した最適化は、Devinが言及したように、言語の表現力を大幅に制限しない限り、非常に限られた範囲を超えて適用することはできません。これはもちろん実行可能なトレードオフですが、議論のために、動的言語ではなく静的言語になります。これらの言語は、ほとんどの人が理解できるように、PythonやRubyとは根本的に異なります。

ウィリアムは、興味深いIBMスライドをいくつか引用しています。

• すべての変数は動的に型指定できます：型チェックが必要です
• すべてのステートメントは、型の不一致などにより例外をスローする可能性があります。例外チェックが必要です
• すべてのフィールドとシンボルは、実行時に追加、削除、変更できます：アクセスチェックが必要です
• すべてのオブジェクトのタイプとそのクラス階層は実行時に変更できます：クラス階層のチェックが必要です

いくつかのこれらのチェックのは、分析後に除去することができます（NB：この分析は、また時間がかかる-実行時）。

さらに、コス氏は、動的言語がC ++のパフォーマンスを上回る可能性があるとも主張しています。JITは実際にプログラムの動作を分析し、適切な最適化を適用できます。

しかし、C ++コンパイラでも同じことができます！最新のコンパイラーは、いわゆるプロファイルガイド最適化を提供します。これは、適切な入力が与えられると、プログラム実行時の動作をモデル化し、JITが適用するのと同じ最適化を適用できます。

もちろん、これは現実的なトレーニングデータの存在にかかっています。さらに、使用パターンが実行中に変更された場合、プログラムは実行時の特性を調整できません。JITはこれを理論的に処理できます。最適化を切り替えるために、JITは継続的に使用率データを収集する必要があるため、実行が再び遅くなるため、この運賃が実際にどのように行われるかを見てみたいと思います。

要約すると、静的分析と最適化と比較して、実行時のホットスポットの最適化は、長期的には実行時情報を追跡するオーバーヘッドを上回るとは思いません。

パフォーマンスYでC / C ++でXを実行できる場合、Yに近いパフォーマンスでRuby / PythonでXを実行できますか？

はい。例として、PyPyを取り上げます。これは、Cに近い解釈を実行するPythonコードのコレクションです（それほど近くではありませんが、遠く離れているわけでもありません）。これを行うには、ソースコードでフルプログラム分析を実行して各変数に静的型を割り当てます（詳細については、AnnotatorおよびRtyperのドキュメントを参照してください）。その後、Cに与えた同じ型情報で武装すると、同じ最適化の種類。少なくとも理論的には。

トレードオフはもちろん、PythonコードのサブセットのみがRPythonによって受け入れられることであり、一般に、その制限が解除されても、Pythonコードのサブセットのみがうまくいくことができます：分析して静的型を指定できるサブセットです。

Pythonを十分に制限すると、制限されたサブセットを利用して効率的なコードにコンパイルできるオプティマイザーを構築できます。これは、実際には興味深い利点ではありません。実際、よく知られています。しかし、そもそもPython（またはRuby）を使用することの全体的なポイントは、おそらく十分に分析されず、優れたパフォーマンスをもたらす興味深い機能を使用したかったということです！興味深い質問は実際には...

さらに、PyPy / RubiniusなどのJITコンパイラーはC / C ++のパフォーマンスに匹敵しますか？

いや

つまり、コードの実行中に、十分なタイピング情報と、すべてのコードをマシンコードまでコンパイルするのに十分なホットスポットを取得できる可能性があります。そして、おそらく、これをいくつかのコードでCよりも優れたパフォーマンスを得ることができます。私はそれが非常に物議を醸すとは思わない。しかし、それでも「ウォームアップ」する必要があり、パフォーマンスは依然として予測可能性が少し低く、一貫して予測可能な高いパフォーマンスを必要とする特定のタスクではCやC ++ほど優れていません。

PythonやRubyよりも多くの型情報を持ち、PythonやRubyよりも優れたJITコンパイラーを持っているJavaの既存のパフォーマンスデータは、まだC / C ++に一致しません。ただし、同じ球場にあります。

簡単な答えは：私たちは知りません、100年後に再び尋ねます。（それでもまだわからないかもしれません。おそらくわからないかもしれません。）

理論的には、これは可能です。これまでに作成されたすべてのプログラムを取得し、それらを可能な限り最も効率的なマシンコードに手動で変換し、ソースコードをマシンコードにマッピングするインタープリターを作成します。これが可能なのは、限られた数のプログラムしか書かれていないためです（さらに多くのプログラムが書かれるにつれて、手動翻訳を続けてください）。もちろん、これは実際的には完全にばかげています。

理論的には、高レベル言語はマシンコードのパフォーマンスに到達できる可能性がありますが、それを超えることはありません。実際には、マシンコードの作成に頼ることはほとんどないため、これは依然として非常に理論的です。この引数は、高レベル言語の比較には適用されません。CがPythonよりも効率的である必要があることを意味するものではありません。

反対側から来る、純粋に実験的な用語では、ほとんどの場合、解釈された高レベル言語はコンパイルされた低レベル言語よりもパフォーマンスが悪いことがわかります。私たちは、CやPythonのような言語が間に挟まれた、非常に高レベルの言語とアセンブリのタイムクリティカルな内部ループで、時間に依存しないコードを書く傾向があります。これをバックアップする統計情報はありませんが、ほとんどの場合、これが実際に最善の決定だと思います。

ただし、高レベルの言語が現実的に書くコードを打ち負かすような競合しない例があります：特殊なプログラミング環境。多くの場合、MatlabやMathematicaなどのプログラムは、単なる人間が書くことができるものよりも、特定の種類の数学的問題を解決するのにはるかに優れています。ライブラリ関数はCまたはC ++（「低レベル言語がより効率的」なキャンプへの燃料です）で記述されている可能性がありますが、Mathematicaコードを記述している場合、それは私のビジネスではありません。ライブラリはブラックボックスです。

理論的には、PythonがCよりも最適なパフォーマンスに近い、あるいはさらに近い可能性がありますか？上で見たように、はい、しかし、私たちは今日からそれとはほど遠いです。繰り返しになりますが、コンパイラーは過去数十年で多くの進歩を遂げており、その進歩は減速していません。

高水準言語は、より多くのものを自動化する傾向があるため、実行する作業が多くなり、効率が低下する傾向があります。一方、セマンティック情報が多くなる傾向があるため、最適化を見つけやすくなります（Haskellコンパイラを記述している場合、別のスレッドが鼻の下の変数を変更することを心配する必要はありません）。リンゴとオレンジの異なるプログラミング言語を比較するためのいくつかの取り組みの1つは、コンピューター言語ベンチマークゲーム（以前のシュートアウト）です。Fortranは、数値タスクで光りがちです。しかし、構造化データまたは高速スレッド交換の操作に関しては、F＃、Scalaはうまく機能します。これらの結果を福音として受け取らないでください。彼らが測定していることの多くは、各言語のテストプログラムの作成者がどれだけ優れていたかです。

高水準言語を支持する主張は、現代のシステムでのパフォーマンスは実行される命令の数とそれほど強く相関せず、時間とともにそれほど相関しないということです。低レベル言語は、単純なシーケンシャルマシンに適しています。高水準言語が2倍の命令を実行するが、キャッシュをよりインテリジェントに使用してキャッシュミスを半分にする場合、最終的に勝者になる可能性があります。

サーバーおよびデスクトッププラットフォームでは、CPUはほとんど高速にならないプラトーに近づいています（モバイルプラットフォームも近づいています）。これは、並列処理の活用が容易な言語に有利です。多くのプロセッサは、ほとんどの時間をI / O応答の待機に費やしています。計算に費やされる時間は、I / Oの量と比較してほとんど重要ではなく、プログラマーが通信を最小限に抑えることを可能にする言語が有利です。

全体として、高水準言語はペナルティから始まりますが、改善の余地があります。彼らはどれくらい近づくことができますか？100年後にもう一度質問してください。

_{最後の注意：多くの場合、比較は、言語A で記述できる最も効率的なプログラムと言語Bで同じではなく、各言語で記述された最も効率的なプログラムとの間ではなく、記述可能な最も効率的なプログラム各言語で一定の時間内に人間によって。これにより、原理的にも数学的に分析できない要素が導入されます。実際には、これは多くの場合、最高のパフォーマンスは、パフォーマンス目標を達成するために記述する必要がある低レベルコードと、リリース日を満たすために書く時間がある低レベルコードとの妥協点であることを意味します。}

C ++の文の基本的な違いx = a + bやPythonの文は、x = a + bC / C ++コンパイラが（と、それはの種類について容易に利用可能であることを少し余分な情報、この文から伝えることができるということであるx、aとb実行する必要があり、正確にどのようなマシンコード） 。Pythonステートメントがどのような操作を行うのかを知るには、停止問題を解決する必要があります。

In C that statement will basically compile to one of a few types of machine addition (and the C compiler knows which one). In C++ it might compile that way, or it might compile to calling a statically known function, or (worst case) it might have to compile to a virtual method lookup and call, but even this has a fairly small machine code overhead. More importantly though, the C++ compiler can tell from the statically known types involved whether it can emit a single fast addition operation or whether it needs to use one of the slower options.

Pythonでは、コンパイラはそれを知っていてa、b両方とも理論的にはほぼ同じくらい良いことをすることができintます。追加のボクシングオーバーヘッドがいくつかありますが、型が静的に知られている場合は、おそらくそれも取り除くことができます（整数はメソッド、スーパークラスの階層などを持つオブジェクトであることをインターフェイスに示します）。問題はPythonのコンパイラができないことですこれは、クラスが実行時に定義され、実行時に変更できるため、定義およびインポートを行うモジュールでさえ実行時に解決されるためです（実行されるインポートステートメントでさえ、実行時にのみ認識できるものに依存します）。そのため、Pythonコンパイラーは、コンパイルしているステートメントが何をするのかを知るために、どのコードが実行されたかを知る必要があります（つまり、停止問題を解決します）。

そのため、理論的に可能な最も洗練された分析を行ったとしても、特定のPythonステートメントが事前に何を行うかについて多くを語ることはできません。これは、洗練されたPythonコンパイラが実装されたとしても、ほとんどすべての場合、Python辞書ルックアッププロトコルに従うマシンコードを発行して、オブジェクトのクラスを決定し、メソッドを見つける必要があることを意味します（クラス階層のMROをトラバースし、実行時に動的に変更することもできるため、単純な仮想メソッドテーブルにコンパイルするのは困難です）、基本的に（遅い）インタープリターが行うことを行います。これが、動的言語用の洗練された最適化コンパイラが実際に存在しない理由です。作成するのは難しいだけではありません。最大の見返りはありません」

これは、コードが何に基づいていないことに注意されたこと、それはコードが何に基づいている可能性がやっています。単純な一連の整数算術演算であるPythonコードでさえ、任意のクラス演算を呼び出しているかのようにコンパイルする必要があります。静的言語は、コードが実行できることについてより大きな制限を持っているため、コンパイラーはより多くの仮定を行うことができます。

JITコンパイラーは、実行時までコンパイル/最適化を待つことでこれを獲得します。これにより、コードが実行できることではなく、コードが実行していることに対して機能するコードを発行できます。このため、JITコンパイラーは、静的言語よりも動的言語の方がはるかに大きな見返りがあります。より静的な言語の場合、オプティマイザーが知りたいことの多くは事前に知ることができるので、それを最適化して、JITコンパイラーが行うことを少なくすることができます。

動的言語用のさまざまなJITコンパイラがあり、コンパイルおよび最適化されたC / C ++に匹敵する実行速度を達成すると主張しています。JITコンパイラーによる最適化でさえ、どの言語の事前コンパイラーでも実行できないため、理論的には（一部のプログラムの）JITコンパイルは、いつか最高の静的コンパイラーを上回る可能性があります。しかし、デヴィンが正しく指摘したように、JITコンパイルのプロパティ（「ホットスポット」のみが高速で、ウォームアップ期間後のみ）は、JITでコンパイルされた動的言語が、すべての可能なアプリケーションに適している可能性が低いことを意味します通常、静的にコンパイルされた言語と同じかそれより高速です。

動的言語の最悪のシナリオの概要を示すクイックポインター：

$\qquad$Perlの解析は計算できません

その結果、（完全な）Perlを静的にコンパイルすることはできません。

一般的に、いつものように、それは依存します。静的にコンパイルされた言語で動的な機能をエミュレートしようとすると、よく考えられたインタープリターまたは（部分的に）コンパイルされたバリアントが静的にコンパイルされた言語のパフォーマンスに近づくかアンダーカットする可能性があると確信しています。

覚えておくべきもう1つのポイントは、動的言語はC以外の別の問題を解決するということです。多くの場合、実行時のパフォーマンスは主要な関心事ではありません。たとえば、市場投入までの時間は、開発者が短時間で複雑で高品質のシステムを作成できるかどうかに依存します。人気のあるもう1つの機能は、プラグインなどの再コンパイルなしの拡張性です。これらの場合、どの言語を好みますか？

この質問に対してより客観的に科学的な答えを提供しようとして、私は次のように主張します。動的言語では、実行時に決定を下すためにインタープリターまたはランタイムが必要です。このインタープリター、またはランタイムはコンピュータープログラムであり、静的または動的のプログラミング言語で作成されています。

インタープリター/ランタイムが静的言語で記述されている場合、（a）解釈する動的プログラムと同じ機能を実行し、（b）少なくとも同様に実行するプログラムを静的言語で作成できます。これらの主張の厳密な証拠を提供するには、追加の（おそらくかなりの）努力が必要になるため、これが自明であることを願っています。

これらの主張が真実であると仮定すると、唯一の解決策は、インタプリタ/ランタイムも動的言語で書かれることを要求することです。ただし、以前と同じ問題に遭遇します。インタープリターが動的である場合、インタープリター/ランタイムが必要であり、これもプログラミング言語（動的または静的）で作成されている必要があります。

インタプリタのインスタンスが実行時にそれ自体を解釈できると仮定しない限り（これが自明であることは自明であることを願っています）、静的言語を破る唯一の方法は、各インタプリタインスタンスが個別のインタプリタインスタンスによって解釈されることです。これは、無限回帰（これが自明であることを願っています）または通訳者の閉じたループ（これも自明であることを願っています）につながります。

理論上でも、一般に、動的言語は静的言語よりも優れたパフォーマンスを発揮できないようです。現実的なコンピューターのモデルを使用する場合、さらにもっともらしいようです。結局、マシンはマシン命令のシーケンスのみを実行でき、マシン命令のすべてのシーケンスは静的にコンパイルできます。

実際には、動的言語のパフォーマンスを静的言語と一致させるには、静的言語でインタープリター/ランタイムを再実装する必要があります。ただし、それができるのは、この議論の要点です。それは鶏と卵の質問であり、上記の未定の（私の意見では、ほとんど自明である）仮定に同意すれば、実際に答えることができます。動的な言語ではなく静的な言語にうなずく必要があります。

この議論に照らして、質問に答える別の方法は次のとおりです。現代のコンピューティングの中心にあるストアドプログラム、control = dataコンピューティングモデルでは、静的コンパイルと動的コンパイルの区別は誤った二分法です。静的にコンパイルされた言語には、実行時に任意のコードを生成および実行する手段が必要です。それは基本的に普遍的な計算に関連しています。

Rubyのような動的言語用のコンパイラをビルドして、C / C ++と同等のパフォーマンスを比較できますか？

答えは「はい」だと思います。私はまた、効率の点で（たとえ多少でも）現在のC / C ++アーキテクチャを超えることさえできると信じています。

理由は簡単です。コンパイル時よりもランタイムに多くの情報があります。

動的型はわずかな障害にすぎません。関数が常にまたはほぼ常に同じ引数型で実行される場合、JITオプティマイザーはその特定の場合に分岐およびマシンコードを生成できます。そして、できることは他にもたくさんあります。

GoogleのSteve YeggeによるスピーチであるDynamic Languages Strike Backを参照してください（私が信じているところにはビデオ版もあります）。彼は、V8からの具体的なJIT最適化手法に言及しています。感動！

私たちは今後5年間で私たちが持っているものを楽しみにしています！

これが理論的に可能であると思われる人々、または遠い将来、私の意見では完全に間違っています。ポイントは、動的言語がまったく異なるプログラミングスタイルを提供し、課すという事実にあります。実際、両方の側面が相互に関連していても、違いは2つあります。

• シンボル（vars、またはすべての種類のid <-> datumバインディング）は型付けされていません。
• 構造（データ、実行時に存在するすべてのもの）も、要素のタイプによって型指定されません。

2番目のポイントは、汎用性を無料で提供します。ここでの構造は、複合要素、コレクションだけでなく、それ自体の型であり、すべての種類（関数、アクション、操作）の（！）ルーチンでさえあることに注意してください...とにかく実行時にチェックが行われます。私たちは、記号を入力した可能性があり、まだ（配列は、その要素の種類に応じて型指定されていないものを構造化しているaだけではないintの配列として配列として入力されます）が、この数は（動的言語では真でなくてもa同様に含むことができ、文字列）。

$L$

• ）Elementを含む、完全にポリモーフィックな（C）型$L$$L$
• すべてのシンボルはそのタイプでありElement、任意の要素を保持できます$L$
• すべての構造（ここでも、モデルルーチンを含む）はElementのみを受け取ります

これはパフォーマンスの大きなペナルティに過ぎないことは明らかです。また、他の投稿で詳しく説明されているすべての結果（プログラムの感度を確保するために必要なあらゆる種類のランタイムチェックの無数）にも触れていません。

私はすべての答えを詳細に読む時間がありませんでした...しかし、私は面白がっていました。

1960年代から70年代前半にも同様の論争がありました（コンピューターサイエンスの歴史はしばしば繰り返されます）：高レベル言語をコンパイルして、プログラマーが手作業で作成したマシンコード（アセンブリコードなど）と同じくらい効率的なコードを作成できますか？誰もがプログラマーがどのプログラムよりもはるかに賢く、非常に賢い最適化を考え出すことができることを知っています（実際には、現在はピープホール最適化と呼ばれるものをほとんど考えています）。これはもちろん私の皮肉なことです。

コード拡張の概念さえありました：優れたプログラマーによって生成された同じプログラムのコードのサイズに対するコンパイラーによって生成されたコードのサイズの比率（これらが多すぎるように:-)。もちろん、この比率は常に1より大きいという考えでした。当時の言語は、CobolとFortran 4、または知識人向けのAlgol 60でした。Lispは考慮されていなかったと思う。

誰かがコンパイラを作成して、時々1の拡張率を得ることができるという噂がありました...コンパイルされたコードが手書きのコードよりもはるかに優れている（そしてより信頼できる）ルールになるまで。当時の人々はコードサイズを心配していました（小さな記憶）が、速度やエネルギー消費についても同じことが言えます。理由は説明しません。

奇妙な機能、言語の動的な機能は重要ではありません。重要なのは、それらが使用されるかどうか、使用されるかどうかです。パフォーマンスは、どんな単位（コードサイズ、速度、エネルギーなど）でも、プログラムの非常に小さな部分に依存することがよくあります。したがって、表現力を与える施設が実際に邪魔にならない可能性が十分にあります。優れたプログラミングの実践では、高度な機能は規律ある方法でのみ使用され、新しい構造を想像します（これがLispのレッスンでした）。

言語に静的な型付けがないという事実は、その言語で書かれたプログラムが静的に型付けされないことを意味していません。一方、プログラムが使用する型システムは、型チェッカーが現在存在するにはまだ十分に形式化されていない可能性があります。

議論の中で、最悪の場合の分析（「停止問題」、PERL解析）への参照がいくつかありました。しかし、最悪の場合の分析はほとんど無関係です。重要なのは、ほとんどの場合または有用な場合に何が起こるかです...しかし、定義されているか、理解されているか、経験されています。プログラムの最適化に直接関係する別の話があります。ずっと前にテキサスの主要な大学で博士課程の学生と彼の顧問（後に国立アカデミーの1人に選出された）の間で行われました。私が思い出すように、学生はアドバイザーが手に負えないことを示した分析/最適化問題の研究に固執していた。すぐに彼らは言葉を話すことはもうありませんでした。しかし、学生は正しかった。ほとんどの実際のケースでは問題は十分に扱いやすいので、彼が作成した論文は参考研究となった。

そしてPerl parsing is not computable、その文が意味するものは何でも、文言についてさらにコメントするために、非常によく形式化された言語であるMLにも同様の問題があります。Type checking complexity in ML is a double exponential in the lenght of the program.それは最悪のケースの複雑さをもたらす非常に正確で正式な結果です...それはまったく問題ではありません。Afaik、MLユーザーは、型チェッカーを爆発させる実用的なプログラムをまだ待っています。

多くの場合、以前と同様に、人間の時間と能力は計算能力よりも不足しています。

将来の本当の問題は、まだ使用されているすべてのレガシーソフトウェアを書き換える必要なく、新しい知識、新しいプログラミング形式を統合するために言語を進化させることです。

数学を見ると、それは非常に大きな知識体系です。それを表現するために使用される言語、表記法、概念は何世紀にもわたって進化してきました。新しい概念で古い定理を書くのは簡単です。私たちは主な証明を適応しますが、多くの結果を気にしません。

しかし、プログラミングの場合、すべての証明を最初から書き直さなければならない場合があります（プログラムは証明です）。私たちが本当に必要とするのは、非常に高レベルで進化可能なプログラミング言語であるかもしれません。オプティマイザーの設計者は喜んで従います。

いくつかのメモ：

• すべての高水準言語が動的であるとは限りません。Haskellは非常に高レベルですが、完全に静的に型付けされています。Rust、Nim、Dなどのシステムプログラミング言語でも、高レベルの抽象化を簡潔かつ効率的に表現できます。実際、動的言語と同じくらい簡潔にすることができます。

• 動的言語用の高度に最適化された事前コンパイラが存在します。適切なLisp実装は、同等のCの半分の速度に達します。

• ここでは、JITコンパイルが大きな勝利になる可能性があります。CloudFlareのWebアプリケーションファイアウォールは、LuaJITによって実行されるLuaコードを生成します。LuaJITは、実際に実行される実行パス（通常、非攻撃パス）を大幅に最適化するため、実際のワークロードで静的コンパイラーによって生成されるコードよりもコードがはるかに高速に実行されます。プロファイルに基づく最適化を備えた静的コンパイラとは異なり、LuaJITは実行時の実行パスの変更に適応します。

• 最適化の解除も重要です。monkeypatchedされているクラスをチェックする必要のあるJITコンパイルされたコードの代わりに、monkeypatchingの動作はランタイムシステムでフックをトリガーし、古い定義に依存していたマシンコードを破棄します。