15

LLVM / Parrotの一部を使用した最適化された手法のpythonなど、一部の言語の開発における問題は何ですか。

PyPy、LLVM、Parrot は、共通プラットフォーム開発の主要なテクノロジです。
私はこれを次のように見ます：

  • PyPy - Python 用に最適化された VM をビルドして VM を構築するためのフレームワーク
    。非常に一般的なソリューションです。プロセスは次のとおりです。
    1. dynamic_language_code ->
    2. PyPy フロントエンド ->
    3. PyPy 内部コード - バイトコード ->
    4. PyPy の最適化 ->
    5. PyPy コードを残し、次
      のことを行います。一部の VM (jvm など) の PyPy バックエンド
      b. 独自の VM を作成するための som キット
      c. PyPy 内部コードの処理/実行

このプロセスについて私は正しいですか? Pythonの場合、最適化されたVMがありますか? 特にデフォルトでは、最適化された PyPy コード (ステップ 5.c) 用の VM が組み込まれています。これは Python 用であり、すべての言語処理がそこで停止し、それによって実行されますか?

  • オウム- PyPy によく似ていますが、5.a と 5.b はありませんか? 動的処理 ( Parrot Magic Cookies ) のいくつかの内部改善。

ParrotとPyPyはどちらも、共通の動的言語ランタイムを作成するプラットフォームを作成するように設計されていますが、PyPy はさらに多くの VM を作成することも望んでいます。
PyPy の感覚はどこにありますか? より多くの VM を作成する必要があるのは何ですか? (parrot のように) 1 つの VM に集中するのは良いことではありません - PyPy 内部バイトコードまたは Parrot のもののいずれかの共通の 1 つのコード レベルがあるためです。PyPy VM で新しく作成された PyPy バイトコードに変換するのに勝るものはないと思います。

  • LLVM - これは PyPy と非常によく似ていますが、VM ジェネレーターはありません。
    PyPy と同様のターゲット (ただし VM ジェネレーターはありません) を備えた成熟した適切に設計された環境ですが、低レベルの構造に取り組んでおり、優れた最適化/JIT 手法が実装されています。

これは次のように見えます: LLVMは一般的に使用されますが、Parrotと **PyPy* は動的言語用に設計されています。PyPy / Parrot では、LLVM よりも高レベルであるため、いくつかの複雑な手法を簡単に導入できます。たとえば、高レベルのコードをよりよく理解し、より優れたアセンブラー コードを生成できる洗練されたコンパイラー (人間が合理的な時間で作成できない) などです。 LLVMのもの？

質問:

  1. 私は正しいですか？いくつかの動的言語を移植する方が、たとえば Parrot よりも llvm に適している理由はありますか?

  2. Parrot での Python 開発の活動は見られません。python C拡張機能を使用するとオウムが機能しないためですか？同じ問題が PyPy にあります

  3. 他の VM が LLVM / オウムに移行したくない理由。例: ruby​​ -> オウム、CLR/ JVM -> LLVM。より洗練されたソリューションに移行する方がよいのではないでしょうか? LLVM は高度な開発プロセスにあり、大企業が投資しています。

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

  5. たとえば、llvm 内の jvm ライブラリをリンクする際の問題は何ですか (何らかの方法で java/jvm/scala を llvm に移植する場合)?

  6. どこか間違っていたら訂正してもらえますか

いくつかの追加：

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

明確化

私は、このソフトウェアがどのように構成されているかを理解したいと思っています。

4

3 に答える 3

25

それは誰もがスタックオーバーフローの質問で答えることができるものではありませんが、私はそれに最小限のショットを与えます。

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

  1. pypyを使用すると、高水準言語でインタープリターを実装でき、生成されたjitを無料で入手できます。これの良いところは、言語とプラットフォームの間に依存関係の不一致がないことです。これが、pypy-clrがIronPythonよりも高速である理由です。詳細はこちら：http ：//codespeak.net/pypy/dist/pypy/doc/extradoc.html- >動的用のJITコンパイラ生成を使用したCLI /.NET用のPythonの高性能実装）

  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. 私はオウムについてあまり知りませんが、私が理解しているように、彼らは動的言語（perl、php、python ....）に特化した1つの標準VMを構築したいと考えています。ここでの問題は、JVM / CLRにコンパイルする場合と同じで、依存関係の不一致がありますが、それははるかに小さいものです。VMはまだ言語のセマンティクスを認識していません。私が理解しているように、オウムはまだユーザーコードに対してかなり遅いです。（http://confreaks.net/videos/118-elcamp2010-parrot）

あなたの質問への答え：

私は正しいですか？いくつかの動的言語を移植する方が、たとえばParrotよりもllvmに適している理由はありますか？

