MIX09上关于DLR解释器消息的一段听记（3月26更新IronPython 2.6A1消息）

John Lam在MIX 09上做了一个关于动态语言与Silverlight应用的讲演，MIX09-T22F: Using Dynamic Languages to Develop Microsoft Silverlight Applications。从55分左右开始，他提到了近期DLR中的解释器的动向。
下面是关于DLR解释器部分，我刚听记的内容……hmm，有空的话或许会把它翻译出来吧，看情况。刚才还有同学说干脆做成外挂字幕好了，可以考虑下。

John Lam 写道

So the interpreter piece.

About three or four weeks ago, Jim Hugunin went off and did some hacking, and he built an improved DLR interpreter. The reason why we need an interpreter -- DLR was always built from the ground up as a compiler. And in certain scenarios, and especially in the scenarios where you're running unit testing code, which is essentially a lot of straight line execution, right? You're gonna compile a whole bunch of code to run it exactly once. The overhead in actually going off and compiling all that code swamps any possible performance gains that you're gonna get from compiling that stuff. So we've been doing very poorly on our unit tests.
But certainly now that we've got this new interpreter, which interprets DLR trees. It's a fairly sophisticated interpreter in some ways, and not so sophisticated in other ways. It's a stackless, it's a very Forth-like interpreter that was checked in. But what's interesting is that it's still walking our trees. So we still have our trees, we're walking our trees.
And that interpreter will run the PyStone benchmark at half the speed of the CPython interpreter, which is pretty damn good, for a tree-walking interpreter. We can make that thing go faster, but we've kind of gotten fast enough to where we want right now. But that's something to take a look at.
Now that we've got this interpreter in there, that means all of the languages are gonna be able to come online with, and use the DLR interpreter. We're probably, I would say...I don't think the check-in has gone in yet, but we're probably about a week away from getting Ruby to use the new DLR interpreter fully. So when that happens we're also gonna be able to publish some new numbers about how well we'll run unit tests. Because that's really one place where we really fall over, and perform very poorly. This is also gonna have the nice benefit for Siliverlight applications as well. We also have an adaptive compilation algorithm, it's a very stupid algorithm in there today. All it does is it counts to three. So the third time it's gonna go off and actually trigger the full compilation pass against the thing that you're trying to invoke. But we'll see how that works, and we'll tune that as required down the road. There's certainly a lot of things we can do with adaptive compilation later.
So, you should get the nice benefit of very nice startup time. And I think that certainly Web-based applications, you're gonna care a heck a lot more baout how fast the app starts up, as opposed to what the ultimate throughput is, even if there's a delay before it kicks into high speed.

下面是我的简单注解：
重点就是，3、4个星期之前Jim Hugunin写了一个新的DLR解释器，比以前的要先进许多。它是一个无栈（stackless）的解释器。“无栈”指的是不使用标准调用栈，而是用别的方式来记录函数调用的活动记录；这主要是为了绕开标准调用栈的一些限制，也就是一个函数调用结束后不能直接前往下一个函数，而必须返回到原本调用的一侧，而这样就无法实现类似Forth的那种高效的threaded-code解释器了。目前，使用这个新解释器运行PyStone的速度大概是CPython的一半，而DLR小组认为就当前而言这个速度已经够用了。
IronRuby大概一周左右之后也会开始全面使用这个新的解释器。其它基于DLR的动态语言实现也都能够直接使用这个解释器来提高启动性能。这对诸如运行单元测试之类的应用场景非常有利，因为这些场景中多数代码只运行一次，编译带来的额外开销比好处要大，不合算。
除了纯解释之外，DLR里也有了比较原始的自适应编译。目前的算法是数三下——当调用某一块“东西”到三次的时候，DLR就能够从解释模式转向编译模式，将DLR tree（也就是新的Expression tree）编译为MSIL然后再执行。DLR在自适应编译方面还有很大的改善余地，以后会有更先进的算法来决定是否编译、何时编译。

之前yawl老大在这里提到过认为IronRuby不会使用混合模式，well，现在事实是已经在用了。

在同一个讲演里，John Lam还提到DLR上初代的4种语言——IronPython、IronRuby、Managed JScript和VBx之中，只有前两者还在持续开发，后两者已经终止开发了。其中Managed JScript是由于开发过程不顺利，而原本的开发人员被转派到别的项目上因而项目终止；后者John Lam没提终止原因，不过或许是Visual Basic 10本身就会与DLR整合，所以没必要把VBx单独发布出来吧？

我有几个星期没跟踪DLR最新的代码了，看来下个星期得再拿出来看看。暂时就这么多，以上。

3月26日补充：
今天IronPython 2.6 Alpha 1发布了，里面就包含了DLR的解释器以及自适应编译。下面引用IronPython 2.6 Alpha 1的release notes：

引用

We’re pleased to announce the release of IronPython 2.6 Alpha 1. As you might imagine, this release is all about supporting new CPython 2.6 features such as the ‘bytes’ and ‘bytearray’ types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101), etc. The minimum .NET version required for this release is the same as IronPython 2.0; namely .NET 2.0 Service Pack 1. Unlike the 2.0 series of IronPython, we plan to release only a couple Alphas and Betas of IronPython 2.6. As such, it’s key that we get your feedback on the release(s) quickly to incorporate requested changes.

Besides CPython 2.6 features, another significant change in this release is that ipy.exe now uses “adaptive compilation” by default. Adaptive compilation is a technique in which IronPython:

• Interprets and executes Python method calls up to N times for a given method. If you’re only going to execute a method a few times, it’s typically faster to interpret the method instead of compiling and executing it
• Compiles and executes the Python method call on the N+1 invocation of the method. Compilation of a Python method is a heavyweight operation, but we can reuse the result for subsequent invocations
• Reuses the previously compiled method for new calls to the Python method. This operation is much faster than interpreting the method call as the method was already compiled in the previous step

The reason for this change is that it provides a nice performance gain for Python code containing lots of functions/methods that only get called a few times. All this said, this feature is still undergoing active development and as a consequence some Python scripts may actually run slower with it turned on. For this reason, our old default mode of running Python scripts is still available by passing the –O or -D flags to ipy.exe. Any feedback on how this new feature affects your IronPython applications performance-wise would be greatly appreciated.

There’s also a few minor changes since IronPython 2.0.1 that are worth calling out here:

IronPython.msi now installs NGEN’ed binaries by default
IronPython.msi now offers a little more selection with respect to what you’d like to install. For example, Silverlight templates are optional
The default installation location of IronPython.msi no longer indicates whether the 2.6 release is an Alpha, Beta, or a patched release. Future IronPython 2.6 installations will replace previous 2.6 releases which will be uninstalled automatically
The -X:PreferComInteropAssembly flag has been removed. All COM interop is now done through normal COM dispatch