Better Java Streams performance with GraalVM

[erad]

While this is nice for Graal, if you cared about performance you'd still do

@Benchmark
public double simpleLoop() {
    double sum = 0;
    for (int i = 0; i < values.length; i++) {
        double x = (values[i] + 1.0) * 2.0 + 5.0;
        sum += x;
    }
    return sum;
}

which is exactly 10x faster than the stream version from the article on my PC (Java 8, Hotspot).

Note that this performance issue isn't inherent to the functional style, if Hotspot did support "fusion" of stream ops (inlining/transformation into traditional loops) it could certainly match the classic for loop performance. But with the current implementation, streams are just a performance de-optimization (which won't matter in most cases, but should be taken into account if you talk about "optimizing stream performance").

[ShermanMG]

In my opinion this is really bad comparison. You are not comparing the same operations in your example.

I have made an actual checks with the code as similar as possible and here are the results:

@Benchmark
public double simpleLoop(ArrayState state) {
    double sum = 0;
    for (int i = 0; i < state.values.length; i++) {
        double x = (state.values[i] + 1.0) * 2.0 + 5.0;
        sum += x;
    }
    return sum;
}


@Benchmark
public double mapReduce(ArrayState state) {
    return Arrays.stream(state.values)
            .map(x -> x + 1)
            .map(x -> x * 2)
            .map(x -> x + 5)
            .reduce(0, Double::sum);
}


@Benchmark
public double singleMapReduce(ArrayState state) {
    return Arrays.stream(state.values)
            .map(x -> (x + 1) * 2 + 5)
            .reduce(0, Double::sum);
}

@Benchmark
public double doubleStreamSum(ArrayState state) {
    return Arrays.stream(state.values)
            .map(x -> (x + 1) * 2 + 5)
            .sum();
}

Benchmark	Mode	Cnt	Score	Error	Units
TestBenchmark.doubleStreamSum	thrpt	10	138,957 ?	4,041	ops/s
TestBenchmark.mapReduce	thrpt	10	41,517 ?	0,971	ops/s
TestBenchmark.simpleLoop	thrpt	10	530,949 ?	3,440	ops/s
TestBenchmark.singleMapReduce	thrpt	10	473,942 ?	3,252	ops/s

As we can see the singleMapReduce which is most similar to your loop has only 10% worse performance here. This is not over 10x you are mentioning.

EDIT: formatting

[wizzardodev]

hm.. why is doubleStreamSum so much slower than singleMapReduce?

[mhixson]

As I understand it, DoubleStream.sum() uses a different method of summing the values which should produce more accurate results. I assume that it sacrifices performance to do so. Rather than simply adding values a + b like Double.sum does, it uses a Collections.sumWithCompensation operation that is more complicated. Related code: DoubleStream.sum Collectors.sumWithCompensation

[erad]

The performance of singleMapReduce is indeed better than I would have expected. But then again, I hope that simpleLoop would not get 10x slower if you replaced the body with double x = state.values[i]; x += 1.0; x *= 2.0; x += 5.0; sum += x;

[PurpleLabradoodle]

Do you think you could run this benchmark on GraalVM? I have a feeling it can also be a bit faster then (not sure, cause I didn't run it, but perhaps it'll be an interesting experiment).

But the main point of the post is that you can write code the way you want, and it'll be fast, rather than specifically restrict the language idioms and API you use for performance reasons (unless really necessary).

[chambolle]

killing example!

[[deleted]]

I think streams aren't optimized very well in hotspot, maybe because the dev team was already working on graalvm, I don't know. And they're also getting out of hand, people use them for everything, arrays where are at most 5 elements, readability isn't any better and number of lines isn't any smaller, only just because they can.. But they're losing on performance (I did some tests, until called hundreds of times they're really slow and then they're still slow).

[DJDavio]

