LLVM、オウム、JVM、Pypy + Python

StackOverflow https://stackoverflow.com/questions/5328295

質問

いくつかの言語を開発する際の問題は何ですか。たとえば、LLVM /オウムの一部を使用したいくつかの最適化された手法のPythonなどです。

Pypy、LLVM、Parrotは、共通のプラットフォーム開発の主な技術です。
私はこれを次のように見ています：

  • パイキー -Python用の最適化されたVMでビルドを備えたVMを構築するフレームワーク
    したがって、それは非常に一般的な解決策です。プロセスはリストされているとおりに行われます：
    1. dynamic_language_code->
    2. Pypy Frontend->
    3. Pypy内部コード-bytecode->
    4. Pypy Optimization->
    5. Pypyコードを残すと：
      a。いくつかのVM用のPypyバックエンド（JVMなど）
      b。独自のVMを作成するSOMキット
      c。 Pypy内部コードの処理/実行

私はこのプロセスについて正しいですか？ Pythonには最適化されたVMがありますか？特にデフォルトでは、最適化されたPypyコード（ステップ5.c）のVMにビルドがあります - Python用のどちらで、すべての言語処理はそこで停止して実行できますか？

  • オウム - Pypyによく似ていますが、5.aと5.bがありませんか？動的処理のためのいくつかの内部改善（オウムマジッククッキー).

両方のオウム と パイキー 一般的な動的言語のランタイムを作成するプラットフォームを作成するように設計されていますが、Pypyはより多くのVMを作成することを望んでいます。
PypyのSensはどこにありますか？より多くのVMを作成するために必要なもののために？ 1つのVM（オウムのような）に集中する方が良いはずです - 一般的な1つのコードレベルがあるため、Pypy内部バイテコードまたはオウムのいずれかです。 Pypy VMSで新しく作成されたPypy Bytecodeに翻訳するのにこれ以上のことは何も得られないと思います。

  • LLVM - これはPypyに非常に似ていますが、VMジェネレーターがありません。
    それは、Pypyと同様のターゲットを備えた（ただしVMジェネレーターなし）が、低レベルの構造と優れた最適化/JITテクニックに取り組んでいる成熟した、適切に設計された環境です。

これを次のように見ていますか： LLVM 一般的な使用ですが、 オウム および** Pypy*動的言語向けに設計されています。 Pypy / Parrotでは、複雑なテクニックをより簡単に導入できます。これは、LLVMよりも高いレベルであるため、高レベルのコードをよりよく理解し、より良いアセンブラーコード（人間が合理的な時間で書くことができない）を生成できる洗練されたコンパイラのように、より簡単に導入できます。 llvm1？

質問：

  1. 私は正しいですか？たとえば、オウムよりもLLVMよりもダイナミック言語を移植する方が良い理由はありますか？

  2. オウムの開発Pythonでのアクティビティが表示されていません。 Python C拡張機能を使用してオウムで動作しないためですか？同じ問題がPypyにあります

  3. 他のVMがLLVM /オウムに移動したくない理由。例：ruby-> Parrot、clr/ jvm-> llvm。彼らがより洗練されたソリューションに移動するのは良いことではないでしょうか？ LLVMは開発プロセスが高く、大企業が投資しています。

  4. 問題はリソースである可能性があることを知っています。バイトコードを変更する必要がある場合 - しかし、それは義務的ではありません - 古いbytecodeに新しいバイトコードに移植しようとするので、新しいコンパイラが新しいbytecodeを生成することができます（まだ少ないJavaが必要ありません解釈した独自のbytecode-フロントエンドはそれをチェックして新しいbytecodeに変換できます）？

  5. LLVM内のJVMライブラリなどのリンクの問題は何ですか（何らかの形でJava/JVM/SCALAにLLVMに移植する場合）。

  6. 私がどこかで間違っているなら、あなたは私を訂正してくれませんか

いくつかの添加物：

=============

説明

このすべてのソフトウェアがどのように構成されているか、そして一方を他方に移植するための問題は何ですか。

役に立ちましたか？

解決

Stackoverflowの質問で誰も可能な回答を詰め込むことはできませんが、私はそれにミンマルショットを与えます。

