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

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.

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