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

Question

是中间表示 --IR -如Java 字节码或.net CIL,仍然是一个优势？我们不能只在源代码中部署软件组件吗？

支持IR的一个论点是软件组件的可移植性,这避免了为每个目标体系结构编译源代码的需要(关于该体系结构的虚拟机的存在).IR提供了对每个体系结构特性的抽象.以同样的方式并与元数据一起,它在实现安全保障方面带来了其他优势; 检查安全通道; 等等

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

那么,在源代码中的组件中部署IR中的软件组件是否有任何优势？

Answer 1

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

• IR字节码的一个优点是混淆了您创建的逻辑.然而,缩小的javascript也是如此,在某些情况下也是如此.

• 另一个优点是缩小了尺寸,但缩小的javascript也很小,也许同样如此.

• 第三个优点是更快的JIT编译,因为字节码更接近源代码的实际机器指令.虽然您可以使用源代码执行JIT,但执行此操作需要更多指令和/或内存.所以其他条件相同,你应该通过字节码部署获得更好的性能.应该注意的是,其他情况很少相同,因此您可能并不总是观察到这种性能优势,或者根据您的性能需求可能会相对较小.

• 第四个优点是,您可以更容易地让其他语言针对字节码IR而不是目标语言.虽然可以创建一个编译为javascript的语言,但通常可以更容易地编译为字节码,并且您可以更好地控制结果的性能和正确性,因为您正在编译成更靠近机器代码的东西. .

• 最后,有可能,甚至在某些情况下,通过这个网站,例如,手动调整字节码的性能,就像人们有时使用汇编程序一样.

现在,区别可能变得模糊.人们可以想象一个相当重量级的字节码格式,可能是由于需要支持大量硬件,或者可能是由于设计不佳,这可能比机器代码更远,而不是解释ANSI C.但是,如果我们假设字节码是接近机器指令的合理尝试,并假设"源代码"表示高于C或更高级别的东西,那么上述优点应该成立.