最初に、3つのプロジェクトはどのような問題を解決しますか？

  1. Pypyを使用すると、高レベルの言語でインタープリターを実装でき、生成されたJITを無料で取得できます。これの良いところは、ランゲージとプラットフォームの間に依存の不一致がないことです。それが、Pypy-ClrがIronpythonよりも速い理由です。詳細はこちら： http://codespeak.net/pypy/dist/pypy/doc/extradoc.html - > cli/.netのPythonの高性能実装JITコンパイラ生成のためのJITコンパイラ生成）

  2. LLVMは、コンパイラ向けの低レベルのインフラストラクチャです。一般的なアイデアは、1つの「高レベルのアセンブリ」を持つことです。すべての順序はその言語で機能します。次に、コンパイラー（JITまたはAOT）の構築を支援するために、たくさんのインフラストラクチャがあります。 LLVMで動的言語を実装することは可能ですが、PypyやParrotで実装するよりも多くの作業が必要です。たとえば、GCを無料で入手することはできません（LLVMと一緒に使用できるGCがあります http://llvm.org/devmtg/2009-10/ - > vmkitビデオ）LLVMに基づいたダイナミックなランゴージュのプラットフォームをより良く構築しようとする試みがあります。 http://www.ffconsultancy.com/ocaml/hlvm/

  3. 私はオウムについてそれほど知りませんが、私が理解しているように、彼らはダイナミックなランゴージュに特化した1つの標準VMを構築したいと考えています（Perl、PHP、Python ....）。ここでの問題は、JVM/CLRへのコンパイルと同じです。 VMはまだあなたのランゲージのセマンティクスを知りません。私が解除するので、オウムはまだユーザーコードの場合はかなり遅いです。 （http://confreaks.net/videos/118-elcamp2010-parrot)

あなたの質問への答え：

私は正しいですか？たとえば、オウムよりもLLVMよりもダイナミック言語を移植する方が良い理由はありますか？

それは努力の問題です。あなた自身のためにあなたのためにあなた自身のために専門化されたことを常に構築することは最終的にはより速くなりますが、それはもっと努力しています。

オウムの開発Pythonでのアクティビティが表示されていません。 Python C拡張機能を使用してオウムで動作しないためですか？同じ問題がPypyにあります。

ターゲティングオウムは（この時点で）Pypyよりも利益をもたらさないでしょう。なぜ他の誰もそれをしないのか私は知らない。

他のVMがLLVM /オウムに移動したくない理由。例：ruby-> Parrot、clr/ jvm-> llvm。彼らがより洗練されたソリューションに移動するのは良いことではないでしょうか？ LLVMは開発プロセスが高く、大企業が投資しています。

その質問にはたくさんのことがあります。

  • 私が言ったように、LLVMは移動するのが難しく、オウムはそれほど速くありません（間違っている場合は修正してください）。
  • RubyはRubinius WitchがRubyで多くのことをしようとし、LLVMにジッツをしようとしています（http://llvm.org/devmtg/2009-10/ - > llvmでルビーを加速する）。
  • LLVMにはCLR/JVMの実装がありますが、どちらもすでに大きな投資を持っている非常に成熟した実装を持っています。
  • LLVMは高レベルではありません。

問題はリソースである可能性があることを知っています。バイトコードを変更する必要がある場合 - しかし、それは義務的ではありません - 古いbytecodeに新しいバイトコードに移植しようとするので、新しいコンパイラが新しいbytecodeを生成することができます（まだ少ないJavaが必要ありません解釈した独自のbytecode-フロントエンドはそれをチェックして新しいbytecodeに変換できます）？

質問が何であるかわかりません。

LLVM内のJVMライブラリなどのリンクの問題は何ですか（何らかの形でJava/JVM/SCALAにLLVMに移植する場合）。

私が上にリンクしたvmkitのビデオを見てください。

私がどこかで間違っているなら、あなたは私を訂正してくれませんか

あなたが書いたものがたくさんあるのは間違っているか、私はあなたが何を意味するのかを和らげませんが、私がリンクしたものは多くのものをより明確にするはずです。

いくつかの例：

Clojure

クリーターは、自分のVMとすべてのライブラリを実装するすべての作業を望んでいませんでした。では、どこに行くの？ Clojureは新しいランゴージであるため、PythonやRubyのような言語を多くのダイナミックなものを制限することにより、JVMのようなプラットフォームでうまく機能する方法で構築できます。

