跟踪树的Javascript性能改进是否会找到其他解释型语言的方式？

问题描述

这听起来像Mozilla运气好，改善了JavaScript性能与。另请参阅Andreas Gal的。

这些改进是否可用于其他解释器/编译器，如果是，这是否意味着我们将看到其他解释型语言的级联改进？

解决方案

Andreas Gal有一个研究JVM调用，并且他的团队中的一些人目前正在将基于嵌套跟踪树的JITting添加到（Sun的新研究JVM用Java编写）和HotSpot。因此，至少它也出现在其他语言的其他虚拟机中。

此外，新的 JIT编译器（目前在Prolog中原型化）使用某种跟踪技术，尽管我不知道Gal / Franz风格的嵌套跟踪树有多么接近。 p>

的用户都清楚这项工作，非常开放实验。

BTW：有一个用JavaScript编写的Ruby虚拟机，叫做。如果你在TraceMonkey上运行，你可以免费获得基于跟踪树的Ruby： - ）

It sounds like Mozilla is having good luck improving JavaScript performance with TraceMonkey. See also Andreas Gal's paper on Trace Trees.

Are these improvements available to other interpreters/compilers and if so, does this mean we'll see a cascade of improvements in other interpreted languages?

解决方案

There's a research JVM by Andreas Gal called HotPath, and some people from his team are currently working on adding nested trace tree based JITting to Maxine (Sun's new research JVM written in Java) and HotSpot. So, at least it is showing up in other VMs for other languages as well.

Also, the new PyPy JIT compiler (currently being prototyped in Prolog) uses some kind of tracing technique, although I don't know how closely related that is to Gal/Franz style nested trace trees.

The Rubinius guys are definitely aware of this work, and very open to experimentation. I wouldn't be surprised, if some advanced compilation techniques start showing up there, soon.

BTW: there is a Ruby VM written in JavaScript, called HotRuby. If you run that on TraceMonkey, you get trace tree based Ruby for free :-)

这篇关于跟踪树的Javascript性能改进是否会找到其他解释型语言的方式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！