Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JVM JIT optimization techniques

advancedweb.hu

Post reply on HN
Print view View original

41–50 of 62 posts

Re: JVM JIT optimization techniques

#41

Post by pjmlp »

sievebrain wrote: post #36
chrisseaton wrote: post #35

Earlier quoted context omitted.

Calling it 'stack allocation' is confusing - object fields are replaced with scalars in the IR. The whole object is not allocated as it would have been on the heap but on the stack in the alloca sense. But I don't think the constraints are that bad are they? Can you give examples? Modern compilers like Graal can even scalar replace objects if they will escape in the future.

Given that the HotSpot compilers are not Graal and HotSpot's scalar replacement optimisation is notoriously fragile, I think the original statement was fair. Once Java 9 rolls around and Graal is just a plugin instead of a whole separate VM build, it'll be less fair, and if Graal ever becomes the default compiler that replaces C2 then it'll be even more fair, but I guess that is years away at best. The biggest constr…

It is not fair, because many of us do deployments in other JVMs, but people keep waving the flag Java performance == Hotspot as if e.g. C++ performance == gcc.

Re: JVM JIT optimization techniques

#42

Post by Alphasite_ »

FreezerburnV wrote: post #18
NotRustAgain wrote: post #9

Earlier quoted context omitted.

https://benchmarksgame.alioth.debian.org/u64q/java.html Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native. Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...

I mean, micro-benchmarks are just generally not something to put a huge amount of stock into in general, regardless of language. Software that scales out to hundreds of thousands if not millions of users is generally written in "slow", "bloated" languages, and seems to be doing ok. It really all depends on the use case, and who is creating the software. Most enterprise software is slow and bloated, but a lot of other…

Does their exist a JVM with an OS level shared heap, to reduce GC overhead? Obviously each can be collected independently of one another so pausing shouldn't be a significant issue and IPC becomes a Normal heap reference which may aid in performance.

Re: JVM JIT optimization techniques

#43

Post by pjmlp »

sievebrain wrote: post #37
userbinator wrote: post #19

Earlier quoted context omitted.

Not pre-HotSpot; I saw the release of HotSpot, and while it did improve performance considerably compared to before, it was still pretty bad compared to native. I see the proliferation of "Java is not slow" articles as a sign that it is --- if it wasn't, why would there be a need for such strong propaganda and carefully constructed microbenchmarks? Sun/Oracle have a deep interest in hiding their "naked emperor". Wher…

I guess you see a lot of such articles because of comments like yours - lots of people still think Java is generically slow or Java code is always bloated, despite not having used it for 10 years or more. Whilst such views persist, there will be articles arguing they're false based on newer data. Nobody writes "C is not slow" articles any more, but I remember a time when there were people who believed C++ was inheren…

So many memories...

Yeah, I remember the days when junior Assembly coders could easily write better code than any C compiler for home computers.

Or the days when the arguments that are now used against Java, Go, Swift and many others where used against Turbo Pascal, C, C++, Modula-2, Basic compilers.

The more things change, the more they stay the same, I guess.

Re: JVM JIT optimization techniques

#44

Post by geodel »

pron wrote: post #17
NotRustAgain wrote: post #9

Earlier quoted context omitted.

https://benchmarksgame.alioth.debian.org/u64q/java.html Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native. Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...

> Java is slow and bloated compared to native. What do you mean by "native"? C/C++? Yes, given enough effort you can write C code that outperforms Java code, sometimes handily, especially in single threaded or low-contention cases. Yet we did write applications in C/C++ before we switched to Java, we had excellent reasons to make the switch, and there have been precious few companies making the switch back. That show…

I feel with companies moving to cloud environment defending Java memory bloat will be harder and harder. Java's limited value types may be out by 2020-21 or so and it will be many more years libraries ecosystem start utilizing it. So we are still at least 10 years away from some form of Java value type available for general users.

Re: JVM JIT optimization techniques

#45

Post by userbinator »

FreezerburnV wrote: post #18
NotRustAgain wrote: post #9

Earlier quoted context omitted.

https://benchmarksgame.alioth.debian.org/u64q/java.html Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native. Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...

I mean, micro-benchmarks are just generally not something to put a huge amount of stock into in general, regardless of language. Software that scales out to hundreds of thousands if not millions of users is generally written in "slow", "bloated" languages, and seems to be doing ok. It really all depends on the use case, and who is creating the software. Most enterprise software is slow and bloated, but a lot of other…

It seems to be able to push out more frames than native, actually.

The table in your link shows it being 6% faster in one (literally) corner case, while all the other entries show it being slower by varying amounts. Keep in mind that in this benchmark a lot of the "heavy lifting" is being done by the GPU via OpenGL, so it isn't great for benchmarking languages that run on the CPU. It also doesn't mention what the "Original C Code" was compiled with.

Re: JVM JIT optimization techniques

#46

Post by userbinator »

sievebrain wrote: post #37
userbinator wrote: post #19

