.net - IronScheme 是解释还是编译？它是否受益于 .NET Framework 优化？

Question

在“IronPython in Action”一书中，作者指出 IronPython 与 CPython 不同，它受益于某些优化，包括 JIT 和框架本身，而 CPython 无法利用这些优化。因此，IronPython 可能比 CPython 更快，尤其是对于多线程场景。

是否IronScheme从这样的优化中受益？它是解释器(不是编译器)，还是解释器，因为这是 Lisp 的本质，必须解释它才能提供类似 Lisp 的灵活性？如果是解释器，它还能从抖动中的优化中受益吗？

Answer 1

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

此外，IronScheme 中没有解释部分(除非您调用运行时符号查找)，因为我几乎从 DLR 的“分支”中删除了所有这些部分，因为没有被使用并减少了代码占用空间(我估计我只使用了大约 25% 的 DLR，其余部分则以 Python 为中心)。

要查看生成的 IL，您可以查看 ironscheme.boot.dll Reflector .NET 中的程序集(最好使用 IL 模式，因为 C# 往往会被奇怪地重组，并且在少数情况下完全错误)。整个程序集由 IronScheme 编译。查看运行时生成的代码要复杂得多。

如前所述，这确实具有 JIT 的所有优点，而且我在 DLR 上进行的优化更加以 Scheme 为中心，当我上次测试它时，它的执行速度通常比 IronPython 快(至少在 18 个月前，我意识到从那时起 IronPython 有了很多改进，但 IronScheme 的速度快了几个因素，即使使用 Scheme 甚至“感觉”更像 Python，甚至是球赛)。

此外，我尝试尽可能多地利用 .NET 框架作为 IronScheme 的基础，并使互操作性更容易。诸如 vectors 之类的东西, byte-vectors , binary-ports和 hash-tables基于我们都知道和使用的普通 .NET 类； object[] , byte[] , Stream和 Hashtable分别，仅举几例。