
Java vs. Go performance - obituary_latte
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=go
======
bcg1
Look, Java is my right hand language, and I've never written a single line of
Go in my life.

But this is kind of unfair I think... the OpenJDK JVM has 20 years of
development behind it, and has probably had mountains of money sunk into
tuning f* out of it by the biggest most enterprisy players in the game.

I'm sure that there is a lot of low hanging fruit for Go to grab at to improve
performance, and most likely will. I can't stand benchmarks like this.

Oh yeah, and Java FTW ;)

~~~
threeseed
I don't think it is that unfair.

From my perspective the JVM hasn't seen major performance changes since the
early days e.g. Java 4. All of the major improvements have come in the library
space e.g. LMAX Disruptor, OpenHFT, Javolution.

~~~
mike_hearn
What perspective is that?

They ship new optimisations in more or less every release. I'm not sure what
workload you do that you've never seen performance improvements.

For example in Java 9 they're going to ship auto-vectorisation for certain
kinds of functional / parallel stream construct.

~~~
threeseed
Almost exclusively J2EE apps.

I am not saying there weren't any benefits from the JVM over the years only
that the biggest gains I've experienced have come from new types of libraries.

Fully agree with Java 9 though. It is the first release that I've been really
excited about. Project Jigsaw has the potential to fundamentally reimagine the
entire platform.

------
chvid
I find these benchmarks slightly dubious because everytime I look into the
actual code I find that is written some obscure manner.

For example - here is the code of the Java "knucleotide" benchmark:

[http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...](http://benchmarksgame.alioth.debian.org/u64q/program.php?test=knucleotide&lang=java&id=7)

(If I understand the website correctly.)

Look at the way data is read (scanPastHeader, readRestIntoByteArray,
fullSequence).

Or how the result of calculateHash is put into a HashMap where it immediately
would be hashed again.

I think this is neither the most natural or performant way of solving the
problem in Java.

~~~
igouy
Currently 7 Java k-nucleotide programs are shown.

 _> the most natural or performant way of solving the problem in Java_

"How to contribute programs"

[http://benchmarksgame.alioth.debian.org/play.html#contribute](http://benchmarksgame.alioth.debian.org/play.html#contribute)

------
hanief
Interesting. All this time I have a perception that Java app is slow as hell.
What a terribly wrong assumption. Color me impressed.

~~~
CookWithMe
Well, a lot of Java web apps ARE slow as hell, but one can't really blame
Java-the-language (or the JVM) for it.

Two examples from my experience:

JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to
render a simple hello world page, but if you mess up the state on a somewhat
complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0].

Hibernate is probably the worst offender. Well, the interface is somewhat
nice: you don't have to care about loading objects from the database,
Hibernate will load them for you. One object, one request at a time. Looking
at the hundreds of generated SQL requests it's quite easy to figure out how
you would write better SQL... but you don't write the SQL, Hibernate does :)

The lesson IMO is: If you're writing everything from scratch, language
performance is important. If you're using frameworks, the performance of the
whole stack is way more important and one should probably compare benchmarks -
or even real-world applications that are similar to ones use case - of the
whole stack.

[0]
[http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html](http://docs.oracle.com/javaee/5/tutorial/doc/bnaqq.html)

~~~
xtrumanx
What's wrong with having six lifecycle stages? I don't use JSF (or Java) but I
can understand the usefulness of having several lifecycle methods assuming you
can hook into them and add your own custom logic. The more lifecycle stages
the more precisely you can choose when during the request processing your
custom logic should be invoked.

~~~
CookWithMe
You're right, there isn't anything wrong with the six stages per se.

The root cause is really that (a) they're forcing a stateful model onto the
web and (b) that the way they're keeping/restoring the state is expensive.

The lifecycle stages are more a sympton of that. Most web framework these days
go with a stateless approach. One notable exception is the lift framework for
scala (although I'm not sure if it's really active anymore). I have only
looked very briefly at it, but it seemed to give the programmer more explicit
control of the state...

A simplified example to demonstrate the problem: Imagine a B2B app with a
medium-sized table, where each row contains multiple objects. A HTTP request
is send for performing an action on one object.

In a stateless approach, the programmer decides which objects he needs to
serve the request. In JSF, the framework restores the complete state as seen
in the previous request, and will also setup a lot of other magic (event
handlers, validators, what not) - no matter whether it is actually needed to
serve the request or not.

So one ends up with stages in the lifecycle that waste a lot of time, but one
really hasn't much control over.

~~~
xtrumanx
Oh sure, the stateful model thing you mention definitely sucks which is why I
hate using asp.net web forms and prefer asp.net mvc at the office.

Both of them have lifecycle methods, (for app start, request start, request
end, etc.) and for the most part I completely ignore them until the day I need
to use them and I'm glad they exist because the alternative would have been
writing a code in every endpoint of my application.

------
unoti
Go has a significantly smaller memory usage in all of the benchmarks, often by
a factor of 10x. For most workloads, this can have a huge impact on when you
need to spend more money to support your business.

~~~
Skinney
It also has a large impact on how often the GC is run. Less memory used, less
GC performed.

~~~
sacado2
It also produces less garbage since, more often than not, small values are
copied, not created on the heap then referenced.

------
logicchains
Since we're posting benchmarks, here's Java vs Haskell:
[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=ghc&lang2=java).
The Haskell implementations generally use much less memory than the Java ones
and perform competitively. In spite of criticism that some of the Haskell
implementations are not idiomatic, they're no more verbose than the Java ones
in terms of LOC.

------
nextw33k
This benchmark is out of date almost immediately because of the patch level of
the Java runtime and the Golang compilers change frequently.

I was half thinking of creating a VB6 module for LLVM just as a tongue in
cheek joke of taking a language with a slow runtime and effectively strapping
a V8 engine to it, but I saw someone already did most of the work:
[https://github.com/microcai/llvm-qbasic](https://github.com/microcai/llvm-
qbasic)

~~~
rockdoe
For that to be an argument two things would be required:

1) Changing patchlevels causing huge performance differences. 2) Those
"patchlevels" being immediately deployable to production in the real world.