それは努力の問題です。自分自身を構築し、自分に特化したものを構築することは、最終的にはより速くなりますが、それははるかに多くの努力です。

Parrotでの開発Pythonのアクティビティは見ていません。Python C拡張機能を使用してもオウムでは機能しないためですか？同じ問題がPyPyにもあります。

オウムをターゲットにすることは、（現時点では）pypyよりもメリットがない可能性があります。なぜ誰もそれをしないのか私にはわかりません。

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

わかりました、その質問にはたくさんのものがあります。

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

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

質問が何なのかわかりません。

たとえば、llvm内のjvmライブラリをリンクすることの問題は何ですか（何らかの方法でjava / jvm / scalaをllvmに移植する場合）？

上でリンクしたVMKitのビデオを見て、彼らがどこまで到達し、問題が何であるか（そして彼らがそれをどのように解決したか）を示します。

どこか間違っていたら訂正してもらえますか

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

いくつかの例：

Clojure

作成者は、自分のVMとすべてのライブラリを実装するためのすべての作業を望んでいませんでした。では、どこに行くのですか？Clojureは新しい言語であるため、Pythonやrubyのような言語が持つであろう多くの動的なものを制限することにより、JVMのようなプラットフォームでうまく機能する方法でClojureを構築できます。

Python

言語は、JVM / CLRで適切に機能するように（実際には）変更できません。したがって、それらにpythonを実装しても、大幅な高速化はもたらされません。静的な保証があまりないため、静的コンパイラもうまく機能しません。CでJITを作成するのは高速ですが、変更するのは非常に困難です（psycoプロジェクトを参照）。llvm jitの使用は機能する可能性があり、Unladen Swallowプロジェクト（ここでもhttp://llvm.org/devmtg/2009-10/- > Unladen Swallow：Python on LLVM）によって調査されています。何人かの人々はPythonでPythonを使いたいと思ったので、彼らはpypyを始め、彼らのアイデアの継ぎ目は本当にうまく機能しました（上記を参照）。オウムも同様に機能する可能性がありますが、私は誰も試したことがありません（お気軽に）。

すべてについて：

あなたは混乱していると思います、そして私はそれを理解することができます。時間をかけて読んで、聞いて、手に入るすべてのものを見てください。ストレスを感じないでください。これには多くの部分があり、最終的には、何がどのように組み合わされ、何が理にかなっているのかがわかります。多くのことを知っている場合でも、まだ多くの議論があります。問題は、新しい言語をどこに実装するか、または古い言語を高速化する方法には多くの答えがあり、3人に質問すると、3つの異なる答えが得られる可能性が高いということです。

于 2011-05-02T22:11:58.213 に答える
11

何を実装しようとしていますか？あなたの質問は非常に紛らわしい言い回しです (英語があなたの母国語ではない可能性が高いことは承知しています)。

LLVM と PyPy はどちらも成熟した有用なプロジェクトですが、現時点ではあまり重複していません。(ある時点で、PyPy は、C コードではなく LLVM バイトコード (インタープリターに静的にコンパイルされたもの) を生成できましたが、パフォーマンス上の利点はあまりなく、サポートされなくなりました。)

PyPy を使用すると、RPython でインタープリターを記述し、それを記述として使用してネイティブ コード インタープリターまたは JIT を生成できます。LLVM は、JIT の実装にも使用できるコンパイラ ツールチェーンを構築するための C++ フレームワークです。LLVM のオプティマイザ、コード生成、およびプラットフォーム サポートは、PyPy よりもはるかに高度ですが、動的言語ランタイムの構築にはあまり適していません (理由の例については、 Unladen Swallow 回顧録を参照してください)。特に、PyPy のトレースベースの JIT ほど、実行時フィードバックの収集/使用 (動的言語を適切に実行するために不可欠です) ほど効果的ではありません。また、LLVM のガベージ コレクションのサポートはまだ原始的であり、JIT を自動的に生成する PyPy 独自の機能が欠けています。

ちなみに、2 つの Java 実装は LLVM で構築されています — <a href="http://vmkit.llvm.org/" rel="noreferrer">J3/VMKit とSharkです。

先週、スタンフォードで開催されたPyPy の講演を視聴することを検討してください。PyPy がどのように機能するかについてのかなりまともな概要を提供します。Carl Friedrich Bolz のプレゼンテーションも、VM 実装の状態の概要を説明しています。

于 2011-03-16T20:59:19.820 に答える
7

主な理由？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 開発者が、他の開発者が行っていることに目を光らせていることは確かですが、彼らが良いアイデアを思いついたとしても、それらを組み込む前に独自の解釈を加えます。

于 2011-03-16T20:25:34.973 に答える