4 ms·

I found something similar with Java's JIT. I had a very hot loop (runtime of 15 minutes) that I wanted to speed up. I profiled it over and over again in Intell

I found something similar with Java's JIT. I had a very hot loop (runtime of 15 minutes) that I wanted to speed up. I profiled it over and over again in IntelliJ, identifying every possible allocation I could eliminate. When I was done there were zero allocations in the hot loop and the thing ran something like 4x faster than it had previously. At that point, looking at the code, I realized that what I had written was very similar to how I'd have implemented it in Rust—I allocated a bunch of structs upfront and then "borrowed" them into the various parts of the algorithm. Since it was so close in style to Rust anyway, I decided to port it over and see if I could get any more performance out of it by being closer to the metal. It turned out that the difference in performance between the Rust version and the Java version was statistically insignificant. I tried a few different optimization settings but didn't manage to get Rust to be any faster than Java's JIT. This was eye opening to me. Now that most runtimes have JIT compilers, I suspect that far more important than choosing the right language is deeply understanding how the language you're working with works under the hood so you can eliminate hot spots and unnecessary allocations.

nirvdrum 3y ago
When you say Java's JIT, I presume you mean C2? I'd be curious to hear how it performs with Graal. If what you ran into was truly side effect free, either the OpenJDK or GraalVM teams would be interested in seeing your use case for further optimization. You're right, this isn't something an application developer should have to think about with a good JIT compiler in place, but JITs are complicated and having real world code samples that aren't performing well are incredibly useful to the compiler devs.
pjmlp 3y ago
Note that there are plenty of Java JIT's to chose from, depending on the JVM implementation. To pick on your example, back when Android used Dalvik as a plain interpreter, followed by a basic JIT method tracing, they implemented floating point math on native code. Nowadays the JIT takes care of it, https://developer.android.com/reference/android/util/FloatMath https://developer.android.com/reference/android/util/FloatMa... Unfortunely it has taken us several decades to catch up to Lisp and BASIC (the original Dartmouth BASIC), were already offering in the 1970's.

nirvdrum 3y ago

When you say Java's JIT, I presume you mean C2? I'd be curious to hear how it performs with Graal. If what you ran into was truly side effect free, either the OpenJDK or GraalVM teams would be interested in seeing your use case for further optimization. You're right, this isn't something an application developer should have to think about with a good JIT compiler in place, but JITs are complicated and having real world code samples that aren't performing well are incredibly useful to the compiler devs.

pjmlp 3y ago

Note that there are plenty of Java JIT's to chose from, depending on the JVM implementation. To pick on your example, back when Android used Dalvik as a plain interpreter, followed by a basic JIT method tracing, they implemented floating point math on native code. Nowadays the JIT takes care of it, https://developer.android.com/reference/android/util/FloatMath https://developer.android.com/reference/android/util/FloatMa... Unfortunely it has taken us several decades to catch up to Lisp and BASIC (the original Dartmouth BASIC), were already offering in the 1970's.