Neither is true, so you don't have an argument.

------
InTheArena
This is a pretty eye opening chart. I know the Go guys have a philosophical
point about wanting to be able to reason the whole source code as the
justification for the Plan 9 and later GCC only stance, but I do have to think
that these numbers are poor enough that a LLVM port should be investigated.

I also think that it's a good think for Go that Apple hasn't open source'd
swift. I suspect it would thrash Go here.

~~~
beering
Maybe I come from a different world, but these numbers seem pretty good. If
you compare C++ and Go, C++ is 3x-1x faster than Go using more code.

For most applications that you'd expect to use Go for, that's decent
efficiency at a smaller memory footprint than Java. Enough, certainly, to make
a high-performance server that uses less RAM than Java and less code than C++.

~~~
nulltype
Go seems to be heavily optimized for write-time efficiency instead of runtime
efficiency.

------
craftit
As I understand it, Go also give some guarantees about the maximum amount of
time the garbage collection will stall the program. An issue where ever you
are trying to achieve consistent performance. As I understand it most of the
java benchmarks postpone clearing up memory until it can be done trivially at
exit, something you just can't do in a whole class of programs.

~~~
Skinney
Not yet, but that is planned for the next release.

------
mmf
The way I read the results Java is basically faster only on the regex
benchmark and it is known fact that today go has a slow regex library.
Everything else the results show Java to be slower with larger code and larger
memory footprint.

Why are all the Java fans psyched by these results?

~~~
igouy
_> faster only on the regex benchmark_

 _fwiw_ Also binary-trees, pidigits, n-body.

[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=go#faster-
programs-measurements)

------
TheLoneWolfling
Now if only the benchmarks game would actually support, say, PyPy. Or LuaJIT.

But nope, one implementation per language, and "language" defined rather
arbitrarily at that.

~~~
igouy
Please take the program source code and the measurement scripts and publish
your own measurements.

 _afaict_ we all feel the same way about this, we all feel that we should sit
on our hands and wait for someone else to do the chores we don't wish to do.

[http://benchmarksgame.alioth.debian.org/play.html#languagex](http://benchmarksgame.alioth.debian.org/play.html#languagex)

~~~
TheLoneWolfling
I would, if I had access to a machine that was somewhat stable w.r.t.
performance.

Alas, my only machine currently is my laptop, and it overheats often enough on
stress-tests that it's... less than accurate, shall I say?

------
karmakaze
Interesting that the 32-bit speed is skewed more in Java's favor. I suppose
the JVM was first 32-bit optimized where Go needn't be.

~~~
igouy
_iirc_ The programs compiled with Go 8g for x86 have always shown slower than
those compiled with Go 6g for x64.

------
obituary_latte
There are also many options available to compare different languages. Very
cool tool.

~~~
igouy
Also you can dive-into the source code and see the different ways people have
written programs in the same language --

[http://benchmarksgame.alioth.debian.org/u64q/performance.php...](http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=fannkuchredux)

Also for an overview --

[http://benchmarksgame.alioth.debian.org/u64/which-
programs-a...](http://benchmarksgame.alioth.debian.org/u64/which-programs-are-
fastest.html)

Also for a different overview --

[http://benchmarksgame.alioth.debian.org/u64/code-used-
time-u...](http://benchmarksgame.alioth.debian.org/u64/code-used-time-used-
shapes.php)

~~~
obituary_latte
That last link...very very cool. Much more interesting than the Java vs go
link I posted. You should submit it and spark a discussion :)

~~~
igouy
By my guest.

It's probably been submitted several times over the years, but there are
always people who haven't seen the benchmarks game at all, or have only seen
the direct comparisons.

The _interesting_ unique detail is "Shortest C++".

------
jackyb
I wonder if there will be any improvement if the Go code is compiled with GCC.

