8 ms·

Graal Autovectorization

137 points by luu 7y ago

hoschicz 7y ago
Can someone explain what is new here? Does OpenJDK have autovectorization or is it just getting added to GraalVM now?
- boyter 7y ago
  I had always believed the OpenJDK did based on this http://prestodb.rocks/code/simd/ http://prestodb.rocks/code/simd/ which was on HN a while ago https://news.ycombinator.com/item?id=14636802 https://news.ycombinator.com/item?id=14636802 so yes? This is really out of my depth though, would love someone who actually knows this area to pipe in.
  - xyzzy_plugh 7y ago
    No, afaik this was not a default optimization. There are SIMD optimizations in specific paths but I'm not aware of general low level autovectorizations before this (outside of ORC/OIL which was never generally available for JVM afaik)
    - zjaffee 7y ago
      SuperUser is enabled by default on openJDK, but it's incredibly simplistic vectorizations being done as can be seen in the article the person above posted.
- StreamBright 7y ago
  It is getting added to Graal now. Disabled by default. OpenJDK has it for some architecture, I think Intel contributed it for x86 and there is this for aarch64. https://www.slideshare.net/mobile/linaroorg/auto-vectorization-support-in-openjdk9-hotspot-c2-compiler-bud1711 https://www.slideshare.net/mobile/linaroorg/auto-vectorizati... Update: This is about the FOSS edition not the EE one. See comment below.
  - pgrulich 7y ago
    So for Graal we have the situation that Graal EE (Enterprise Edition) has auto-vectorization. However, its not in the open-source version as Oracle holds it back. The implementation in this issue is however provided by Twitter.
    - StreamBright 7y ago
      Sorry I am not aware of EE and its features, I should have added that my comment was about the FOSS edition.
    - pjmlp 7y ago
      One should also note that if it wasn't for Oracle, MaximeVM would have been yet another cool dead technology out of Sun Research Labs. So quite the opposite of holding it back.
      - amalter 7y ago
        I think Graal and Graal EE on Oracle Cloud is one of the smartest product moves out of Oracle in .... idk ... forever? However, it seems like a knifes edge to walk on. If Graal CE gets uptake, are there enough compiler folks at Redhat, Azul, Google, et. al. to shrink (or overtake) the Graal EE performance edge. Graal CE must be “good enough” to get people hooked that they then want to hold their nose enough to engage with Oracle (through Cloud or license). Maybe the management and visualization advantages are enough? I don’t think so though. I also don’t think it will pay off (despite the incredible technical achievement that Graal is). I was just talking with an ex-Oracle SMB sales rep, and they left because they would persuade businesses off SQL Server on technical merits, only to see their clients steamrolled by the Compliance Department a year later. Larry is, 75 years old or so? I think recent Microsoft history can show goodwill can be created quickly, but it must be done from the top down.
        pjmlp 7y ago
        Commercial JDKs do pay off, so much that many of the commercial AOT compilers (since around 2000) are still in business, although with the ongoing support on OpenJDK that might change a bit (ExcelsiorJET just gave up). JIT and GC algorithms to the level done by JVM implementations don't come up with all nighters and weekend programming scratching an itch, and those software engineers need to be payed accordingly. So if others have a problem with Oracle, maybe they could compensate for the fact that Oracle employees still do 90% of Java development and OpenJDK related work.
mohsinmehmood 7y ago
The most powerful and free paraphrase online text tool, to create unlimited content for your websites. https://paraphrase.tools/ https://paraphrase.tools/
truth_seeker 7y ago
Very good move indeed. This is what a smart JIT should be able to do so that the programmer does not have to worry about various hardware-specific optimizations. Now since they are able to loop unroll it by analysing AST and converting into SIMD, it must also be possible to forward instructions to GPU/GPGPU in the future with little more effort. Similar efforts on JVM in the past - https://astojanov.github.io/blog/2017/12/20/scala-simd.html https://astojanov.github.io/blog/2017/12/20/scala-simd.html LLVM - https://llvm.org/docs/Vectorizers.html https://llvm.org/docs/Vectorizers.html GCC - https://www.gnu.org/software/gcc/projects/tree-ssa/vectorization.html https://www.gnu.org/software/gcc/projects/tree-ssa/vectoriza...
- chrisseaton 7y ago
  Note that of course the JVM's top-tier JIT compilers (C2, Graal EE) have already done this autovectorisation for many years - this is just the first time code has been contributed for the open source version of Graal, because previously it was an Enterprise-only feature in that compiler. For example open source code in C2 https://github.com/openjdk/jdk/blob/497cb3f4f4ae7f86c173139643adf8ec8401921e/src/hotspot/share/opto/superword.cpp https://github.com/openjdk/jdk/blob/497cb3f4f4ae7f86c1731396.... > Now since they are able to loop unroll it by analysing AST There's no AST analysis going on here - it operates at the graph level. > it must also be possible to forward instructions to GPU/GPGPU in the future with little more effort Hah. People have been trying general GPU offload for a decade and haven't really got anywhere yet. The blocking issue is finding work that is coarse-grained enough to make the context-switch worth it.
  - gmueckl 7y ago
    Efficient CPU implementations and efficient GPU implementations that solve the same problem are typically completely different algorithms for anything that is more complex than a big loop. Programming 64 4-wide or 8-wide extremely powerful cores is very different from programming 400 limited cores, each 16 wide.
  - apta 7y ago
    > this is just the first time code has been contributed for the open source version of Graal, because previously it was an Enterprise-only feature in that compiler. Is the Enterprise-only implementation different from what has been contributed to the open source version?
