
Graal Autovectorization - luu
https://github.com/oracle/graal/pull/1692
======
truth_seeker
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/vectoriza...](https://www.gnu.org/software/gcc/projects/tree-
ssa/vectorization.html)

~~~
chrisseaton
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/497cb3f4f4ae7f86c1731396...](https://github.com/openjdk/jdk/blob/497cb3f4f4ae7f86c173139643adf8ec8401921e/src/hotspot/share/opto/superword.cpp).

> 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.

~~~
apta
> 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?

~~~
repolfx
Yes. This is Twitter's own implementation of the idea.

It may not get accepted. The maintainer of Graal asked Twitter some tough
questions about whether they'd really be maintaining it over the long run and
how much it really helped when they first proposed the patch and didn't seem
to get any answers.

This seems like a continuation of the problem that has made Java a money hole
for first Sun and then Oracle. Any attempt to stabilise its losses by making a
better Java with proprietary extensions causes companies like Twitter or Red
Hat to duplicate those features and submit competing implementations
themselves, rather than simply pay the original team. Those duplicates then
have to either both be maintained or one has to be rejected.

Given this sort of behaviour it's not clear that there's any sustainable way
to fund core Java development, other than indefinite cross-subsidisation by
other revenue lines.

~~~
apta
> Given this sort of behaviour it's not clear that there's any sustainable way
> to fund core Java development, other than indefinite cross-subsidisation by
> other revenue lines.

Wouldn't it move to a model similar to that of C++? Perhaps have a committee
that agree to what features get committed and maintained? There are obviously
many large companies with deep pockets who heavily rely on the JVM for their
core business.

------
moreati
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.

~~~
Twirrim
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
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
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.

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

~~~
StreamBright
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-
vectorizati...](https://www.slideshare.net/mobile/linaroorg/auto-
vectorization-support-in-openjdk9-hotspot-c2-compiler-bud1711)

Update: This is about the FOSS edition not the EE one. See comment below.

~~~
pgrulich
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.

~~~
pjmlp
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
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
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.

~~~
amalter
The niche JDK vendors are an order of magnitude off what Oracle needs to fund
JDK development. I suppose the closest example is Azul, which is using the
same "pay for performance" model of Graal EE.

I have absolutely nothing against some kind of commercial model for funding
the JDK. My comments were that in my opinion, the model is unfortunately
doomed:

\- Lack of goodwill for Oracle - Enterprises who are not yet Oracle customers
really really want to stay away from entering into a commercial agreement.
True or not, the perception is that a license agreement with Oracle comes with
aggressive and intrusive compliance audits.

\- Worse is better syndrome - Indeed Oracle is the primary developer on the
JDK, but the others entering this space are not hobbyists working on the side.
Plenty of serious vendors with serious compiler chops have skin in keeping
"free JRE" as the "fast enough" JRE. Redhat natch IBM, Google, Azul, Amazon,
apparently Twitter (see pull request). Graal EE is supposedly 30-40% faster on
some numeric workloads. But what if these players get that down to 20% or 10%
.. or suddenly there might be workloads where CE is faster. Much harder to
pitch that license agreement without compelling and unambiguous benefit.

I don't have a "problem" with Oracle, I'm just commenting on where I think the
industry is right now. Maybe Oracle will prove me wrong - Microsoft sure did.

~~~
pjmlp
The others entering on this space are mostly repacking Oracle's work, in what
concerns Java language and JVM specification.

From those listed by you, IBM and Azul have their own JVM implementations, and
just like Oracle require enterprise contracts for the cool features.

Finally, everyone complains about Oracle, yet no one else bothered to make a
counter offer to buy Sun.

~~~
repolfx
Doesn't matter though. Azul is probably doomed. Does anyone pay IBM for a
commercially enhanced JVM? I never heard of it.

IBM might have some enterprise JVM, but they just bought Red Hat. Red Hat
hired a bunch of former Sun/Oracle devs and then developed an open source
pauseless GC, thus chopping the knees out from underneath Azul and Oracle's
ZGC work.

What have Azul and IBM got now? They've gone down the path of trying to use
LLVM as a JIT compiler, but they're now in competition with Graal and
GraalVM+ZGC or Shenandoah would appear to match their capabilities. They had a
good run with edge whilst it lasted, but ultimately there are only so many
ways to make Java go faster and the world is apparently not short of companies
willing to do JVM heavy lifting for free. But of course, only on the parts
that other firms are trying to sell. I don't see Twitter implementing a
Project Valhalla anytime soon.

Oracle have developed some great tech in GraalVM and are now trying to turn it
into a real business. It's a remarkably long term strategy, but in the end
there are lots of people who don't want to see Java go back to being a
commercial product again and will happily 'burn' money to ensure it. And I'm
sure some would love to just spite Oracle too.

I suspect eventually Oracle will let most of the Java and Graal developers go,
probably reallocating them to a non-profit foundation that it slowly winds
back commercial support for until its investment in Java is more evenly
balanced with other large industry players. The existing OpenJDK people don't
seem to be under any commercial pressure or urgency already so it wouldn't be
a big shift for them.

~~~
pjmlp
Ever heard of Websphere, IBM i, IBM z/OS?

~~~
repolfx
Yes but I imagine a lot of developers haven't. How many new projects are being
started on a mainframe?

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