Earlier quoted context omitted.

Not pre-HotSpot; I saw the release of HotSpot, and while it did improve performance considerably compared to before, it was still pretty bad compared to native. I see the proliferation of "Java is not slow" articles as a sign that it is --- if it wasn't, why would there be a need for such strong propaganda and carefully constructed microbenchmarks? Sun/Oracle have a deep interest in hiding their "naked emperor". Wher…

I guess you see a lot of such articles because of comments like yours - lots of people still think Java is generically slow or Java code is always bloated, despite not having used it for 10 years or more. Whilst such views persist, there will be articles arguing they're false based on newer data. Nobody writes "C is not slow" articles any more, but I remember a time when there were people who believed C++ was inheren…

despite not having used it for 10 years or more

I just don't write code in Java anymore --- I still need to use some Java apps, and the difference remains obvious.

The other thing I've noticed is that a lot of those "Java is actually fast" articles are [1] entirely words about all the fancy optimisations JVMs do with no real numbers, [2] comparing Java with previous versions of itself, [3] comparing Java with highly dynamic languages like JavaScript, Python, or Ruby, or [4] microbenchmarks designed to specifically highlight certain JVM optimisations.

but I remember a time when there were people who believed C++ was inherently slower than C.

The C++ vs C case is slightly different, because C++ is essentially an extension of C. Some features like iostreams vs stdio are objectively slower on the C++ side, and efficient C++ code usually tends to look a lot like C. Those who say C++ is slower are referring to the "overuse" of C++ features that add overhead. As the benchmarks posted below show, even carefully written and optimised Java that looks like C is slower than C.

Re: JVM JIT optimization techniques

#47

Post by greydius »

userbinator wrote: post #3

for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM. Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, a…

> I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts

This is really a matter of perspective. A typical enterprise application is running on a beafy multicore processor and spending most of its threads' cycles waiting for database IO. Also, it's not really a concern if your jar file is 100 MB when your machine has 256 GB of ram. From this perspective, the fact that an application can be quickly slapped together from the multitude of Java libraries and frameworks by a stackoverflow savvy junior developer far far outweighs the marginal performance benefits that could be gained from using a language that compiles to native code.

The fact is that Hotspot has made the jvm perform "good enough" for this kind of domain. And keep in mind that many enterprise developers (at least in my experience) have never used a language besides Java, so this level of performance is normal to them.

Re: JVM JIT optimization techniques

#48

Post by pron »

geodel wrote: post #44
pron wrote: post #17

Earlier quoted context omitted.

> Java is slow and bloated compared to native. What do you mean by "native"? C/C++? Yes, given enough effort you can write C code that outperforms Java code, sometimes handily, especially in single threaded or low-contention cases. Yet we did write applications in C/C++ before we switched to Java, we had excellent reasons to make the switch, and there have been precious few companies making the switch back. That show…

I feel with companies moving to cloud environment defending Java memory bloat will be harder and harder. Java's limited value types may be out by 2020-21 or so and it will be many more years libraries ecosystem start utilizing it. So we are still at least 10 years away from some form of Java value type available for general users.

1. Memory "bloat" is always a better use of resources than increased development time, regardless of how you have to pay for it.

2. How are Java's value types limited?

3. I find your calculation extremely pessimistic. Lambda expression are widespread a couple of years after their release, and I see no reason why value types will be different. I think that 5 years are a better estimate for wide use of value types.

Re: JVM JIT optimization techniques

#49

Post by geodel »

pron wrote: post #16
userbinator wrote: post #3

for most of the time, many performance considerations are invisible from the higher abstraction levels, so you can concentrate writing simple, elegant and maintainable applications in Java, Scala, Kotlin or anything that runs on the JVM. Funny statement, at least for Java. I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, a…

> I don't know anyone who would say the majority of Java applications aren't huge, slow, memory-hogging beasts compared to equivalent native ones, and whose codebases are just as unoptimised for the perspective of the humans who have to work with them. I would, and I've been developing in Java for over ten years now, after ten years of C/C++. I think that your complaints have nothing to do with Java, and much to do w…

Well if Graal is faster why is it not made part JDK distribution.

Re: JVM JIT optimization techniques

#50

Post by MrBuddyCasino »

pvg wrote: post #29
userbinator wrote: post #15

Earlier quoted context omitted.

It's interesting that the "gz" column, which reflects the amount of source code required, shows a very slight trend towards C being smaller, although there are big exceptions like regex-dna and reverse-complement. I'm not seeing the 400x more memory - there is a 40x though. But if you add up the columns for the programs that have both C and Java versions, you get this rough summary... secs KB gz Java 76.33 2004048 12…

"half as fast as C and 2.5x the memory on average" is a stupendously good result for any managed runtime. Most don't get anywhere near it while providing more than acceptable performance in practice.

Yes, and 2.5x is something that can be dealt with by deploying beefier hardware. The productivity gain is what makes that tradeoff a no-brainer.
Post reply on HN