1f60c 7y ago
I had no idea Graal VM was open source! That's awesome.
moreati 7y ago
Does Graal being an Oracle project make anyone else nervous? I mean from a software license or patent perspective. On the technical side there's much to like. However I worry that once Graal becomes popular, Oracle will announce something that makes it risky to use without paying for a per-seat license or support package. I'm probably just showing my bias, but they have form in this area.
- pmart123 7y ago
  Probably. Larry Ellison always seems to find a way.
- Twirrim 7y ago
  It's an open source project. If Oracle does something disliked by the community, the community can fork and do whatever they like. This is something that has happened repeatedly with open source projects when the community has disliked the government of it, e.g. think Jenkins/Hudson situation. Or going way back Mambo/Joomla. Disclaimer: I work for Oracle, but nothing to do with Graal etc.
  - eslaught 7y ago
    Looking at the license [1], it appears to be GPL v2 with a classpath exception. This means it doesn't directly deal with the issue of patents, only copyright. There have been cases in the past of companies going after users for patents on otherwise open source projects. The worst part is, Oracle reserves those right so they can decide retroactively to go after those users (unless Oracle decides to modify/replace the license). [1]: https://github.com/oracle/graal/blob/master/LICENSE https://github.com/oracle/graal/blob/master/LICENSE
    - repolfx 7y ago
      Actually large parts are under the Universal Permissive License these days, which explicitly deals with patent grants. e.g. https://github.com/graalvm/graaljs/blob/master/LICENSE https://github.com/graalvm/graaljs/blob/master/LICENSE https://opensource.org/licenses/UPL https://opensource.org/licenses/UPL I think Graal itself is GPL2+Classpath because it's derived from a codebase that was itself licensed that way, not because Oracle actually want ambiguity. If they wanted that, their new from-fresh codebases wouldn't be under a more precise open source license.

137 points by luu 7y ago

hoschicz 7y ago

Can someone explain what is new here? Does OpenJDK have autovectorization or is it just getting added to GraalVM now?

boyter 7y ago
I had always believed the OpenJDK did based on this http://prestodb.rocks/code/simd/ http://prestodb.rocks/code/simd/ which was on HN a while ago https://news.ycombinator.com/item?id=14636802 https://news.ycombinator.com/item?id=14636802 so yes? This is really out of my depth though, would love someone who actually knows this area to pipe in.
- xyzzy_plugh 7y ago
  No, afaik this was not a default optimization. There are SIMD optimizations in specific paths but I'm not aware of general low level autovectorizations before this (outside of ORC/OIL which was never generally available for JVM afaik)
  - zjaffee 7y ago
    SuperUser is enabled by default on openJDK, but it's incredibly simplistic vectorizations being done as can be seen in the article the person above posted.
StreamBright 7y ago
It is getting added to Graal now. Disabled by default. OpenJDK has it for some architecture, I think Intel contributed it for x86 and there is this for aarch64. https://www.slideshare.net/mobile/linaroorg/auto-vectorization-support-in-openjdk9-hotspot-c2-compiler-bud1711 https://www.slideshare.net/mobile/linaroorg/auto-vectorizati... Update: This is about the FOSS edition not the EE one. See comment below.
- pgrulich 7y ago
  So for Graal we have the situation that Graal EE (Enterprise Edition) has auto-vectorization. However, its not in the open-source version as Oracle holds it back. The implementation in this issue is however provided by Twitter.
  - StreamBright 7y ago
    Sorry I am not aware of EE and its features, I should have added that my comment was about the FOSS edition.
  - pjmlp 7y ago
    One should also note that if it wasn't for Oracle, MaximeVM would have been yet another cool dead technology out of Sun Research Labs. So quite the opposite of holding it back.
    - amalter 7y ago
      I think Graal and Graal EE on Oracle Cloud is one of the smartest product moves out of Oracle in .... idk ... forever? However, it seems like a knifes edge to walk on. If Graal CE gets uptake, are there enough compiler folks at Redhat, Azul, Google, et. al. to shrink (or overtake) the Graal EE performance edge. Graal CE must be “good enough” to get people hooked that they then want to hold their nose enough to engage with Oracle (through Cloud or license). Maybe the management and visualization advantages are enough? I don’t think so though. I also don’t think it will pay off (despite the incredible technical achievement that Graal is). I was just talking with an ex-Oracle SMB sales rep, and they left because they would persuade businesses off SQL Server on technical merits, only to see their clients steamrolled by the Compliance Department a year later. Larry is, 75 years old or so? I think recent Microsoft history can show goodwill can be created quickly, but it must be done from the top down.
      - pjmlp 7y ago
        Commercial JDKs do pay off, so much that many of the commercial AOT compilers (since around 2000) are still in business, although with the ongoing support on OpenJDK that might change a bit (ExcelsiorJET just gave up). JIT and GC algorithms to the level done by JVM implementations don't come up with all nighters and weekend programming scratching an itch, and those software engineers need to be payed accordingly. So if others have a problem with Oracle, maybe they could compensate for the fact that Oracle employees still do 90% of Java development and OpenJDK related work.

