virtual-machine - 中间表示(例如字节码或.net IL)仍然是一个优势吗？

Question

是中间表示--IR--比如Java bytecodes或.net CIL ，还有优势吗？我们不能只在源代码中部署软件组件吗？

支持 IR 的一个论据是软件组件的可移植性，它避免了为每个目标架构编译源代码的需要(关于该架构的虚拟机的存在)。 IR 提供了对每个架构特性的抽象。以同样的方式并与元数据一起，它在启用安全保证方面带来了其他优势；检查安全 channel ；等等

今天，一些技术，如 Node.js(带有 V8 引擎)引入了源代码中可部署组件的想法，在 Node.js 中称为包(我不确定这是否是 Node.js 中的一个开创性想法)。源代码包含 IR + 元数据的相同信息。此外，在源代码中使用组件并不会阻止运行时引擎使用与现代虚拟机相同的原理，例如即时编译和后期绑定(bind)数据类型，这允许自适应优化，因此理论上可以更快地产生执行。

那么，在 IR 中部署软件组件比在源代码中部署组件有什么优势吗？

Answer 1

在某些情况下，区别开始模糊，我将在下面说明。但总的来说:

IR 字节码的一个优点是混淆了您创建的逻辑。但是，缩小的 javascript 也是如此，并且在某些情况下达到类似的程度。

另一个优点是减小了大小，但缩小的 javascript 也很小，也许同样如此。

第三个优势是更快的 JIT 编译，因为字节码更接近源代码的实际机器指令。虽然您可以使用源代码执行 JIT，但它需要更多的指令和/或内存来完成。因此，在其他条件相同的情况下，您应该通过字节码部署获得更好的性能。应该注意的是，其他情况很少是相同的，因此您可能并不总是观察到这种性能优势，或者它可能相对较小，具体取决于您的性能需求。

第四个优点是您可以更轻松地让其他语言以字节码 IR 为目标，而不是以一种语言为目标。虽然可以创建一种编译为 javascript 的语言，但通常更容易编译为字节码，并且您将对结果的性能和正确性有更多的控制，因为您正在编译为更接近机器代码的内容.

最后，有可能，甚至在某些情况下，通过这个网站，手动调整你的字节码以提高性能，就像人们有时使用汇编程序所做的那样。

现在区别可能会变得模糊。可以想象一种相当重量级的字节码格式，可能是由于需要支持广泛的硬件，或者可能是由于设计不佳，这可能比解释的 ANSI C 更远离机器代码。但是，如果我们假设字节码是一种近似机器指令的合理尝试，并假设“源代码”代表 C 或更高级别的东西，那么上述优势应该成立。