

So why is it that not even hardware acceleration can make Java run as fast
as native code? Some reasons are listed on this slide.
First we have things like array bounds checking, dynamic type checking,
garbage collection. These are built-in features of Java that you can't avoid
Then we have expensive native calls. I should mention that you can't even
have native code in your own app, but the built-in libraries often need to call
native functions.
One important thing is that you get no access to SIMD instructions and other
special CPU features. When you're woring in native code, you can get a big
performance boost by writing some of your critical routines in assembly and
using the ARM equivalents of Intel's MMX and SSE
Then finally, there's the poblem Java bytecode has a stack-based execution
model, whereas all CPUs are using registers. It's hard for the VM to compile
stack-based code into fast register-based code, and that's probably one of
the reasons why the HotSpot VM performs so badly. But there are other
reasons, too.
So the bottom line is that Java will remain slower than native code, and we
just have to live with that fact. The performance gap will become smaller, but
it will not go away.

本文探讨了即使采用硬件加速,Java仍无法媲美原生代码运行速度的原因。列举了数组边界检查、动态类型检查等特性,以及昂贵的原生调用、缺乏SIMD指令支持等问题,并分析了Java字节码的栈式执行模型导致的性能挑战。
1971

被折叠的 条评论
为什么被折叠?



