3 ms·

>A lot of software these days is run by JIT compiling VMs, anything Java, anything JavaScript, and that trend is likely to accelerate in future with new tech li

by adev_ 6y ago

>A lot of software these days is run by JIT compiling VMs, anything Java, anything JavaScript, and that trend is likely to accelerate in future with new tech like Graal that can JITC even stuff like LLVM bitcode or Python. That's theory. Practice is that JIT-compiled language generally performs even worst than compiled language with an outdated instructions set. And there is reasons to that, compiler passes are expensive, including vectorization, and you specially do not want anything expensive running in your critical JIT passes. Some language like Julia still do it but to the price of a very long compiling and starting time. Something that has never been acceptable over JVM or in Nodejs.

thu2111 6y ago
Comparing language performance isn't the same thing as comparing JIT vs AOT performance. Generally JIT outperforms AOT for a language like Java by about 20%. For Scala, it's even more. For a more dynamic language like JavaScript or Ruby you don't even try to AOT it at all the difference is so huge. Even in languages that are normally AOT compiled, profile guided optimisations make a big difference. For C++ I've seen figures in the 15%+ range. That's a lot! Most projects don't use PGO though because it's a pain to deploy. C2 does auto-vectorisation and it's not a slow compiler. It runs in parallel with the app, it's not a problem. The difficulty with auto-vectorisation isn't how much time you have to compile it, it's more that matching all the different loop constructs to the instructions is a very complicated problem that ends up needing tons of special cases in the compiler. It's a problem of code complexity rather than runtime performance. And it's opaque to the user: if they change their code structure a bit and it's no longer recognised as a vectorizable template, it'll stop being vectorised and performance drops off a cliff. You can't really see that though as a developer ahead of time because it's all just "best effort" optimisation. Game devs in particular hate that and would rather have a compiler error than silently bailed out optimisation passes. That's why Java is switching to explicit vectorisation. It's not about JITs not having enough CPU time, it's about giving the developer reliable and predictable performance even in the face of arbitrary refactorings.

by adev_ 6y ago

thu2111 6y ago

Comparing language performance isn't the same thing as comparing JIT vs AOT performance. Generally JIT outperforms AOT for a language like Java by about 20%. For Scala, it's even more. For a more dynamic language like JavaScript or Ruby you don't even try to AOT it at all the difference is so huge. Even in languages that are normally AOT compiled, profile guided optimisations make a big difference. For C++ I've seen figures in the 15%+ range. That's a lot! Most projects don't use PGO though because it's a pain to deploy. C2 does auto-vectorisation and it's not a slow compiler. It runs in parallel with the app, it's not a problem. The difficulty with auto-vectorisation isn't how much time you have to compile it, it's more that matching all the different loop constructs to the instructions is a very complicated problem that ends up needing tons of special cases in the compiler. It's a problem of code complexity rather than runtime performance. And it's opaque to the user: if they change their code structure a bit and it's no longer recognised as a vectorizable template, it'll stop being vectorised and performance drops off a cliff. You can't really see that though as a developer ahead of time because it's all just "best effort" optimisation. Game devs in particular hate that and would rather have a compiler error than silently bailed out optimisation passes. That's why Java is switching to explicit vectorisation. It's not about JITs not having enough CPU time, it's about giving the developer reliable and predictable performance even in the face of arbitrary refactorings.