代码之家 › 专栏 › 技术社区 › Robert Harvey

IronScheme是解释的还是编译的?它是否受益于.NET框架优化?

ironscheme scheme compiler-construction optimization .net

5

Robert Harvey · 技术社区 · 15 年前

在书里 “IronPython正在运行,” 作者指出,与CPython不同,IronPython在JIT和框架本身中都受益于某些优化,而CPython无法利用这些优化。因此,IronPython可能比CPython更快,特别是对于多线程场景。

做 IronScheme 从这些优化中获益?它是一个解释器(不是编译器),它是一个解释器,因为它是LISP的本质,它必须被解释为提供Lisp样的灵活性吗?如果它是一个解释器,它还能从抖动优化中获益吗?

1 回复 | 直到 15 年前

1

3

Robert Harvey 15 年前

像IronPython(我基于IronScheme的DLR的初始版本)一样,IronScheme一直被编译到IL级别。

此外,IronScheme中没有解释部分(除非您调用runtime symbol lookup that),因为我几乎已经从DLR的“分支”中删除了所有这些部分,因为没有使用它们,并且减少了代码占用(我估计我只使用了大约25%的DLR,其余部分都是以Python为中心的)。

要查看生成的IL,可以查看 ironscheme.boot.dll 在Reflector.NET中的程序集(最好使用IL模式,因为C#在某些情况下可能会被奇怪地重新构造,而且完全是错误的)。整个程序集由IronScheme编译。查看运行时生成的代码要复杂得多。

如前所述,这确实有JIT的所有好处,而且随着我对DLR进行的以方案为中心的优化,它通常比我上次测试时的IronPython执行得更快(至少在18个月前,我意识到IronPython从那时起已经有了相当多的改进,但是ironpatche是一些更快的因素,甚至在球赛中使用更像Python的Scheme)。

此外,我尝试尽可能多地使用.NETFramework作为IrOnStand的基础,并使互操作变得更容易。像这样的事情 vectors , byte-vectors , binary-ports 和 hash-tables 基于我们都知道和使用的普通.NET类; object[] , byte[] , Stream 和 Hashtable 举几个例子。