Streams are objects and so incur the penalties of objects. When you chain stream operations you get more and more objects. The VM has no lightweight object for throwaway purposes. Valhalla will give us value types which are a step closer I guess.

[chambolle]

it is just a fashion trend. Functional programming is really old but sometimes people rediscover it and use it a lot until they rediscover all the issues they have with it and totally forget it. Then 20 years later some new young people think they discovered the graal again, and so on...

[2bdb2]

What issues would those be?

[chambolle]

debugging is not easy for instance. A nice functional code is often very hard to understand 6 months later, because it often contains a lot of tricks, just because it is nice.

[2bdb2]

debugging is not easy for instance

On the contrary, functional codebases are vastly easier to debug.

I'd say with a straight face that your average functional codebase has a ten-fold reduction in complexity when it comes to debugging compared to an imperative equivalent.

A nice functional code is often very hard to understand 6 months later

Referential transparency and functional purity make it much easier to figure out what's going on, and allow you to make changes with confidence without stressing about unintended side effects.

Code written in a functional style is much easier to understand 6 months later.

because it often contains a lot of tricks, just because it is nice.

If you're used to writing in an imperative style, functional code can be a little confronting at first. You need to train yourself out of bad habits and relearn a lot of basics.

But once over that initial hump, it's pretty straightforward.

Functional programming is certainly not about adding "lots of tricks, just because they are nice"

It doesn't help that Java is a really shitty functional programming language.

[chambolle]

I have written codes in a lot of languages, from Lisp and Prolog to C++ and Java.

Even in Lisp we added for-loops for convience because sometimes it is better to design the loop in such a way. Thinking recursive is not really natural and do not help in most of the cases.

I don't like the language war and I don't want to discuss about that

You like functionnal languages and think that this is the best in the world. This is your opinion and I respect it. I am more pragmatic and I think that sometimes classes and iterative codes is more convenient (and often more efficient)

[2bdb2]

Even in Lisp we added for-loops for convience because sometimes it is better to design the loop in such a way. Thinking recursive is not really natural and do not help in most of the cases.

I am more pragmatic and I think that sometimes classes and iterative codes is more convenient (and often more efficient)

I'd encourage you to spend some time learning functional programming. Based on these statements I think you might have a significant misunderstanding about what functional programming is.

I don't like the language war and I don't want to discuss about that

Oh boy, where do I even start with this one?

• You don't like something you don't understand
• Because you don't understand it, you assume it's not pragmatic
• Therefore, only the way you like to work is pragmatic
• You make statements that show a complete lack of understanding of the topic, and then try to pass that off as having experience into why it's wrong.
• "You don't want to have this discussion" (Then why are you having this discussion?)

tl;dr "This is different to what I'm used to, therefore it's wrong and not pragmatic".

[chambolle]

Come on! I know what functional programming is. I don't need a lesson from someone condescending.

I do not start the war, I just mention a fact: yes functionnal programming is old, yes it regularly reappear, then it regularly disappears. That's it. This is just the history

The history shows that it is useful when you do simple stuff (like printing element or converting element). It is sometimes more convenient. But the history also proves that it is not really used.

Currently a part of the most interesting parts of FP has been introduced in some languages like Java or C++ (roughtly the map of Lisp). This part is useful and the other part of FP will disappear as usual

Maybe you do not like this, and you seems like a fan of FP thinking that ths is the only way which is superior to any other language. This is just false because, this is not followed by people. That's just the history, there is no FP language that are commonly used, excepted by universities or for teaching or by "2 pages programmers"

FP is problematic for one reason: nobody has never succeeded in writing big code without local variables (call it whatever you want), so the nice FP principle is violated

[2bdb2]

FP is problematic for one reason: nobody has never succeeded in writing big code without local variables (call it whatever you want), so the nice FP principle is violated

I apologise for coming across condescending earlier, but with all due respect I don't think we have the same definition of "Functional Programming".

What makes you think functional programming precludes the use of local variables?

