Ruby、PythonがJavascript V8の速度を得るために何を妨げているのですか？[閉まっている]

V8エンジンの最適化（インラインキャッシュなど）の実装をブロックしているRuby / Python機能はありますか？

PythonはGoogleのメンバーによって共同開発されているため、ソフトウェア特許によってブロックされるべきではありません。

または、これはGoogleがV8プロジェクトに投入したリソースの問題です。

Ruby、PythonがJavascript V8の速度を得るために何を妨げているのですか？

何もない。

まあ、大丈夫：お金。（そして時間、人、リソース、しかしお金があればそれらを買うことができます。）

V8には、高性能で専門性が高く、経験豊富な（したがって、高額な）エンジニアのチームがあり、ハイパフォーマンスな実行を作成するのに何十年もの経験（私は個別に話している-まとめると数世紀のようなものです）を持っています。動的オブジェクト指向言語用のエンジン。彼らは基本的に、Sun HotSpot JVMを作成した人と同じです（他の多くの人の中で）。

主任開発者であるLars Bakは、文字通り25年間VMに取り組んできました（これらのVMはすべてV8にまで達しています）。これは基本的に彼の（専門的な）人生全体です。Ruby VMを作成している人の中には、25歳に満たない人もいます。

V8エンジンの最適化（インラインキャッシュなど）の実装をブロックしているRuby / Pythonの機能はありますか？

少なくともIronRuby、JRuby、MagLev、MacRuby、およびRubiniusには、単相（IronRuby）または多相のインラインキャッシングがあるため、答えは明らかにノーです。

最新のRuby実装は、すでに多くの最適化を行っています。たとえば、特定の操作では、RubiniusのHashクラスはYARVのクラスよりも高速です。HashYARVは100％手作業で最適化されたCで実装されているのに対し、Rubiniusのクラスは100％純粋なRubyで実装されていることに気付くまで、これはひどくエキサイティングなサウンドにはなりません。

したがって、少なくとも一部のケースでは、RubiniusはGCCよりも優れたコードを生成できます。

または、これはGoogleがV8プロジェクトに投入したリソースの問題です。

はい。Googleだけではありません。V8のソースコードの系統は25年前のものです。V8に取り組んでいる人々は、Self VM（今日までに作成された最速の動的OO言語実行エンジンの1つ）、Animorphic Smalltalk VM（現在までに作成された最速のSmalltalk実行エンジンの1つ）、HotSpotも作成しましたJVM（これまでに作成された中で最速のJVM、おそらく最速のVM期間）とOOVM（これまでに作成された中で最も効率的なSmalltalk VMの1つ）。

実際、V8の主任開発者であるLars Bakは、それらすべてに加えて、他のいくつかにも取り組みました。

JavaScriptインタープリターを高度に最適化するための推進力はさらにあります。そのため、Mozilla、Google、Microsoftの間で非常に多くのリソースが投入されているのがわかります。JavaScriptは、（通常はせっかちな）人間がそれを待っている間、リアルタイムでダウンロード、解析、コンパイル、および実行する必要があり、人がそれと対話している間は実行する必要があり、制御されていないクライアント側でこれを実行しますコンピュータ、電話、トースターなどの環境。これらの条件下で効果的に実行するには、効率的である必要があります。

PythonとRubyは、開発者/配備者によって制御される環境で実行されます。制限の要因がメモリやディスクI / Oなどであり、実行時間ではない、一般的に強力なサーバーまたはデスクトップシステム。または、キャッシュなどのエンジン以外の最適化を利用できる場合。これらの言語では、速度の最適化よりも言語とライブラリの機能セットに重点を置く方が理にかなっています。

これの副次的な利点は、Node.jsなどのあらゆる種類のアプリケーションで再利用できる高性能のオープンソースJavaScriptエンジンが2つあることです。

その大部分はコミュニティと関係があります。ほとんどの場合、PythonとRubyには企業の支援がありません。PythonとRubyのフルタイムで仕事をすることで報酬が支払われることはありません（特に、CPythonまたはMRIで仕事をすることで報酬が支払われることはありません）。一方、V8は、世界で最も強力なIT企業によって支えられています。

さらに、V8の人々にとって重要な唯一のことはインタープリターであるため、V8はより速くなる可能性があります-彼らには作業する標準ライブラリーがなく、言語設計に関する心配もありません。彼らは通訳を書くだけです。それでおしまい。

それは知的財産法とは何の関係もありません。また、PythonはGoogleのメンバーによって共同開発されたものではありません（そのクリエーターは他のコミッターと一緒にそこで働いていますが、Pythonの作業に対して報酬を得ていません）。

Pythonの速度に対するもう1つの障害はPython 3です。その採用は、他の実装が追いつくまで新しい言語機能の開発を凍結しているという点で、言語開発者の主な関心事のようです。

技術的な詳細については、Rubyについてはあまり詳しくありませんが、Pythonには最適化を使用できる場所がいくつかあります（そして、GoogleプロジェクトのUnladen Swallowは、ほこりを噛む前にこれらを実装し始めました）。以下は、彼らが計画した最適化の一部です。CPythonにJIT a la PyPyが実装されれば、将来的にPythonがV8の速度を上げるのを見ることができますが、今後数年間はそうは思われません（現在の焦点は、JITではなくPython 3の採用です）。

