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.
Java vs. Go performance
61–69 of 69 posts
Re: Java vs. Go performance
#62Now 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.
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.
Re: Java vs. Go performance
#63Now 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.
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
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?
Re: Java vs. Go performance
#64There are also many options available to compare different languages. Very cool tool.
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... Also for an overview -- http://benchmarksgame.alioth.debian.org/u64/which-programs-a... Also for a different overview -- http://benchmarksgame.alioth.debian.org/u64/code-used-time-u...
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 :)
Re: Java vs. Go performance
#65Earlier quoted context omitted.
My understanding is that Go has a very simple optimizer. They were waiting for all the C code in the compiler to be translated to Go, which I believe was done in the last release.
not an expert, but i think you are talking about Go's garbage collection, which i don't think is an optimizer.
Some improvement to the garbage collector was done in the last release, and involved moving much of the runtime to Go. Making the compiler into Go, however, is actually only completed in the 1.5 (development) branch, to be released in... August, I think. That'll open up the work on the optimizer (and everything else in the compiler) to be done in Go.
Re: Java vs. Go performance
#66Earlier quoted context omitted.
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... Also for an overview -- http://benchmarksgame.alioth.debian.org/u64/which-programs-a... Also for a different overview -- http://benchmarksgame.alioth.debian.org/u64/code-used-time-u...
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 :)
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++".
Re: Java vs. Go performance
#67Earlier quoted context omitted.
You can't fine-tune memory usage and can run into cache issues (or worse) if you deal with quite a lot of data, though.
> You can't fine-tune memory usage What do you mean by that? There are some very fine-grained tuning options if you really need them.
Maybe I'm wrong, but I don't know how you can say you want, say, a list of objects of class Foo be in contiguous slots of memory, rather than having a list of references to objects. Because the latter is very cache-unfriendly. In go, you can say whether you want a []Foo or a []*Foo
Re: Java vs. Go performance
#68Earlier quoted context omitted.
> You can't fine-tune memory usage What do you mean by that? There are some very fine-grained tuning options if you really need them.
Maybe I'm wrong, but I don't know how you can say you want, say, a list of objects of class Foo be in contiguous slots of memory, rather than having a list of references to objects. Because the latter is very cache-unfriendly. In go, you can say whether you want a []Foo or a []*Foo
You can do that "by hand" with buffers (and the HFT guys do) but yeah it's not easy or fun. C#-style struct types are supposedly coming in the next version.
Re: Java vs. Go performance
#69Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
There's a series of articles about how Java don't have to be slow XML-laden crap: http://blog.paralleluniverse.co/2014/05/01/modern-java/ While I don't necessarily agree with everything in it (like Gradle builds), it's interesting to look at.
If you don't like XML but don't want to switch to Gradle, you could use another language atop Maven: https://github.com/takari/polyglot-maven