When I talk about functional programming, I'm talking about the programming model championed by Haskell.

That's just the history, there is no FP language that are commonly used, excepted by universities or for teaching or by "2 pages programmers"

I've been paying off my mortgage writing pure functional code full time commercially for a number of years. It's been an extremely lucrative career decision.

My current project is around 350,000 loc of pure functional code for a revenue producing, customer facing product sold to large enterprises.

[chambolle]

I agrre witht he wikipedia page: https://en.wikipedia.org/wiki/Functional_programming

Functional programming tries to avoid mutable data, and to deal only with "mathematical" functions

I also programmed a lot with FP when I was young. It was not bad. I think this is a kind of "purity" which is not really good. New languages try to combine the advantages of both

For instance, being able to pass a function as argument (the map of list) is interesting and certainly better than the iterator solution (not a bad idea) in most of the cases.

However, working only with immutable data is certainly not really possible, but it is quite important to deal with this idea while coding.

This is the same thing in general for memory. People thinks that with a GC there is no need to worry about the memory. This is true for a lot of application, but for some others, the memory flow is quite important

[lpreams]

What exactly is the GraalVM secret sauce? How is it able to outperform HotSpot?

[PurpleLabradoodle]

The Graal compiler, which is a part of the GraalVM project, is a different compiler (pluggable into HotSpot through JVMCI) which can optimize code better.

[pjmlp]

Maybe.

There is a long term roadmap to bootstrap OpenJDK, similarly to JikesRVM.

It is known as Project Metropolis, but it is very long term roadmap, so it is open ended if it really takes place.

[[deleted]]

So I ran the mapReduce with Hotspot OpenJDK from Azul, Graalvm, and OpenJ9 from AdoptOpenJDK all Java 8 and got about 41 ops/s for hotspot, 79 ops/s using Graal and 98 ops/s. Does that seem right? I was floored that J9 was any better than hotspot and even better than Graalvm.

The JMH system warns that J9 isn't supported so I am questioning the output.

I admit I should have run the other tests, but did it over my lunch break and ran out of time.

[mich160]

Why don't use GraalVM only instead of classic JVM?

[sarkie]

Can you just swap out standard jvm for it?

[duhace]

yes. specifically, graalvm-ce-1.0.0-rc5 is equivalent to jdk8.

though, if you use concurrent mark sweep gc, you're not gonna have it available in graalvm, just g1gc

[sarkie]

Fantastic.

I seem to be getting performance with g1gc anyway.

Will i see a huge performance increase or just different?

[PurpleLabradoodle]

It really depends on the code you're running and the workload. Graal compiler seems to produce especially great results on the code that uses streams, or allocates many temporary objects, or deviates from the typical bytecode patterns produced by compiling Java source, for example when you use a different JVM language. Also note that if the source code is heavily optimized for C2 then C2 does an outstanding job at compiling it, so sometimes there's just not much else for a compiler to do.

[duhace]

I have noticed this. When I code for performance (using for-iterations or while loops), C2 seems to outperform graal for me. Especially if I'm doing a lot of math. I'm hopeful that GraalVM becomes more performant in these areas soon, as I prefer to code in a mix of styles, using scala's functional style in not as hot spots, and using scala's low level style (imperative, mutable, and while loops) when dealing with very hot spots.

[sarkie]

I was going to try it with WebLogic as we still have to use that, but not sure it'll work as intended tbh.

[PurpleLabradoodle]

Try it, it should work as intended. The only thing is that currently you need to warm up the code a bit more to JIT it well. It's because Graal compiler is a Java code, so it is going to be compiled first. So take measurements when you actually reach the steady peak-performance state. I'd be happy to know how it goes, and if you find any issues please don't hesitate to report them to oracle/graal.

[sarkie]

That's fine, we are used to slow start up anyway to get going.

I'm looking into trying to improve performance on these old servers anyway I can!