IronScheme 是解释型还是编译型？它是否受益于 .NET Framework 优化？
在《IronPython in Action》一书中，作者指出，与 CPython 不同，IronPython 从 JIT 和框架本身的某些优化中受益，而 CPython 无法利用这些优化。因此，IronPython 可能比 CPython 更快，尤其是对于多线程场景。
IronScheme 是否能从此类优化中受益？它是一个解释器（而不是编译器）吗？它是一个解释器吗？因为这是 Lisp 的本质，必须对其进行解释才能提供类似 Lisp 的灵活性？如果它是解释器，它仍然可以从抖动优化中受益吗？
In the book "IronPython in Action," the author states that IronPython, unlike CPython, benefits from certain optimizations, both in the JIT and in the framework itself, that CPython cannot take advantage of. Consequently, IronPython is potentially faster than CPython is, especially for multithreading scenarios.
Does IronScheme benefit from such optimizations? Is it an interpreter (not a compiler), and is it an interpreter because that's the nature of Lisp, that it must be interpreted to provide the Lisp-like flexibility? If it is an interpreter, can it still benefit from optimizations in the jitter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
与 IronPython（以及我基于 IronScheme 的 DLR 的第一个 Python）一样，IronScheme 一直编译到 IL 级别。
此外，IronScheme 中没有解释部分（除非您调用运行时符号查找），因为我几乎从 DLR 的“分支”中删除了所有这些部分，因为没有使用并减少了代码占用空间（我据估计，我只使用了大约 25% 的 DLR，其余部分则以 Python 为中心）。
要查看生成的 IL 内容，您可以查看 Reflector .NET 中的
ironscheme.boot.dll程序集（最好使用 IL 模式，因为 C# 往往会进行奇怪的重组，并且在某些情况下完全是错误的）。整个程序集由 IronScheme 编译。查看运行时生成的代码要困难得多。如前所述，这确实具有 JIT 的所有优点，并且随着我对 DLR 进行的优化更加以方案为中心，当我上次测试它时，它通常比 IronPython 执行得更快（至少是 18 个月前，我意识到）从那时起，IronPython 已经有了相当多的改进，但 IronScheme 的速度要快一些，甚至使用“感觉”更像 Python 的 Scheme 来进行球赛）。
此外，我尝试尽可能多地利用 .NET 框架作为 IronScheme 的基础，并使互操作性变得更容易。
向量、字节向量、二进制端口和哈希表等都是基于普通的.NET我们都知道并使用的类；仅举几例，分别是object[]、byte[]、Stream和Hashtable。Like IronPython (well the initial one with the DLR that I based IronScheme on), IronScheme is compiled all the way down to IL level.
Furthermore, there are no interpreted parts in IronScheme (unless you call runtime symbol lookup that), as I have pretty much ripped out all of that from my 'branch' of the DLR, due to not being used and reducing the code footprint (I estimated I only used about 25% of the DLR, where the rest was rather Python-centric).
To see what IL gets generated, you can look at the
ironscheme.boot.dllassembly in Reflector .NET (using IL mode preferably, as C# tends to be restructured weirdly and just plain wrong in a few cases). This entire assembly is compiled by IronScheme. To see runtime generated code is a lot more trickier.As said, this does have all the benefits of JIT, and with the optimizations I made on the DLR to be more Scheme-centric, it generally performed faster than IronPython when I last tested it (a good 18 months back at least, I realize IronPython has had quite a few improvements since then, but IronScheme was a few factors faster, even using Scheme that 'felt' more like Python to even the ball game).
Furthermore, I have attempted to utilize as much of the .NET framework as a foundation for IronScheme, and to make interoperability easier. Things like
vectors,byte-vectors,binary-portsandhash-tablesare based on the normal .NET classes we all know and use;object[],byte[],StreamandHashtablerespectively, to name a few.