多くの人は、RubyとPythonがそれぞれのグローバルインタープリターロックを削除することで大きな利益を得ることができると感じています。

また、PythonとRubyはどちらもJSよりもはるかに重い言語であることを理解する必要があります。これらは標準ライブラリ、言語機能、および構造の点ではるかに多く提供しています。オブジェクト指向のクラスシステムだけでも、かなりの重みが加わります（良い意味で）。私は、JavascriptをLuaのように埋め込むように設計された言語と考えています（そして多くの点で、それらは似ています）。RubyとPythonには、はるかに豊富な機能セットがあり、その表現力は通常、速度を犠牲にしてもたらされます。

パフォーマンスはコアPython開発者の主要な焦点ではないようです。コア開発者は、「十分に高速」で十分であり、プログラマーの生産性を向上させる機能は、コンピューターがコードをより高速に実行する機能よりも重要であると感じています。

実際、しかし、標準のインタープリターと互換性のあるより高速なPythonインタープリターを作成するために、（現在は放棄された）Googleプロジェクトunladen-swallowがありました。PyPyは、より高速なPythonを作成することを目的とした別のプロジェクトです。PyPyの前身であるPsycoもあり、インタプリタ全体を変更せずに多くのPythonスクリプトのパフォーマンスを向上させることができます。Cythonを使用すると、Pythonの構文に非常によく似たものを使用して、Python用の高性能Cライブラリを作成できます。

誤解を招く質問。V8はJavaScriptのJIT（ジャストインタイムコンパイラ）実装であり、最も人気のある非ブラウザ実装であるNode.jsでは、イベントループの周りに構築されます。CPythonはJITではなく、イベントも発生しません。しかし、これらはPythonのPyPyプロジェクトで最も一般的に存在します-CPython 2.7（そして間もなく3.0+）互換のJIT。そして、例えばトルネードのようなイベントサーバーライブラリがたくさんあります。実際のテストは、トルネードとNode.jsを実行するPyPy間に存在し、パフォーマンスの違いはわずかです。

私はこの質問に出くわしましたが、言及されていないパフォーマンスの違いには大きな技術的な理由もあります。Pythonには強力なソフトウェア拡張機能の非常に大きなエコシステムがありますが、これらの拡張機能のほとんどはパフォーマンスのためにCまたはその他の低レベル言語で記述されており、CPython APIに深く結びついています。

CPythonの実装を高速化するために使用できるよく知られた手法（JIT、最新のガベージコレクターなど）はたくさんありますが、すべてAPIに大幅な変更を加える必要があり、プロセスのほとんどの拡張機能が壊れます。CPythonはより高速になりますが、Pythonを非常に魅力的にする多くの機能（広範なソフトウェアスタック）は失われます。適切な例としては、いくつかのより高速なPython実装がありますが、それらはCPythonと比較してほとんど牽引力がありません。

設計の優先順位とユースケースの目標が異なるため、私は信じています。

一般に、スクリプト言語（動的）の主な目的は、ネイティブ関数の呼び出し間の「接着剤」となることです。そして、これらのネイティブ機能は、a）最も重要で頻繁に使用される領域をカバーし、b）可能な限り効果的でなければならない。

次に例を示し ます。iOS SafariがフリーズするjQueryソート フリーズは、get-by-selector呼び出しの過度の使用が原因です。get-by-selectorがネイティブコードで実装され、実質的にはそのような問題はまったくありません。

V8デモで頻繁に使用されるレイトレーサーデモを検討してください。Pythonの世界では、Pythonがネイティブ拡張のすべての機能を提供するため、ネイティブコードで実装できます。ただし、V8レルム（クライアント側のサンドボックス）では、VMを可能な限り[サブ]に効果的にする以外に選択肢はありません。そして、唯一のオプションは、スクリプトコードを使用することによるレイトレーサーの実装を参照してください。

優先順位や動機はさまざまです。

でSciter私はネイティブにかなりのフルjQureyコアを実装することで、テストを行いました。ScIDE（HTML / CSS / Scriptで作られたIDE）のような実用的なタスクでは、そのようなソリューションはVMの最適化よりもはるかにうまく機能すると思います。

他の人が述べたように、PythonにはPyPyの形式の高性能JITコンパイラーがあります。

意味のあるベンチマークを作成することは常に微妙ですが、たまたま私はさまざまな言語で書かれたK-meansの単純なベンチマークを持っています- ここで見つけることができます。制約の1つは、さまざまな言語がすべて同じアルゴリズムを実装し、（速度の最適化とは対照的に）単純で慣用的なものになるように努めるべきであるということでした。私はすべての実装を書いたので、私がだまされていないことはわかっていますが、私が書いたものは慣用的であるとすべての言語で主張することはできません（私はそれらのいくつかについての知識しか持っていません）。

私は決定的な結論を主張していませんが、PyPyは、Nodeよりもはるかに優れており、私が得た最も速い実装の1つでした。代わりに、CPythonはランキングの最も遅い終わりにありました。

