Javascript V8の速度を得るためにRuby、Pythonをブロックしているのは何ですか？
最適化の実装をブロックしているRuby/Python機能はありますか（例 インラインキャッシュ ）V8エンジンにはありますか？
PythonはGoogleのメンバーによって共同開発されているため、ソフトウェア特許によってブロックされるべきではありません。
または、これはむしろGoogleがV8プロジェクトに投入したリソースの問題です。
Javascript V8の速度を得るために、Ruby、Pythonをブロックするのは何ですか？
なし。
まあ、大丈夫：お金。 （そして時間、人、リソース、しかしお金があれば、それらを買うことができます。）
V8には、高性能の実行を作成する数十年の経験（個別に話しています-集合的には世紀のようなものです）に取り組んでいる、優秀で高度な経験のある（したがって高給の）エンジニアのチームがいます動的OO言語用のエンジン。彼らは基本的に、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のクラスよりも高速です。これで、RubiniusのHashクラスが100％純粋なRubyで実装され、YARVが100％手で最適化されたCで実装されることに気付くまで、これはひどくエキサイティングではありません。
そのため、少なくとも場合によっては、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はすべて1つに加えて、他にもいくつかの作業を行いました。
JavaScriptインタープリターを高度に最適化することへのより多くの推進力があります。それが、Mozilla、Google、およびMicrosoftの間で非常に多くのリソースがそれらに置かれるのを見る理由です。 JavaScriptは、（通常はせっかちな）人間が待っている間、リアルタイムでダウンロード、解析、コンパイル、実行する必要があります。コンピュータ、電話、トースターなどの環境。これらの条件下で効果的に実行するには、効率的である必要があります。
PythonとRubyは、開発者/デプロイヤが制御する環境で実行されます。一般に、制限要因が実行時間ではなくメモリやディスクI/Oのようなものになるような、巨大なサーバーまたはデスクトップシステム。または、キャッシングなどのエンジン以外の最適化を利用できる場合。これらの言語では、おそらく速度の最適化よりも言語とライブラリの機能セットに焦点を当てる方が理にかなっています。
この副次的な利点は、Node.jsなどのあらゆる種類のアプリケーションに再利用できる、そして再利用されている2つの優れた高性能のオープンソースJavaScriptエンジンがあることです。
その大部分はコミュニティに関係しています。 PythonおよびRubyの大部分は企業の支援を受けていません。 PythonおよびRubyのフルタイムで働くための報酬はありません（特に、CPythonまたはMRIでの仕事中は特に報酬を受け取りません）。一方、V8は、世界で最も強力なIT企業に支えられています。
さらに、V8の人々にとって重要なのはインタプリタだけであるため、V8の方が高速化できます。標準ライブラリがなく、言語設計の心配もありません。彼らは通訳を書くだけです。それでおしまい。
知的財産法とは関係ありません。 Pythonは、Googleの開発者と共同開発していません（その作成者は他の数人のコミッターと一緒にそこで働いていますが、Pythonで作業するための支払いを受けていません）。
Python速度のもう1つの障害はPythonです。3。その採用は、言語開発者の主な関心事のようです。つまり、他の実装まで新しい言語機能の開発を凍結しています。追いつく。
技術的な詳細については、Rubyについてあまり知りませんが、Pythonには最適化を使用できる場所がいくつかあります（そして、GoogleプロジェクトのUnladen Swallowは、ほこりをかむ前にこれらを実装し始めました） ）。 ここに彼らが計画した最適化の一部があります 。 JIT a la PyPyがCPythonに実装されると、将来的にPythonがV8の速度を上げることがわかりますが、今後数年間はそうなるとは思われません（現在の焦点はPython 3 JITではなく採用）。
また、多くの人は、RubyとPythonがそれぞれの グローバルインタープリターロック を削除することで大きな恩恵を受けると感じています。
また、PythonとRubyはどちらもJSよりもはるかに重い言語であるということを理解する必要があります。これらは、標準ライブラリ、言語機能、および構造の点ではるかに優れています。オブジェクト指向のクラスシステムだけでも、かなりの重量が追加されます（いい意味で）。 Javascriptは、Luaのように埋め込み用に設計された言語であるとほとんど思います（多くの点で似ています）。 RubyとPythonには豊富な機能セットがあり、その表現力は通常、速度を犠牲にします。
パフォーマンスは、コアPython開発者の主要な焦点ではないようです。開発者は、「十分に高速」で十分であり、プログラマの生産性向上に役立つ機能は、コンピューターがコードをより速く実行できるようにします。
ただし、実際には、標準のインタープリターと互換性のある高速のPythonインタープリターを作成するために、（現在は放棄されている）Googleプロジェクト nladen-swallow がありました。 PyPy は、より高速なPythonを作成することを目的とした別のプロジェクトです。また、インタプリタ全体を変更することなく、多くのPythonスクリプトのパフォーマンスを向上できるPyPyの前身である Psyco と、 Cython があります。 Python構文に非常によく似たものを使用して、Python用の高性能Cライブラリを作成できます。
誤解を招く質問。 V8はJavaScriptのJIT（ジャストインタイムコンパイラー）実装であり、最も一般的な非ブラウザー実装Node.jsではイベントループを中心に構築されます。 CPythonはJITではなく、イベントも発生しません。ただし、これらはPythonに存在し、最も一般的にはPyPyプロジェクト（CPython 2.7（およびすぐに3.0+）互換JIT）に存在します。また、Tornadoなどのイベントサーバーライブラリが多数あります。 Tornadoを実行するPyPyとNode.jsの間に実世界のテストが存在し、パフォーマンスの違いはわずかです。
設計の優先順位とユースケースの目標が異なるため、私は信じています。
一般的に、スクリプト（動的）言語の主な目的は、ネイティブ関数の呼び出し間の「接着剤」になることです。そして、これらのネイティブ機能は、a）最も重要/頻繁に使用される領域をカバーし、b）可能な限り効果的でなければなりません。
以下に例を示します。 jQueryソートによりiOS Safariがフリーズする そこにあるフリーズは、get-by-selector呼び出しの過度の使用が原因です。 get-by-selectorがネイティブコードで実装され、実質的にそのような問題が発生しない場合。
V8デモで頻繁に使用されるデモであるレイトレーサーデモを検討してください。 Pythonの世界では、Pythonがネイティブ拡張のすべての機能を提供するため、ネイティブコードで実装できます。ただし、V8レルム（クライアント側のサンドボックス）では、VMを可能な限り[サブ]効果にする以外に、他のオプションはありません。したがって、唯一のオプションは、スクリプトコードを使用することによるレイトレーサーの実装を確認することです。
異なる優先順位と動機。
Sciter では、ほぼ完全なjQureyコアをネイティブに実装してテストを行いました。 ScIDE （HTML/CSS/Scriptで作成されたIDE）のような実用的なタスクでは、このようなソリューションはVM最適化よりもはるかに優れていると思います。
私はちょうどこの質問に出くわしましたが、言及されていないパフォーマンスの違いには大きな技術的理由もあります。 Pythonには強力なソフトウェア拡張機能の非常に大きなエコシステムがありますが、これらの拡張機能のほとんどはパフォーマンスのためにCまたは他の低レベル言語で記述されており、CPython APIに大きく結びついています。
CPythonの実装を高速化するために使用できるよく知られた手法（JIT、最新のガベージコレクターなど）が多数ありますが、いずれもAPIの大幅な変更が必要であり、プロセスのほとんどの拡張機能が破壊されます。 CPythonは高速になりますが、Pythonを魅力的なもの（大規模なソフトウェアスタック）の多くは失われます。適切な例として、いくつかのより高速なPython実装がありますが、CPythonと比較してほとんど牽引力がありません。
声明は正確ではない
V8がJSの単なる実装であるように、CPythonはPythonのただの実装です。 PypyはV8に匹敵するパフォーマンスを持っています 。
また、認識されるパフォーマンスの問題もあります。V8はネイティブに非ブロッキングであるため、IO待機時間を節約するため、Web devはよりパフォーマンスの高いプロジェクトにつながります。また、V8は主にIOがキーとなる開発Webで使用されるため、同様のプロジェクトと比較されます。ただし、Pythonは、Web開発以外の多くの分野で使用できます。また、科学的な計算や暗号化などの多くのタスクにC拡張機能を使用したり、燃えるようなパフォーマンスでデータを処理したりすることもできます。
しかし、Webでは、最も人気のあるPythonおよびRubyプロジェクトがブロックされています。特にPythonには、同期WSGI標準のレガシーがあり、有名なDjangoのようなフレームワークはそれに基づいています。
非同期Python（Twisted、Tornado、gevent、asyncioなど）またはRubyを記述できます。しかし、それは頻繁に行われません。最高のツールはまだブロックされています。
ただし、RubyおよびPythonのデフォルトの実装がV8ほど高速ではない理由はいくつかあります。
経験
JörgW Mittagが指摘したように、V8に取り組んでいるのはVM天才です。 Pythonは、多くのドメインで非常に優れた情熱的な人々によって開発されていますが、VMチューニングに特化してはいません。
資源
Pythonソフトウェア基盤にはほとんどお金がありません： 40k未満 Pythonに投資するために1年で。これは、Google、Facebook、またはAppleなどの大手企業がすべてPythonを使用していると思うとちょっとおかしくなりますが、itい真実です。ほとんどの作業は無料で行われます。 Youtubeの原動力であり、Javaの前に存在した言語は、ボランティアによって手作りされました。
彼らは賢明で献身的なボランティアですが、フィールドでさらにジュースが必要だと判断した場合、この専門分野のトップスペシャリストを雇うために300kを要求することはできません。彼らは無料でそれをする誰かを探し回らなければなりません。
これは機能しますが、優先順位に非常に注意する必要があることを意味します。したがって、次を確認する必要があります。
目的
最新の最新機能を備えていても、Javascriptの記述はひどいものです。スコーピングの問題、非常に少ないコレクション、ひどい文字列と配列の操作、日付、数学、正規表現以外のstdlistがほとんどなく、非常に一般的な操作であっても構文糖衣がありません。
しかし、V8では、速度があります。
これは、Chromeでのページレンダリングのボトルネックであるため、速度がGoogleの主な目的だったためです。
Pythonでは、ユーザビリティが主な目的です。プロジェクトのボトルネックになることはほとんどないからです。ここで不足しているリソースは、開発者の時間です。開発者向けに最適化されています。
他の人が言及したように、Pythonには PyPy の形式の高性能JITコンパイラがあります。
意味のあるベンチマークを作成することは常に微妙ですが、たまたま K-means という異なる言語で書かれた簡単なベンチマークがあります。それは here です。制約の1つは、さまざまな言語がすべて同じアルゴリズムを実装し、（速度の最適化とは対照的に）単純で慣用的なものになるよう努力する必要があるということでした。私はすべての実装を書いたので、だましていないことは知っていますが、私が書いたものが慣用的であるとすべての言語で主張することはできません（私はそれらの一部の通過知識しかありません）。
決定的な結論を主張することはありませんが、PyPyはNodeよりもはるかに優れた最速の実装です。代わりに、CPythonはランキングの最も遅い終わりにありました。
JavaScript実装は、バインディングの後方互換性を気にする必要がないためです。
最近まで、JavaScript実装のユーザーはWebブラウザーのみでした。セキュリティ要件のため、Webブラウザーベンダーのみが、バインディングをランタイムに書き込むことによって機能を拡張する特権を持ちました。したがって、バインディングのC APIの下位互換性を維持する必要はありませんでした。JavaScriptランタイムの進化に伴い、Webブラウザーの開発者にソースコードの更新を要求することは許可されました。とにかく一緒に働いていました。ゲームの後発であり、非常に経験豊富な開発者が率いるV8でさえ、APIが改良されるにつれて変更されました。
OTOH Rubyは（主に）サーバー側で使用されます。人気のあるRuby拡張機能の多くは、Cバインディングとして記述されています（RDBMSドライバーを検討してください）。言い換えれば、Rubyは互換性を維持しないと成功しなかったでしょう。
今日、その違いはある程度存在しています。 node.jsを使用している開発者は、V8が時間とともにAPIを変更するため、ネイティブ拡張の下位互換性を維持するのが難しいと不平を言っています（そして、それがnode.jsがフォークされた理由の1つです）。 IIRC Rubyは、この点でさらに保守的なアプローチを取っています。
V8は、JIT、クランクシャフト、型推論器、データ最適化コードにより高速です。タグ付きポインター、ダブルのNaNタグ付け。そしてもちろん、途中で通常のコンパイラー最適化を行います。
単純なRuby、python、およびPerlエンジンはこれらのどちらも実行せず、わずかな基本的な最適化のみを行います。
近づいてくる唯一の主要なvmはluajitです。これは、型推論、定数の折りたたみ、NaNタグ付け、整数も行いませんが、同様の小さなコードとデータ構造を使用します。そして、私のプロトタイプの動的言語であるpotionとp2には、luajitと同様の機能があり、v8よりも優れています。オプションのタイプシステム「漸進的タイピング」を使用すると、クランクシャフトをバイパスできるため、v8を簡単に上回ることができます。 Dartを参照してください。
Pypyやjrubyのような既知の最適化されたバックエンドには、さまざまなオーバーエンジニアリング手法がまだあります。