language-features - 语言和 VM : Features that are hard to optimize and why

Question

我正在做一项功能调查，为一个研究项目做准备。

说出难以优化的主流语言或语言功能，以及为什么该功能值得或不值得付出代价，或者只是用轶事证据驳斥我下面的理论。在有人将其标记为主观之前，我要求提供语言或功能的具体示例，以及优化这些功能的想法，或者我没有考虑过的重要功能。此外，任何对证明我的理论正确或错误的实现的引用。

在我难以优化的功能和我的理论列表中名列前茅(我的一些理论未经测试并且基于思想实验):

1) 运行时方法重载 (又名多方法调度或基于签名的调度)。当与允许运行时重新编译或方法添加的功能结合时，是否很难优化。还是只是很难？调用站点缓存是许多运行时系统的常见优化，但多方法增加了额外的复杂性，并且使得内联方法不太实用。

2) 类型变形/变体 (又名基于值的类型而不是基于变量的类型)
当您不知道 someting 的类型是否可以在基本块中更改时，传统的优化根本无法应用。结合多种方法，内联必须小心谨慎，而且可能只针对给定的被调用者大小阈值。 IE。考虑内联简单的属性获取(getter/setter)很容易，但内联复杂的方法可能会导致代码膨胀。另一个问题是我不能只是将一个变体分配给一个寄存器并将其 JIT 到 native 指令，因为我必须携带类型信息，或者每个变量都需要 2 个寄存器而不是 1 个。在 IA-32 上这很不方便，即使使用 x64 的额外寄存器进行了改进。这可能是我最喜欢的动态语言特性，因为它从程序员的角度简化了很多事情。

3) 头等舱续集 - 有多种方法可以实现它们，我在两种最常见的方法中都这样做了，一种是堆栈复制，另一种是实现运行时以使用连续传递样式、仙人掌堆栈、写时复制堆栈帧，和垃圾收集。一流的延续存在资源管理问题，即。我们必须保存一切，以防继续延续，而且我不知道是否有任何语言支持留下带有“意图”的延续(即“我不会回到这里，所以你可以丢弃这个世界的副本” )。在线程模型和延续模型中编程后，我知道两者都可以完成同样的事情，但是延续的优雅给运行时带来了相当大的复杂性，并且还可能影响缓存效率(堆栈的局部性随着使用延续和协同例程而发生更多变化) )。另一个问题是它们只是不映射到硬件。优化延续就是针对不太常见的情况进行优化，正如我们所知，常见情况应该很快，而不太常见的情况应该是正确的。

4) 指针算术和屏蔽指针的能力 (以整数形式存储等)不得不把它扔进去，但实际上我可以很容易地不用它。

我的感觉是，许多高级功能，尤其是动态语言中的功能，并没有映射到硬件上。微处理器实现在芯片优化背后进行了数十亿美元的研究，但语言功能的选择可能会边缘化许多这些功能(如缓存、堆栈顶部到寄存器的别名、指令并行性、返回地址缓冲区、循环缓冲区和分支预测)。微功能的宏应用不一定像某些开发人员想的那样成功，在 VM 中实现多种语言最终会将 native 操作映射到函数调用中(即，语言越动态，我们就越需要查找/在运行时缓存，什么都不能假设，所以我们的指令混合由比传统的静态编译代码更高百分比的非本地分支组成)并且我们唯一能真正 JIT 的是非动态类型的表达式评估和对常量或立即数类型的操作。我的直觉是，字节码虚拟机和 JIT 内核可能因此不适用于某些语言。

我欢迎你的回答。

Answer 1

几点意见:

所有具有动态调度的语言，甚至基于单个对象，似乎都很难有效地实现。看看在 Self(或者最近使用 SpiderMonkey 的 JavaScript)的运行时优化方面所做的所有努力。

不要小看分隔继续 .陪审团仍然存在，但它们比经典的无定界延续更容易优化。阅读 Gasbichler 和 Sperber 的论文。