`
RednaxelaFX
  • 浏览: 3039646 次
  • 性别: Icon_minigender_1
  • 来自: 海外
社区版块
存档分类
最新评论

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

    博客分类:
  • DLR
阅读更多
John LamMIX 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
分享到:
评论

相关推荐

    IronPython 2.6源代码

    IronPython 2.6 是一个开源的Python解释器,它完全用C#语言编写,并且与.NET Framework紧密集成。这个项目是由微软的前员工、现为Google员工的Michael Foord领导的,旨在提供一个高性能、可扩展且能够无缝运行在.NET...

    Professional IronPython.pdf

    ### 《Professional IronPython》知识点概述 #### 一、书籍简介 本书名为《Professional IronPython》,作者为John Paul Mueller,由Wiley Publishing出版。本书详细介绍了IronPython的基础知识及其高级应用,适合...

    IronPython-1.1.1

    IronPython-1.1.1 是一个特定版本的IronPython实现,它是一个高效且功能强大的Python解释器,专为.NET Framework和Mono平台设计。由Jim Hugunin在微软的引领下开发,IronPython的独特之处在于它能够无缝地融入.NET...

    IronPython各个支持平台对应的DLL资源

    - **DLL**:IronPython运行时环境通常依赖于一系列的DLL文件,这些文件包含了Python解释器和相关功能的实现。 - **DLR**:动态语言运行时(Dynamic Language Runtime,DLR)是.NET Framework的一部分,它为动态语言...

    IronPython In Action

    通过以上内容可以看出,《IronPython In Action》一书不仅深入讲解了IronPython的基础知识和高级特性,还重点探讨了IronPython作为.NET平台上脚本引擎的应用场景和技术细节。无论是对于想要学习IronPython的初学者,...

    IronPython(.NET和Python实现平台)v2.7.7官方安装版(附安装方法)

    ironPython是一种在.NET及Mono上的Python实现,由微软的Jim Hugunin所发起,是一个开源的项目,基于微软的DLR引擎,除去.NET,IronPython与Python并没有什么区别。它支持一个可交互的控制台,该控制台支持完全的动态...

    ironpython3:在动态语言运行时之上构建的适用于.NET Framework的Python 3.x的实现

    IronPython 3 要支持Python 3.x,仍有许多工作要做。 我们正在努力,尽管进展缓慢。 我们欢迎所有想提供帮助的人! 当前的目标是与Python 3.4兼容的发行版,尽管可能包括更高版本的功能和行为。IronPython是Python...

    针对Change Set 32648而更新的荒井省三的简单DLR语言例子

    针对IronPython change set 32648中的DLR而对荒井省三所制作的简单语言的例子的更新 博文链接:https://rednaxelafx.iteye.com/blog/192354

    ironpython2:.NET Framework的Python编程语言的实现; 建立在动态语言运行时(DLR)之上

    IronPython 3已发布,现在可以从下载! 铁蟒 IronPython是Python编程语言的开源实现,该语言与.NET Framework紧密集成。 IronPython可以使用.NET Framework和Python库,而其他.NET语言也可以轻松使用Python代码。 ...

    Python库 | downward_dlr-19.6.0.tar.gz

    综上所述,"downward_dlr-19.6.0"作为Python的一个专业库,其背后蕴含了丰富的编程理论和技术细节,值得我们深入研究和探索。无论是对Python的底层机制有更深入的理解,还是在实践中提高代码效率,这个库都为我们...

    Pro DLR in .NET 4

    Dynamic Language Runtime (DLR) in .NET is a framework for designing and interacting with dynamic languages such as Python and Ruby. For the first time, the DLR places such languages on an equal ...

    .net4的DLR高级编程 Apress.Pro.DLR.in.NET.4.Nov.2010

    《.NET 4 的 DLR 高级编程》是一本深度探索 .NET 动态语言运行时(Dynamic Language Runtime,简称 DLR)的专著,由 Chaur Wu 撰写,出版于 2010 年 11 月。这本书针对 .NET 4 开发者,特别是那些对在 .NET 平台上...

    dlr-618最新升级固件

    dlr-618最新升级固件

    沉默:由Python和.NET的DLR支持的异步协作开发后代理

    SILENTTRINITY是由Python 3和.NETs DLR支持的现代,异步,多人和多服务器C2 /后期开发框架。 这是使用嵌入式第三方.NET脚本语言动态调用.NET API的大量研究的成果,该技术是作者创造的BYOI(自带翻译)。 该工具和...

Global site tag (gtag.js) - Google Analytics