mohsinmehmood 7y ago

The most powerful and free paraphrase online text tool, to create unlimited content for your websites. https://paraphrase.tools/ https://paraphrase.tools/

truth_seeker 7y ago

Very good move indeed. This is what a smart JIT should be able to do so that the programmer does not have to worry about various hardware-specific optimizations. Now since they are able to loop unroll it by analysing AST and converting into SIMD, it must also be possible to forward instructions to GPU/GPGPU in the future with little more effort. Similar efforts on JVM in the past - https://astojanov.github.io/blog/2017/12/20/scala-simd.html https://astojanov.github.io/blog/2017/12/20/scala-simd.html LLVM - https://llvm.org/docs/Vectorizers.html https://llvm.org/docs/Vectorizers.html GCC - https://www.gnu.org/software/gcc/projects/tree-ssa/vectorization.html https://www.gnu.org/software/gcc/projects/tree-ssa/vectoriza...

chrisseaton 7y ago
Note that of course the JVM's top-tier JIT compilers (C2, Graal EE) have already done this autovectorisation for many years - this is just the first time code has been contributed for the open source version of Graal, because previously it was an Enterprise-only feature in that compiler. For example open source code in C2 https://github.com/openjdk/jdk/blob/497cb3f4f4ae7f86c173139643adf8ec8401921e/src/hotspot/share/opto/superword.cpp https://github.com/openjdk/jdk/blob/497cb3f4f4ae7f86c1731396.... > Now since they are able to loop unroll it by analysing AST There's no AST analysis going on here - it operates at the graph level. > it must also be possible to forward instructions to GPU/GPGPU in the future with little more effort Hah. People have been trying general GPU offload for a decade and haven't really got anywhere yet. The blocking issue is finding work that is coarse-grained enough to make the context-switch worth it.
- gmueckl 7y ago
  Efficient CPU implementations and efficient GPU implementations that solve the same problem are typically completely different algorithms for anything that is more complex than a big loop. Programming 64 4-wide or 8-wide extremely powerful cores is very different from programming 400 limited cores, each 16 wide.
- apta 7y ago
  > this is just the first time code has been contributed for the open source version of Graal, because previously it was an Enterprise-only feature in that compiler. Is the Enterprise-only implementation different from what has been contributed to the open source version?

1f60c 7y ago

I had no idea Graal VM was open source! That's awesome.

moreati 7y ago

Does Graal being an Oracle project make anyone else nervous? I mean from a software license or patent perspective. On the technical side there's much to like. However I worry that once Graal becomes popular, Oracle will announce something that makes it risky to use without paying for a per-seat license or support package. I'm probably just showing my bias, but they have form in this area.

pmart123 7y ago
Probably. Larry Ellison always seems to find a way.
Twirrim 7y ago
It's an open source project. If Oracle does something disliked by the community, the community can fork and do whatever they like. This is something that has happened repeatedly with open source projects when the community has disliked the government of it, e.g. think Jenkins/Hudson situation. Or going way back Mambo/Joomla. Disclaimer: I work for Oracle, but nothing to do with Graal etc.
- eslaught 7y ago
  Looking at the license [1], it appears to be GPL v2 with a classpath exception. This means it doesn't directly deal with the issue of patents, only copyright. There have been cases in the past of companies going after users for patents on otherwise open source projects. The worst part is, Oracle reserves those right so they can decide retroactively to go after those users (unless Oracle decides to modify/replace the license). [1]: https://github.com/oracle/graal/blob/master/LICENSE https://github.com/oracle/graal/blob/master/LICENSE
  - repolfx 7y ago
    Actually large parts are under the Universal Permissive License these days, which explicitly deals with patent grants. e.g. https://github.com/graalvm/graaljs/blob/master/LICENSE https://github.com/graalvm/graaljs/blob/master/LICENSE https://opensource.org/licenses/UPL https://opensource.org/licenses/UPL I think Graal itself is GPL2+Classpath because it's derived from a codebase that was itself licensed that way, not because Oracle actually want ambiguity. If they wanted that, their new from-fresh codebases wouldn't be under a more precise open source license.