ステートメントは正確には真実ではありません

V8がJSの単なる実装であるように、CPythonはPythonの1つの実装にすぎません。PypyはV8に匹敵するパフォーマンスを備えています。

また、知覚されるパフォーマンスの問題もあります。V8は本来非ブロッキングであるため、IO待機を節約できるため、Web開発はよりパフォーマンスの高いプロジェクトにつながります。また、V8は主にIOが重要な開発Webに使用されるため、類似のプロジェクトと比較しています。しかし、Pythonはweb開発以外の多くの分野で使用できます。さらに、科学的な計算や暗号化などの多くのタスクにC拡張機能を使用して、非常に高いパフォーマンスでデータを処理することもできます。

しかし、ウェブでは、最も人気のあるPythonおよびRubyプロジェクトがブロックしています。特に、Pythonには同期WSGI標準のレガシーがあり、有名なDjangoのようなフレームワークはそれに基づいています。

非同期Python（Twisted、Tornado、gevent、asyncioなど）またはRubyを記述できます。しかし、それは頻繁には行われません。最高のツールはまだブロックしています。

ただし、RubyとPythonのデフォルト実装がV8ほど高速でない理由はいくつかあります。

経験

JörgW Mittagが指摘したように、V8に取り組んでいる人たちはVMの天才です。Pythonは、多くの分野で非常に優れた、情熱的な人々の集まりによって開発されていますが、VMのチューニングほど専門的ではありません。

資源

Python Software Foundationの資金は非常に少なく、Pythonに投資するための年間投資額は4万未満です。これは、Google、Facebook、Appleなどの大手企業がすべてPythonを使用していると考えると、ちょっとおかしいですが、醜い真実です。ほとんどの作業は無料で行われます。Youtubeを支え、Javaがボランティアによって手作りされた以前から存在していた言語。

彼らは賢く献身的なボランティアですが、畑でもっとジュースが必要だとわかったとき、彼らはこの専門分野の最高の専門家を雇うために30万人を要求することはできません。彼らは無料でそれをするだろう誰かを探し回らなければならない。

これは機能しますが、優先順位については非常に注意する必要があります。したがって、次のことを確認する必要があります。

目的

最新の最新機能を備えていても、Javascriptを書くのはひどいです。スコーピングの問題、非常に少ないコレクション、ひどい文字列と配列の操作、日付、数学、正規表現以外のstdlistがほとんどなく、非常に一般的な操作であっても構文上の問題はありません。

しかし、V8では速度が向上します。

これは、速度がChromeでのページレンダリングのボトルネックであるため、速度がGoogleの主な目的であったためです。

Pythonでは、使いやすさが主な目的です。プロジェクトのボトルネックになることはほとんどないからです。ここで不足しているリソースは開発者の時間です。開発者向けに最適化されています。

JavaScriptの実装では、バインディングの下位互換性を考慮する必要がないためです。

最近まで、JavaScript実装の唯一のユーザーはWebブラウザーでした。セキュリティ要件のため、ランタイムへのバインディングを記述して機能を拡張する特権を持っているのはWebブラウザーベンダーのみでした。したがって、バインディングのC APIに下位互換性を維持する必要はありませんでした。JavaScriptランタイムが進化するにつれて、Webブラウザーの開発者にソースコードの更新を要求することは許容されました。彼らはとにかく一緒に働いていました。ゲームの後発であり、非常に経験豊富な開発者によってリードされていたV8でさえ、APIが向上するにつれてAPIを変更しました。

OTOH Rubyは（主に）サーバー側で使用されます。多くの一般的なルビ拡張は、Cバインディングとして記述されています（RDBMSドライバーを検討してください）。つまり、互換性を維持しなければ、Rubyは成功しなかったでしょう。

現在でも、ある程度の違いはあります。node.jsを使用している開発者は、V8が時間の経過とともにAPIを変更するため、ネイティブ拡張の下位互換性を維持するのが難しいと不満を言っています（これがnode.jsがフォークされた理由の1つです）。IIRCルビーは、この点でいまだに保守的なアプローチを取っています。

V8は、JIT、クランクシャフト、型推論、およびデータ最適化コードにより高速です。タグ付きポインタ、ダブルのNaNタグ付け。そしてもちろん、途中で通常のコンパイラの最適化を行います。

単純なruby、python、およびperlエンジンは、これらのどちらも実行せず、マイナーな基本的な最適化のみを実行します。

近づく唯一の主要なvmはluajitです。これは、型推論、定数の折りたたみ、NaNタグ付け、整数も実行しませんが、同様の小さなコードとデータ構造を使用し、悪い言語ほど太っていません。そして、私のプロトタイプの動的言語、potionとp2は、luajitと同様の機能を備えており、v8よりも優れています。オプションのタイプシステムである「段階的なタイピング」を使用すると、クランクシャフトをバイパスできるため、v8を簡単に上回ることができます。ダーツを参照してください。

pypyやjrubyなどの既知の最適化されたバックエンドは、依然としてさまざまなオーバーエンジニアリングテクニックの影響を受けています。