代码之家 › 专栏 › 技术社区 › Roman A. Taycher

关于可能的java(或其他内存管理语言)优化的问题

aot jit compilation

2

Roman A. Taycher · 技术社区 · 15 年前

此外,许多人似乎不喜欢Java(和许多其他高级内存管理语言)的本机代码生成(有时称为提前编译),原因有很多,例如可移植性的丧失(等等),但也有一部分原因是(至少对于那些有即时编译器的语言来说)这种思想认为,提前编译机器代码会错过jit编译器可能完成的优化,因此从长远来看可能会比较慢。

http://en.wikipedia.org/wiki/Profile-guided_optimization (编译成一个二进制+一些额外的程序,然后运行程序并分析测试运行的运行时信息,以生成一个更优化的二进制,以供实际使用)对于java/(其他内存管理语言),这与jit代码相比会如何?有人有线索吗?

3 回复 | 直到 15 年前

1

2

Sandor Murakozi 15 年前

Profile-guided优化有一些注意事项,其中之一甚至在您链接的Wiki文章中提到过。它的结果是有效的

对于给定的示例,表示用户或其他代码实际使用代码的方式。
对于给定的平台(CPU、内存+其他硬件、操作系统等等)。
从性能的角度来看,即使是在通常被认为(或多或少)相同的平台之间,也有相当大的差异(例如,比较一个单核、512M的旧Athlon和一个在Linux上运行的6核、8G的Intel,但是内核版本非常不同)。
对于给定的JVM及其配置。

如果其中任何一个发生了变化,那么您的分析结果(以及基于它们的优化)就不再需要有效了。最有可能的是,有些优化仍然会产生有益的效果,但有些优化结果可能不太理想(甚至会降低性能)。

处理真实数据(使用统计+平台+配置)可以避免前面提到的警告。

我猜概要文件引导的优化器仍然可以与之竞争(甚至击败它),但只有在某些特殊情况下,如果您可以避免以下警告:

您很确定您的示例很好地代表了实际场景,并且在执行过程中不会有太多变化。
当然,您知道/控制JVM及其配置。

这种情况很少发生,我猜一般来说JIT会给你更好的结果,但我没有证据。

如果你的目标是一个不能进行JIT优化的JVM(我认为大多数小型设备都有这样一个JVM),那么从profile-guided优化中获得价值的另一种可能性就是。

顺便说一句,在其他答案中提到的一个缺点是很容易避免的:如果静态/概要文件引导的优化速度很慢(可能是这样),那么只在发布时(或者RCs去测试人员)或者在夜间构建时(时间不那么重要)才这样做。

2

4

benjismith 15 年前

我个人认为最大的区别不是JIT编译和AOT编译,而是类编译和整个程序优化。

当您运行javac时,它只查看单个.java文件,并将其编译成单个.class文件。所有的接口实现、虚拟方法和重写都会被检查有效性,但没有得到解决(因为不分析整个程序就不可能知道真正的方法调用目标)。

JVM使用“运行时加载和链接”将所有类组装成一个连贯的程序(程序中的任何类都可以调用专门的行为来更改默认的加载/链接行为)。

长话短说,如果不分析整个程序,有很多优化是不可能的,而进行整个程序分析的最佳时间是在运行时。

3

1

Gian 15 年前

在编译时执行更多的静态分析或优化过程的代价本质上是您从这个额外的工作中获得的(不断减少的)回报与编译器运行所需的时间相比。像MLton(对于标准ML)这样的编译器是一个具有大量静态检查的全程序优化编译器。它产生了非常好的代码,但在中大型程序上,甚至在快速系统上,速度变得非常非常慢。