13 ms·

Build OpenJDK for a Nice Speedup

127 points by mring33621 7y ago

pron 7y ago
Precisely what compilers do for a given flag varies by compiler and by version. There could potentially be issues with certain optimizations (unfortunately, the OpenJDK VM does have undefined behavior, although we're attempting to gradually reduce it; the chance of a real problem due to undefined behavior certainly increases with the optimization level, as does the probability of a compiler bug), and there have been such issues in the past. So while building OpenJDK with particular optimizations for your particular hardware might be worthwhile in some cases, it's not for the faint of heart, and it should be done with care and extensive testing. If you intend to deploy such a custom-built OpenJDK in production, you should strongly consider getting the JCK [1] (the Java TCK) and testing your build for conformance (for all the VM configurations you'll use: GC choice, compiler choice etc.). A safer and easier way to get "free" performance speedups is to use the most recent JDK (currently 13). [1]: http://openjdk.java.net/groups/conformance/JckAccess/ http://openjdk.java.net/groups/conformance/JckAccess/
- danwills 7y ago
  I wonder whether Gentoo might have an edge here (even in general beyond just jdk) since nearly everything on the system is built with the local CPU as the optimisation target? It certainly reduces the need to not be 'feint of heart' to build things too as it's part of business-as-usual. Whether Gentoo itself requires one to not be feint of heart, is definitely an open question!
- saagarjha 7y ago
  > unfortunately, the OpenJDK VM does have undefined behavior, although we're attempting to gradually reduce it Is it a goal to remove undefined behavior completely? Because I seem to recall certain architectural decisions being completely reliant on undefined behavior, such as signal handlers as implicit null checks…
  - chrisseaton 7y ago
    You can write these little architectural parts in assembly rather than C, to avoid having to write undefined behaviour.
    - saagarjha 7y ago
      Does the JVM use assembly for this? I’d expect writing all of the VM code that handles Java objects in assembly for each platform would be a bit difficult, and I’m not sure I saw enough assembly files in the project for this…
      - chrisseaton 7y ago
        No I mean it is an option available to avoid undefined behaviour, not that this is what the JVM does. But moving more of the implementation of the JVM (or all of it!) to Java is the real solution to all this in my opinion.
        saagarjha 7y ago
        > No I mean it is an option available to avoid undefined behaviour, not that this is what the JVM does. Ah. > But moving more of the implementation of the JVM (or all of it!) to Java is the real solution to all this in my opinion. And what, ship a Graal binary to cut the bootstrapping/startup step?
        chrisseaton 7y ago
        Yes, rewrite all of the JVM into Java and ship an AOT-compiled binary.
      - pron 7y ago
        BTW, there's much more assembly code in OpenJDK than you'd find by looking for assembly files. There's a lot of code (all of the interpreter, for example) that's generated at startup time, and written in assmebly as a C++ DSL. E.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateTable_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x... and https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x...
eadler 7y ago
The entry to the article suggests compiling for your architecture and the n deps several other things. The article benchmarks - Ofast which is poorly named. It's really -Obroken-by-design. It'll be "faster" but completely break applications. It also suggests using omit frame pointer which destroys debugability. -march and -mtune are the parts that the the article title and intro actually suggest. While possible, I see no evidence that this matters. As I understand it the arch that Java is compiled with is not the same as the one that gets used for JIT compiling.
- earenndil 7y ago
  > [-Ofast will] be "faster" but completely break applications Except for the jvm, apparently. And everything else I've tried it with. > It also suggests using omit frame pointer which destroys debugability. Which is completely useless except for jvm developers. > As I understand it the arch that Java is compiled with is not the same as the one that gets used for JIT compiling. The performance of the compiler itself matters, not just the performance of the generated code, because, since it's a JIT, compiler code continues to run.
  - rjsw 7y ago
    The Hotspot JIT reads the CPU configuration at runtime to choose which optimizations are best or which instruction extensions are available.
    - chrisseaton 7y ago
      That doesn't help the performance of the runtime code, which is C++ or AOT-compiled Java.
    - pron 7y ago
      Right, but the OpenJDK VM (HotSpot) uses three JITs -- C1, C2 and Graal -- and two of them are written in C++, so C++ compiler flags could affect the performance of the JIT compilers, although not of the code they generate. Because the performance of the emitted code is far more important than the performance of the compiler, I doubt that will make a difference, but there are other important parts of the OpenJDK VM that are written in C++ and whose performance might be affected, most notably the GCs.
NullPrefix 7y ago
>funroll loops Reads like it came right from the Gentoo ricing guide.
exabrial 7y ago
Seems like something GraalVM could do at runtime!
this_user 7y ago
Whether or not the build may already be optimised depends on your source for the JDK. Looks like the Arch build of the OpenJDK is already using -O3.
- mumblemumble 7y ago
  It's not about what level of optimization is used, so much as what particular CPU generation the target is being optimized toward. The public binary distributions have to limit themselves to what X86-64 looked like when it first came out in 2003, which means they can't take advantage of any new instructions that were introduced in the past 16 years.
ambrop7 7y ago
> -march=native and -mtune=broadwell tell the compiler to optimize for your architecture. One would think given the compiler documentation that march implies mtune, but this is apparently not the case. That sounds like a bug to me which should be reported.
- saagarjha 7y ago
  There's a thread discussing that topic: https://lemire.me/blog/2018/07/25/it-is-more-complicated-than-i-thought-mtune-march-in-gcc/#comment-321471 https://lemire.me/blog/2018/07/25/it-is-more-complicated-tha...
oso2k 7y ago
Interesting that `-Ofast` & `-O3` were chosen to bench and not `-Osize`. In some real-world cases, `-Osize` can beat `-O3` because it will impact caches less with the smaller code size. This has interesting affects also when the workload is is highly parallel/threaded and less sequential. It also reduces side-effects of trying to create fast, possibly unrolled loop code.
- paulddraper 7y ago
  With today's L1/L2 caches, it's been a long time since I've seen -Osize not hurt performance.
- bcaa7f3a8bbc 7y ago
  This is the wisdom from the old days, and it's still true in many cases. But I believe compiler developers are trying to keep -O3/-Os working as advertised by their literal meaning, especially when it's combined with -march and -mtune, the cases of performance degradation should be fewer by now. For example, by using the knowledge of the subarchitecture, compilers can optimizing the code for Intel's MicroFusion rather than performing useless loop unrolling that actually degrades performance. In all benchmarks on Phoronix since GCC 4.9, they showed -Os is almost always slower than -O2 and -O3. https://www.phoronix.com/scan.php?page=article&item=gcc_49_optimizations&num=2 https://www.phoronix.com/scan.php?page=article&item=gcc_49_o... Linux kernel used to prefer -Os at everywhere, but now it has -O2 and -O3 as well. I think there is a measurable performance improvement in benchmarks in some cases. https://github.com/torvalds/linux/blob/15f5db60a13748f44e5a14a2573c2cfcdc152f1c/init/Kconfig#L1211 https://github.com/torvalds/linux/blob/15f5db60a13748f44e5a1...
- nwallin 7y ago
  It's very dependent on the code. I'm currently writing a path tracer as a side project, and -Ofast is sickeningly faster than -O2. Like 4-5 times faster. -O3 duplicates all the loops into two versions: one with AVX instructions chunking 8 iterations at a time, and a second scalar version that does the final 1-7 iterations. -Ofast is a little bit faster than -O3 because it generates the approximate rsqrtps and rcpps instructions. However this is a special case. Most code isn't heavy on crunching massive quantities of floats, and much of the code that does isn't written in a way that gives the compiler the freedom to autovectorize your loops. And a surprisingly large amount of code is still compiled with MSVC which won't vectorize at all. In gcc, -O2 is generally fastest for general purpose code, both faster than -Os and -O3. As an example of why -O2 is faster than -Os, -O2 will optimize signed integer division by a constant power of two into a handful of bitwise instructions, which are larger than a single (but much, much slower) division instruction. (signed integer division can't be replaced with a single bitshift because negative integers work differently. unsigned integer division can be replaced by a single bitshift.) People think this is a universal optimization, but it's a size tradeoff so -Os specifically eschews it.
bcaa7f3a8bbc 7y ago
-Ofast enables unsafe floating-point optimizations that might give a performance boost for applications which don't need strict compliance. For example, FP operations cannot be optimized by using the association rule due to various concerns, but -Ofast enables -fassociative-math and allows such optimization. If your program just computes a bunch of numbers and doesn't rely on some uncommon features such as NaN or signed zero, it would only slightly change the last irrelevant few significant digits of the result, and greatly speed up your program. But the general rule-of-thumb is that -Ofast should not be used, unless you know what the program is doing and how the optimization affects it. A more meaningful comparison is -O2 vs. -O3 vs. -O3 -march=native -mtune=broadwell. Or run the OpenJDK test suite with -Ofast and see whether there are failed tests.

127 points by mring33621 7y ago

pron 7y ago

Precisely what compilers do for a given flag varies by compiler and by version. There could potentially be issues with certain optimizations (unfortunately, the OpenJDK VM does have undefined behavior, although we're attempting to gradually reduce it; the chance of a real problem due to undefined behavior certainly increases with the optimization level, as does the probability of a compiler bug), and there have been such issues in the past. So while building OpenJDK with particular optimizations for your particular hardware might be worthwhile in some cases, it's not for the faint of heart, and it should be done with care and extensive testing. If you intend to deploy such a custom-built OpenJDK in production, you should strongly consider getting the JCK [1] (the Java TCK) and testing your build for conformance (for all the VM configurations you'll use: GC choice, compiler choice etc.). A safer and easier way to get "free" performance speedups is to use the most recent JDK (currently 13). [1]: http://openjdk.java.net/groups/conformance/JckAccess/ http://openjdk.java.net/groups/conformance/JckAccess/

danwills 7y ago
I wonder whether Gentoo might have an edge here (even in general beyond just jdk) since nearly everything on the system is built with the local CPU as the optimisation target? It certainly reduces the need to not be 'feint of heart' to build things too as it's part of business-as-usual. Whether Gentoo itself requires one to not be feint of heart, is definitely an open question!
saagarjha 7y ago
> unfortunately, the OpenJDK VM does have undefined behavior, although we're attempting to gradually reduce it Is it a goal to remove undefined behavior completely? Because I seem to recall certain architectural decisions being completely reliant on undefined behavior, such as signal handlers as implicit null checks…
- chrisseaton 7y ago
  You can write these little architectural parts in assembly rather than C, to avoid having to write undefined behaviour.
  - saagarjha 7y ago
    Does the JVM use assembly for this? I’d expect writing all of the VM code that handles Java objects in assembly for each platform would be a bit difficult, and I’m not sure I saw enough assembly files in the project for this…
    - chrisseaton 7y ago
      No I mean it is an option available to avoid undefined behaviour, not that this is what the JVM does. But moving more of the implementation of the JVM (or all of it!) to Java is the real solution to all this in my opinion.
      - saagarjha 7y ago
        > No I mean it is an option available to avoid undefined behaviour, not that this is what the JVM does. Ah. > But moving more of the implementation of the JVM (or all of it!) to Java is the real solution to all this in my opinion. And what, ship a Graal binary to cut the bootstrapping/startup step?
        chrisseaton 7y ago
        Yes, rewrite all of the JVM into Java and ship an AOT-compiled binary.
    - pron 7y ago
      BTW, there's much more assembly code in OpenJDK than you'd find by looking for assembly files. There's a lot of code (all of the interpreter, for example) that's generated at startup time, and written in assmebly as a C++ DSL. E.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateTable_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x... and https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x...

eadler 7y ago

The entry to the article suggests compiling for your architecture and the n deps several other things. The article benchmarks - Ofast which is poorly named. It's really -Obroken-by-design. It'll be "faster" but completely break applications. It also suggests using omit frame pointer which destroys debugability. -march and -mtune are the parts that the the article title and intro actually suggest. While possible, I see no evidence that this matters. As I understand it the arch that Java is compiled with is not the same as the one that gets used for JIT compiling.

earenndil 7y ago
> [-Ofast will] be "faster" but completely break applications Except for the jvm, apparently. And everything else I've tried it with. > It also suggests using omit frame pointer which destroys debugability. Which is completely useless except for jvm developers. > As I understand it the arch that Java is compiled with is not the same as the one that gets used for JIT compiling. The performance of the compiler itself matters, not just the performance of the generated code, because, since it's a JIT, compiler code continues to run.
- rjsw 7y ago
  The Hotspot JIT reads the CPU configuration at runtime to choose which optimizations are best or which instruction extensions are available.
  - chrisseaton 7y ago
    That doesn't help the performance of the runtime code, which is C++ or AOT-compiled Java.
  - pron 7y ago
    Right, but the OpenJDK VM (HotSpot) uses three JITs -- C1, C2 and Graal -- and two of them are written in C++, so C++ compiler flags could affect the performance of the JIT compilers, although not of the code they generate. Because the performance of the emitted code is far more important than the performance of the compiler, I doubt that will make a difference, but there are other important parts of the OpenJDK VM that are written in C++ and whose performance might be affected, most notably the GCs.

NullPrefix 7y ago

>funroll loops Reads like it came right from the Gentoo ricing guide.

exabrial 7y ago

Seems like something GraalVM could do at runtime!

this_user 7y ago

Whether or not the build may already be optimised depends on your source for the JDK. Looks like the Arch build of the OpenJDK is already using -O3.

mumblemumble 7y ago
It's not about what level of optimization is used, so much as what particular CPU generation the target is being optimized toward. The public binary distributions have to limit themselves to what X86-64 looked like when it first came out in 2003, which means they can't take advantage of any new instructions that were introduced in the past 16 years.

ambrop7 7y ago

> -march=native and -mtune=broadwell tell the compiler to optimize for your architecture. One would think given the compiler documentation that march implies mtune, but this is apparently not the case. That sounds like a bug to me which should be reported.

saagarjha 7y ago
There's a thread discussing that topic: https://lemire.me/blog/2018/07/25/it-is-more-complicated-than-i-thought-mtune-march-in-gcc/#comment-321471 https://lemire.me/blog/2018/07/25/it-is-more-complicated-tha...

oso2k 7y ago

Interesting that `-Ofast` & `-O3` were chosen to bench and not `-Osize`. In some real-world cases, `-Osize` can beat `-O3` because it will impact caches less with the smaller code size. This has interesting affects also when the workload is is highly parallel/threaded and less sequential. It also reduces side-effects of trying to create fast, possibly unrolled loop code.

paulddraper 7y ago
With today's L1/L2 caches, it's been a long time since I've seen -Osize not hurt performance.
bcaa7f3a8bbc 7y ago
This is the wisdom from the old days, and it's still true in many cases. But I believe compiler developers are trying to keep -O3/-Os working as advertised by their literal meaning, especially when it's combined with -march and -mtune, the cases of performance degradation should be fewer by now. For example, by using the knowledge of the subarchitecture, compilers can optimizing the code for Intel's MicroFusion rather than performing useless loop unrolling that actually degrades performance. In all benchmarks on Phoronix since GCC 4.9, they showed -Os is almost always slower than -O2 and -O3. https://www.phoronix.com/scan.php?page=article&item=gcc_49_optimizations&num=2 https://www.phoronix.com/scan.php?page=article&item=gcc_49_o... Linux kernel used to prefer -Os at everywhere, but now it has -O2 and -O3 as well. I think there is a measurable performance improvement in benchmarks in some cases. https://github.com/torvalds/linux/blob/15f5db60a13748f44e5a14a2573c2cfcdc152f1c/init/Kconfig#L1211 https://github.com/torvalds/linux/blob/15f5db60a13748f44e5a1...
nwallin 7y ago
It's very dependent on the code. I'm currently writing a path tracer as a side project, and -Ofast is sickeningly faster than -O2. Like 4-5 times faster. -O3 duplicates all the loops into two versions: one with AVX instructions chunking 8 iterations at a time, and a second scalar version that does the final 1-7 iterations. -Ofast is a little bit faster than -O3 because it generates the approximate rsqrtps and rcpps instructions. However this is a special case. Most code isn't heavy on crunching massive quantities of floats, and much of the code that does isn't written in a way that gives the compiler the freedom to autovectorize your loops. And a surprisingly large amount of code is still compiled with MSVC which won't vectorize at all. In gcc, -O2 is generally fastest for general purpose code, both faster than -Os and -O3. As an example of why -O2 is faster than -Os, -O2 will optimize signed integer division by a constant power of two into a handful of bitwise instructions, which are larger than a single (but much, much slower) division instruction. (signed integer division can't be replaced with a single bitshift because negative integers work differently. unsigned integer division can be replaced by a single bitshift.) People think this is a universal optimization, but it's a size tradeoff so -Os specifically eschews it.

bcaa7f3a8bbc 7y ago

-Ofast enables unsafe floating-point optimizations that might give a performance boost for applications which don't need strict compliance. For example, FP operations cannot be optimized by using the association rule due to various concerns, but -Ofast enables -fassociative-math and allows such optimization. If your program just computes a bunch of numbers and doesn't rely on some uncommon features such as NaN or signed zero, it would only slightly change the last irrelevant few significant digits of the result, and greatly speed up your program. But the general rule-of-thumb is that -Ofast should not be used, unless you know what the program is doing and how the optimization affects it. A more meaningful comparison is -O2 vs. -O3 vs. -O3 -march=native -mtune=broadwell. Or run the OpenJDK test suite with -Ofast and see whether there are failed tests.