Python

言語を（実際に）JVM/CLRでうまく機能するように変更することはできません。したがって、それらにPythonを実装することは、大規模なスピードアップをもたらすことはありません。静的コンパイラもあまりうまく機能しません。これは、静的保証があまりないためです。 CでJITを書くのは高速ですが、変更が非常に困難です（PSYCOプロジェクトを参照）。 LLVM JITを使用することは機能し、Unladen Swallowプロジェクトによって調査されます（再び http://llvm.org/devmtg/2009-10/ - > laden wallow：llvmのpython）。一部の人々はPythonにPythonを持ちたいと思っていたので、Pypyとアイデアの縫い目を始めて、本当にうまく機能します（上記参照）。オウムも同様に機能する可能性がありますが、私は誰も試してみたのを見ていません（お気軽に）。

すべてについて：

私はあなたが混乱していると思います、そして私はそれを理解することができます。時間をかけて読んで、聞いて、あなたが得ることができるものすべてを見てください。自分を強調しないでください。これには多くの部分があり、最終的には、何がどのように適合し、何が理にかなっているのか、そしてあなたが多くのことを知っているときでさえ、まだ多くのことを議論することができます。問題は、新しい言語をどこで実装するか、古い言語をスピードアップする方法には多くの答えがあり、3人に尋ねると、3つの異なる答えが得られる可能性があります。

他のヒント

何を実装しようとしていますか？あなたの質問は非常に紛らわしいことです（私は英語があなたの第一言語ではない可能性が高いことを認識しています）。

LLVMとPypyはどちらも成熟した有用なプロジェクトですが、この時点ではあまり重複していません。 （ある時点で、PypyはCコードとは対照的に、通訳に静的にコンパイルされたLLVMバイトコードを生成することができましたが、パフォーマンスの利点はあまり提供されず、もはやサポートされていません。）

Pypyを使用すると、rpythonに通訳を書いて、それを説明として使用して、ネイティブコードインタープリターまたはJITを生成できます。 LLVMは、JITの実装にも使用できるコンパイラツールチェーンを構築するためのC ++フレームワークです。 LLVMのオプティマイザー、コード生成、プラットフォームのサポートは、Pypyのものよりもはるかに高度ですが、動的な言語ランタイムの構築にはあまり適していません（を参照 アンケートのツバメの回顧展 理由のいくつかの例については）。特に、PypyのトレースベースのJITほどランタイムフィードバックを収集/使用するのに効果的ではありません（これは、動的言語をうまく機能させるためには絶対に不可欠です）。また、LLVMのガベージコレクションのサポートは依然としてやや原始的であり、JITを自動的に生成するPypyのユニークな能力が欠けています。

ちなみに、2つのJava実装がLLVMに基づいています。J3/vmkit と 鮫.

あなたは見ることを検討するかもしれません パイキートーク 先週スタンフォードから。 Pypyの仕組みのかなりまともな概要を提供します。カール・フリードリッヒ・ボルツ プレゼンテーション また、VM実装の状態の適切な概要を提供します。

主な理由？ VMデザインはそうだからです いいえ 解決されたテクノロジーであり、さまざまな目標と目的を持つさまざまなVMを持つことで、すべてのメカニズムを並行して試してみることができます。

JVM、CLR、PYPY、PARROT、LLVM、およびその他はすべて、さまざまな方法で異なる種類の問題をターゲットにしています。 Chrome、Firefox、Safari、IEがすべて独自のJavaScriptエンジンを使用する理由に似ています。

Unladen SwallowはLLVMをCpythonに適用しようとし、Python固有のことを行うよりもLLVMで問題を修正するのに多くの時間を費やしました。

Python-on-Parrotは、Perl 6とPythonのセマンティックな違いに苦しんでおり、フロントエンドのコンパイルプロセスに問題を引き起こすため、この分野での将来の努力は、Pypyフロントエンドを使用してParrot VMをターゲットにする可能性があります。

さまざまなVM開発者は確かに他の人が何をしているのかを監視していますが、彼らが良いアイデアを持ち上げたとしても、彼らは彼らを組み込む前に彼らに彼らにスピンをかけます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top