Hey. I'M not sure, but if I understood currectly, Graalvm makes

Question

Hey. I'M not sure, but if I understood currectly, Graalvm makes

Java run without the jvm on native machines and it produces assembly like C/C++?
If it does this, does this mean that Java with Graalvm is as fast is C/C++?

0

20.07.2024

2 ответов

10 просмотров

Αλι (EN, EO) Автор вопроса

Dmytro Buryak
> Graalvm makes Java run without the jvm on native...

Thank you for the great explanation 👍.

0

1 месяц назад

Dmytro Buryak · Accepted Answer

> Graalvm makes Java run without the jvm on native machines and it produces assembly like C/C++? Yes, correct. > If it does this, does this mean that Java with Graalvm is as fast is C/C++? There's no answer to this question because there are different aspects in "to be fast". First aspect is app startup time. In classic bytecode-for-JVM style, the app startup takes very substantial time because first before your app code gets executed, the JVM itself needs to start up. This is probably the major advantage of using graalvm - instant startup time. With this regards, graalvm app is as fast as c/cpp one - they both start up practically instantly. Second aspect is the first rounds of your code blocks execution (first ~15 executions if I'm not mistaken). This is the time when JVM does not engage JIT yet. You better google for what JIT is, but in a nutshell, it is an adaptable compiler that lives in VM, tracks code execution metrics and from time to time during code execution tries to recompile code pieces and find the best performing optimization options for that block. So, before JIT kicks in, first executions are very slow compared to c/c++. I.e. java app as bytecode-for-JVM is significantly slower than c/cpp one during first 15 executions. Graalvm and c/cpp both do not have JIT, all compiler optimizations are specified during build time. Hence: jvm << graalvm < c/cpp jvm will be significantly slower. And c/cpp code most likely will be slightly faster than graalvm in real world apps. And "slightly" here is "slightly faster compared to how significantly faster graalvm is than jvm during first executions". I.e. this "slightly" may be like 2-4 times faster. But it may be 20-40 times faster than first jvm executions. For "one off" applications, that's it. But for server apps, or UI apps that users use for a prolonged time, the same code paths may be executed many times repeatedly. That's where JIT comes in. So now we're talking about the third aspect - running for a long time when same code is executed again and again. This state is usually called "hot jvm" or "pre-heated jvm" in java world. So in this case the full power of JIT is unleashed, as compared to classic compiler (graalvm or c/cpp), jit takes into account how code is executed in reality, in runtime, and jit can make experiments or assumptions. All this allows better optimizations than the classic compiler can do. So in this phase, in "hot jvm" state, bytecode-for-jvm might perform better than graalvm. It's very unlikely that hot-jvm will peform better than c/cpp, especially in real-world apps. Yeah, you can find some example, but in average c/cpp is faster than hot-jvm. The bottom line. Graalvm is not that about speed, but rather about - faster startup time than jvm - self-contained execution binary (you don't need jre or anything to run it) - much smaller memory requirements All that is important for microservices. That's where graalvm shines. But overall, question like "jvm is faster than graalvm or than c/cpp" is practically useless. Areas where they are both applicable and you decide which one to use, those areas in 99% cases are not dependent on performance differences in question. These techs are from different worlds with very small intersection.

Похожие чаты

Hey. I'M not sure, but if I understood currectly, Graalvm makes

2 ответов

Похожие вопросы