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

11–20 of 62 posts

Re: JVM JIT optimization techniques

#11

Post by bitmapbrother »

NotRustAgain wrote: post #9
bitmapbrother wrote: post #6

Earlier quoted context omitted.

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

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

Ah, synthetic benchmarks. Are you really sure they're consistently twice as slow? Your link shows otherwise.

  mandelbrot 17% slower
  fannkuch-redux 34% slower
  fasta 38% slower
  fasta-redux 39% slower
  pidigits 44% slower
So much for predicting my next argument.

Re: JVM JIT optimization techniques

#13

Post by CherryPickMuch »

bitmapbrother wrote: post #11
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...

Ah, synthetic benchmarks. Are you really sure they're consistently twice as slow? Your link shows otherwise. mandelbrot 17% slower fannkuch-redux 34% slower fasta 38% slower fasta-redux 39% slower pidigits 44% slower So much for predicting my next argument.

How come you left out these ones?

    spectral-norm 115% slower
    reverse-compliment 121% slower
    n-body 136% slower
    regex-dna 235% slower
    k-nucleotide 253% slower
Cherry picking your data shows you're either dishonest or really lost in your denial.

Re: JVM JIT optimization techniques

#14

Post by pron »

zmmmmm wrote: post #4

It's interesting how most of the optimizations are only really available if you essentially write your programs in a functional style. That is, they all depend on the compiler being able to analyse the local scope to decide whether the state changes are confined enough that it can perform an optimization without changing behavior. If a reference escapes, even into a private, instance variable, the compiler will (admi…

That's not a functional style, but an observation of how most (non-pathological) code behaves. If you're talking about escape analysis and stack allocation, the functional style doesn't help, because references escape all the time. That they're pointing to immutable objects doesn't matter.

In any case, whether functional or not, the observation is that many objects have limited scopes, that correspond to structural scopes in the code.

Re: JVM JIT optimization techniques

#15

Post by userbinator »

NotRustAgain wrote: post #9
bitmapbrother wrote: post #6

Earlier quoted context omitted.

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

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

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  12775
    C gcc  37.32   793652   11651
...that Java is on average half as fast as C and uses 2.5x more memory, while requiring slightly more source code.

Re: JVM JIT optimization techniques

#16

Post by pron »

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 with a coding style that became popular in the '90s. You could see the very same in C++ applications back then, but then Java took over. The big enterprise applications of the '90s and '00s reflect the prevailing mindset of the time. Java applications written today don't look like that.

> In my experience, a "simple, elegant" design --- which does not necessarily mean "highly abstract" --- tends to be very close to optimal anyway, with the compiler's optimiser doing the remaining work. That makes me wonder whether claiming a language/runtime/compiler has powerful optimisation abilities is actually a reflection of how much the typical source code in the language has to be "cleaned up" by the optimiser in order to be decently efficient.

In that case I think your experience may be limited, or that you're unaware how big "the remaining work" may actually be, especially on modern hardware. HotSpot has proven extremely adept at running many different code styles very efficiently. HotSpot's next-gen compiler, Graal[1], is IMO the biggest breakthrough in compilation technology of the past decade. It runs Java faster than C2 (HotSpot's current compiler), Python faster than PyPy, and JS as fast as any other VM out there. It even has a C frontend, which, while not yet matching gcc, performs surprisingly well considering how little effort has been put into it.

This kind of work can be very important, namely, the ability to optimize code across different languages. A recent paper[2] found that re-writing parts of SQLite in Python (!), instead of the original C, can result in a 3x (!) performance boost when running in an application, as application and DBMS code can be optimized as one unit.

[1]: https://wiki.openjdk.java.net/display/Graal/Publications+and...

[2]: http://arxiv.org/abs/1512.03207

Re: JVM JIT optimization techniques

#17

Post by pron »

NotRustAgain wrote: post #9
bitmapbrother wrote: post #6

Earlier quoted context omitted.

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

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 shows you that the microbenchmarks don't tell the whole story.

Right now, the JVM's biggest performance issue is the lack of value types. Once they arrive -- and work is well underway -- beating Java would be harder and harder, especially given new compilers like Graal. But in any event, I just don't see large developers switch back to C++ (or Rust) en masse. Memory usage is hardly an issue, as RAM is very cheap and underutilized in server environments anyway. Spending effort to conserve RAM just doesn't make any sense, unless you're targeting RAM constrained environments.

Re: JVM JIT optimization techniques

#18

Post by FreezerburnV »

NotRustAgain wrote: post #9
bitmapbrother wrote: post #6

Earlier quoted context omitted.

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

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 stuff exists that is quite the contrary. Two easy examples:

- Cyberduck is written in Java, yet nobody seems to be complaining about how slow and bloated it is.

- There exists a version of Quake 2 written in Java: http://bytonic.de/html/benchmarks.html It seems to be able to push out more frames than native, actually.

Both of those are real software that actually run well on Java, regardless of penalty paid for running in a VM, JIT, and GC.

Also when looking at the amount of memory and time taken when comparing C to Java in the microbenchmarks, always be sure to mentally factor in the base overhead of starting up the JVM both in time and memory. It's pretty easy to see that when a C version takes up something like 100KB of memory and the Java one takes up 30MB, Java consistently takes up at least ~30MB regardless of how much memory is required for that microbenchmark. When the C version takes up 300MB and the Java one takes up 700MB, that's a bit better of a comparison. (though still not perfect, because the Java GC will reserve a lot of memory for itself, even if it isn't using the full 700MB, if it feels it needs that much, etc.)

Re: JVM JIT optimization techniques

#19

Post by userbinator »

bitmapbrother wrote: post #6
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…

Ah, the Java is slow argument. When were you doing Enterprise Java? It must have been around the pre HotSpot years. As for applications that are huge, memory hogs, complex and non elegant, well, congratulations you just described the majority of enterprise applications.

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". Where are all the "C is not slow" articles, for example? I'm sure anyone who has used a non-trivial Java application, not even an "Enterprise" one, is immediately aware that it seems slower, even those who might not know at all what Java is.

Re: JVM JIT optimization techniques

#20

Post by bitmapbrother »

CherryPickMuch wrote: post #13
bitmapbrother wrote: post #11

Earlier quoted context omitted.

Ah, synthetic benchmarks. Are you really sure they're consistently twice as slow? Your link shows otherwise. mandelbrot 17% slower fannkuch-redux 34% slower fasta 38% slower fasta-redux 39% slower pidigits 44% slower So much for predicting my next argument.

How come you left out these ones? spectral-norm 115% slower reverse-compliment 121% slower n-body 136% slower regex-dna 235% slower k-nucleotide 253% slower Cherry picking your data shows you're either dishonest or really lost in your denial.

Perhaps you should read his reply more carefully next time. He said the benchmarks were "consistently 2x" as slow. He was wrong and the rest of the synthetic benchmarks you posted just corroborated my point.

As for being dishonest, well, you're commenting from a newly minted temp account so it would seem you didn't have the courage/backbone to use your real one.

Post reply on HN