LLVM、Parrot、JVM、PyPy + Python
开发某些语言有什么问题，例如 python 与 LLVM / Parrot 的一些优化技术。
PyPy、LLVM、Parrot是通用平台开发的主要技术。
我看到这样的内容：
- PyPy - 构建 VM 的框架，内置针对 python 优化的 VM
所以它是相当通用的解决方案。该过程如下所列：- 动态语言代码 ->
- PyPy 前端 ->
- PyPy 内部代码 - 字节码 ->
- PyPy 优化 ->
- 留下 PyPy 代码并：
一个。某些 VM（如 jvm）的 PyPy 后端
b. som Kit 来制作自己的虚拟机
c.处理/运行 PyPy 内部代码
- 动态语言代码 ->
关于这个过程我说得对吗？对于python有优化的VM吗？特别是默认情况下，VM 中有用于优化 PyPy 代码的构建（步骤 5.c） - 这是针对 python 的，并且每种语言处理都可以在那里停止并通过它运行？
- Parrot - 很像 PyPy，但没有 5.a 和 5.b ？动态处理的一些内部改进（Parrot Magic Cookies）。
Parrot 和 PyPy 都旨在创建一个平台，该平台可创建通用动态语言运行时，但 PyPy 想要更多 - 还创建更多 VM。
PyPy 的意义在哪里？我们为什么需要创建更多VM？不应该更好地专注于一个虚拟机（就像在 parrot 中一样） - 因为有一个共同的代码级别 - 要么是 PyPy 内部字节码，要么是 Parrot 字节码。 我认为我们无法将其转换为 PyPy 字节码以使用 PyPy 虚拟机新创建。
- LLVM - 我认为这与 PyPy 非常相似，但没有 VM 生成器。
它是成熟的、设计良好的环境，具有与 PyPy 类似的目标（但没有 VM 生成器），但致力于低级结构和实现的出色优化/JIT 技术将
其视为：LLVM 是通用的，但是 < strong>Parrot 和 **PyPy* 专为动态语言而设计。在 PyPy / Parrot 中更容易引入一些复杂的技术 - 因为它比 LLVM 更高级别 - 比如复杂的编译器，可以更好地理解高级代码并生成更好的汇编代码（人类无法在合理的时间内编写），然后LLVM 吗？
问题：
我说得对吗？有什么理由认为将某些动态语言移植到 llvm 会比移植到 Parrot 更好？
我还没有在 Parrot 上看到开发 python 的活动。是因为使用 python C 扩展在 parrot 上不起作用吗？同样的问题在 PyPy 中
为什么其他虚拟机不想迁移到 LLVM/parrot。例如红宝石->鹦鹉，CLR/JVM -> LLVM。对于他们来说，转向更复杂的解决方案不是更好吗？ LLVM 正处于高度开发阶段，并且有大公司投资。
我知道问题可能出在重新编译资源上，如果需要更改字节码 - 但这不是强制性的 - 因为我们可以尝试将旧字节码移植到新的，新的编译器产生新的字节码（java仍然需要解释自己的字节码 - 所以前端可以检查它并将其翻译为新的字节码）？
在 llvm 内链接例如 jvm 库有什么问题（如果我们以某种方式将 java/jvm/scala 移植到 llvm）？
如果我在某个地方错了，你可以纠正我
一些补充：
=============
澄清
我想弄清楚所有这些软件是如何组成的 - 以及什么是将一个移植到另一个的问题。
What is the problem in developing some languages, for example python for some optimized techniques with some of LLVM / Parrot.
PyPy, LLVM, Parrot are the main technologies for common platform development.
I see this like:
- PyPy - framework to build VM with build in optimized VM for python
So it quite general solution. The process goes as listed down:- dynamic_language_code ->
- PyPy frontend ->
- PyPy internal code - bytecode ->
- PyPy optimization ->
- leaving PyPy code and:
a. PyPy backend for some VM (like jvm)
b. som Kit to make own VM
c. processing/running PyPy internal code
Am I right About this process? For python there is optimized VM? Particularly by default there is build in VM for optimized PyPy code (step 5.c) - which is for python and every language processing can stop there and be running by it?
- Parrot - much like PyPy, but without 5.a and 5.b ? Some internal improvements for dynamic processing (Parrot Magic Cookies).
Both Parrot and PyPy are designed to create a platform which create a common dynamic languages runtime, but PyPy wants more - also to create more VM.
Where is the sens of PyPy? For what we need to create more VM? Shouldn't be better to focus on one VM (like in parrot) - because there is common one code level - either PyPy internal bytecode or Parrot ones.
I think we can't gain nothing better to translate to PyPy bytecode to newly created with PyPy VMs.
- LLVM - i see this very similar to PyPy but without VM generator.
It is mature, well designed environment with similar targets as PyPy (but without VM generator) but working on low level structure and great optimization/JIT techniques implemeted
Is see this as: LLVM is general use, but Parrot and **PyPy* designed for dynamic languages. In PyPy / Parrot is more easy to introduce some complicated techniques - because it is more high level then LLVM - like sophisticate compiler which can better understand high level code and produce better assembler code (which humans can't write in reasonable time), then the LLVM one?
Questions:
Am I right? Is there any reason that porting some dynamic language would be better to llvm then to for example Parrot?
I haven't see the activity on development python on Parrot. Is it because using python C extensions doesn't work on parrot? The same problem is in PyPy
Why other VMs don't want to move to LLVM / parrot. Eg ruby -> parrot, CLR/ JVM -> LLVM. Wouldn't be better for them to move to more sophisticated solution? LLVM is in high development process and has big companies investing in.
I know the problem might be in recompile are resources, if there is need to change bytecode - but it is not obligatory - as we can try to port old bytecode to new one, and new compilers produce new bytecode (never less java still need to interpreted own bytecode - so the frontend can check it and translate it to new bytecode)?
What are the problems with linking for example jvm libraries inside llvm (if we port somehow java/jvm/scala to llvm)?
Can you correct me if i'm wrong somewhere
Some addings:
- How does Parrot compare to other virtual machines
- What's the benefit of Parrot VM for end-users
- What are the differences between LLVM and java/jvm
=============
CLARIFICATION
I want to figure how all this software consist - and what is the problem to porting one to other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这不是任何人都可以在 stackoverflow 问题中回答的内容，但我会尽量尝试。
首先这3个项目解决什么问题？
pypy 允许您用高级语言实现解释器，并且您可以免费获得生成的 jit。这样做的好处是语言和平台之间不会出现依赖不匹配的情况。这就是 pypy-clr 比 IronPython 更快的原因。
更多信息在这里： http://codespeak.net/pypy/dist/pypy/doc /extradoc.html -->用于 CLI/.NET 的 Python 的高性能实现（具有动态 JIT 编译器生成）
llvm 是编译器的低级基础架构。总的想法是召开一次“高层集会”。所有优化都适用于该语言。然后有大量的基础设施可以帮助您构建编译器（JIT 或 AOT）。在 llvm 上实现动态语言是可能的，但需要比在 pypy 或 parrot 上实现更多的工作。例如，您无法免费获得 GC（您可以将 GC 与 LLVM 一起使用，请参阅 http://llvm.org/devmtg/2009-10/ --> vmkit 视频）有人尝试基于 llvm 构建更好的动态语言平台：http://www.ffconsultancy.com/ocaml/hlvm/
我对鹦鹉了解不多，但正如我所言了解他们想要构建一个专门用于动态语言（perl、php、python ....）的标准虚拟机。这里的问题与编译到 JVM/CLR 时的问题相同，存在依赖项不匹配，只是小得多。虚拟机仍然不知道您的语言的语义。据我了解，parrot 对于用户代码来说仍然相当慢。 (http://confreaks.net/videos/118-elcamp2010-parrot)
答案对于你的问题：
这就是努力的问题。自己构建并专门为您打造的一切最终会更快，但需要付出更多的努力。
以 parrot 为目标（在这一点上）不太可能比 pypy 有好处。为什么没有人这样做我不知道。
好吧，这个问题有很多内容。
我不知道问题是什么。
观看我上面链接的 VMKit 视频，该视频显示了他们走了多远以及问题是什么（以及他们如何解决它）。
你写的很多东西都是错误的，或者我只是不明白你的意思，但我链接的东西应该让很多东西更清晰。
一些例子：
创建者不想要实现他自己的虚拟机和所有库的所有工作。那么去哪里呢？由于 Clojure 是一种新语言，因此您可以通过限制 python 或 ruby 等语言拥有的大量动态内容，以在 JVM 等平台上良好运行的方式构建它。
该语言（实际上）无法更改为在 JVM/CLR 上正常工作。因此，在这些上实现 python 不会带来巨大的加速。静态编译器也不会很好地工作，因为没有太多静态保证。用 C 语言编写 JIT 速度很快，但很难更改（请参阅 psyco 项目）。使用 llvm jit 是可行的，Unladen Swallow 项目对此进行了探索（再次http://llvm.org/ devmtg/2009-10/ --> Unladen Swallow：LLVM 上的 Python）。有些人想在 python 中使用 python，所以他们开始使用 pypy，他们的想法看起来效果非常好（见上文）。 Parrot 也可以工作，但我还没有看到有人尝试过（随意）。
关于一切：
我认为你很困惑，我可以理解。花点时间阅读、聆听、观看你能得到的一切。不要给自己太大压力。这有很多部分，最终你会看到什么是如何组合在一起的以及什么是有意义的，即使你知道很多，仍然有很多讨论可以做。问题是在哪里实现新语言或如何加速旧语言有很多答案，如果你问 3 个人，你可能会得到三个不同的答案。
That not stuff anybody can possible answer in a stackoverflow questions but i give it a minmal shot.
First what problems do the 3 projects solve?
pypy allows you to implement an interpreter in a high level language and you get a generated jit for free. The good thing about this is that you don't have a dependence mismatch between the langauge and the platform. Thats the reason why pypy-clr is faster then IronPython.
More info here: http://codespeak.net/pypy/dist/pypy/doc/extradoc.html --> High performance implementation of Python for CLI/.NET with JIT compiler generation for dynamic)
llvm is a low level infrastructure for compilers. The general idea is to have one "high level assembly". All the optomizations work on that language. Then there is tons of infrastructure around to help you build compilers (JIT or AOT). Implementing a dynamic language on llvm is possible but needs more work then implementing it on pypy or parrot. You, for example, can't get a GC for free (there are GC you can use together with LLVM see http://llvm.org/devmtg/2009-10/ --> the vmkit video ) There are attempts to build a platform better for dynamic langauges based on llvm: http://www.ffconsultancy.com/ocaml/hlvm/
I don't know that much about parrot but as I understand they want to build one standard VM specialized for dynamic langauges (perl, php, python ....). The problem here is the same as with compiling to JVM/CLR there is a dependency missmatch, just a much smaller one. The VM still does not know the semantics of your langauge. As I unterstand parrot is still pretty slow for user code. (http://confreaks.net/videos/118-elcamp2010-parrot)
The answer to your question:
Thats a question of effort. Building everthing your self and specialized for you will eventually be faster but it's a LOT more effort.
Targeting parrot would (at this point) not likely have a benefit over pypy. Why nobody else does it I don't know.
Ok there is a lot of stuff in that question.
I have no idea what the question is.
Watch the video of VMKit I linked above that show how far they got and what the problem is (and how they solved it).
Lots of stuff you wrote is wrong or I just don't anderstand what you mean, but the stuff I linked should make a lot of stuff clearer.
Some examples:
The creater didn't want all the work of implementing his own vm and all the libraries. So where to go to? Since Clojure is a new langauge you can build it in a way that works well on a platform like the JVM by restricting a lot of dynamic stuff a language like python or ruby would have.
The language can't (practically) be changed to work well on JVM/CLR. So implementing python on those wont bring massive speedups. Static compiler won't work very well either because there are not many static guarantees. Writing a JIT in C will be fast but very hard to change (see the psyco project). Using the llvm jit could work and is explored by the Unladen Swallow project (again http://llvm.org/devmtg/2009-10/ --> Unladen Swallow: Python on LLVM). Some people wanted to have python in python so they started pypy and their idea seams to work really well (see above). Parrot could work as well but I have not seen anybody have try (feel free).
On everything:
I think you're confused and I can understand that. Take your time and read, listen, watch everything you can get. Don't stress yourself. There are a lot of parts to this and eventually you see how what fits together and what makes sense and even when you know a lot there is still a lot of discussing one may do. The question is where to implement a new language or how to speed up a old language have many answers and if you ask 3 people you're likely to get three different answers.
你想实现什么？你的问题措辞非常混乱（我意识到英语可能不是你的母语）。
LLVM 和 PyPy 都是成熟、有用的项目，但目前确实没有太多重叠。 （在某一时刻，PyPy 可以生成 LLVM 字节码（与 C 代码相反，它被静态编译为解释器），但它没有提供太多性能优势，并且不再受支持。）
PyPy 允许您编写解释器RPython 并使用它作为描述来生成本机代码解释器或 JIT； LLVM 是一个用于构建编译器工具链的 C++ 框架，也可用于实现 JIT。 LLVM 的优化器、代码生成和平台支持比 PyPy 先进得多，但它不太适合构建动态语言运行时（请参阅 Unladen Swallow 回顾 了解一些原因示例）。特别是，它在收集/使用运行时反馈（这对于使动态语言表现良好绝对必要）方面不如 PyPy 基于跟踪的 JIT 有效。此外，LLVM 的垃圾收集支持仍然有些原始，并且缺乏 PyPy 自动生成 JIT 的独特能力。
顺便说一句，有两个 Java 实现是基于 LLVM 构建的：J3/VMKit 和 鲨鱼。
您可以考虑观看斯坦福大学的 Py 演讲上星期;它对 PyPy 的工作原理提供了相当不错的概述。 Carl Friedrich Bolz 的演示文稿也提供了很好的概述VM 实现的状态。
What are you trying to implement? Your question is very confusingly worded (I realize English is likely not your first language).
LLVM and PyPy are both mature, useful projects, but really don't overlap much at this point. (At one point, PyPy could generate LLVM bytecode—which was statically compiled to an interpreter—as opposed to C code, but it didn't provide much of a performance benefit and is no longer supported.)
PyPy lets you write an interpreter in RPython and use that as a description to generate a native code interpreter or JIT; LLVM is a C++ framework for building a compiler toolchain which can also be used to implement a JIT. LLVM's optimizers, code generation and platform support are significantly more advanced than those of PyPy, but it isn't as well suited to building a dynamic language runtime (see the Unladen Swallow retrospective for some examples of why). In particular, it is not as effective at collecting/using runtime feedback (which is absolutely essential for making dynamic languages perform well) as PyPy's trace-based JIT. Also, LLVM's garbage collection support is still somewhat primitive, and it lacks PyPy's unique ability to automatically generate a JIT.
Incidentally two Java implementations are built on LLVM—J3/VMKit and Shark.
You might consider watching the PyPy talk from Stanford last week; it provides a pretty decent overview of how PyPy works. Carl Friedrich Bolz's presentation also provides a good overview of the state of VM implementation.
主要原因是什么？因为虚拟机设计不是一项固定的技术，并且拥有具有不同目的和目的的各种虚拟机允许并行尝试多种机制，而不是必须串联尝试所有机制。
JVM、CLR、PyPy、Parrot、LLVM 等都以不同的方式针对不同类型的问题。这类似于 Chrome、Firefox、Safari 和 IE 都使用自己的 Javascript 引擎的原因。
Unladen Swallow 尝试将 LLVM 应用到 CPython，并且花在解决 LLVM 问题上的时间比做任何 Python 特定的事情还要多。
Python-on-Parrot 受到 Perl 6 和 Python 之间语义差异的影响，导致前端编译过程出现问题，因此该领域的未来工作可能会使用 PyPy 前端来针对 Parrot VM。
不同的虚拟机开发人员当然会关注其他人在做什么，但即使他们提出了好的想法，他们也会在合并之前加入自己的想法。
The main reason? Because VM design is not a settled technology, and having a variety of VMs with different goals and objectives allows a variety of mechnisms to be tried in parallel rather than all having to be tried in series.
The JVM, CLR, PyPy, Parrot, LLVM and the rest all target different kinds of problems in different ways. It's similar to the reasons why Chrome, Firefox, Safari and IE all use their own Javascript engines.
Unladen Swallow attempted to apply LLVM to CPython, and spent more of their time fixing issues in LLVM than they did in doing anything Python specific.
Python-on-Parrot suffered from semantic differences between Perl 6 and Python causing problems with the front-end compilation process, so future efforts in this area are likely to use the PyPy front-end to target the Parrot VM.
Different VM developers certainly keep an eye on what the others are doing, but even when they lift good ideas they will put their own spin on them before incorporating them.