4 ms·

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

by bcg1 12y ago

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 ;)

melling 12y ago
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.
- torvix 12y ago
  not an expert, but i think you are talking about Go's garbage collection, which i don't think is an optimizer.
  - pkroll 12y ago
    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.
ori_b 12y ago
As someone who has a fairly strong distaste for Java: It's not unfair at all. If I want to make the most of my CPU, and Java runs faster than Go, then that's the way it is. There may be historical reasons for this. There may be low hanging fruit for Go. But in the end, all that matters to the consumer of my project is "code go fast?".
deleted 12y ago
[deleted]
threeseed 12y ago
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 12y ago
  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 12y ago
    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.
- peterashford 12y ago
  That is utter and complete rubbish. Every major Java release has come with significant performance improvements.
lmm 12y ago
"Fair" to the Go designers? No. Go may indeed improve as time goes by. "Fair" to companies considering Go right now? Absolutely. If you're deploying a production system, you go to war with the army you have.
- bcg1 12y ago
  To clarify, I was making a point about the implication inherent in a "This vs. That" comparison... IMHO it is a total distraction, especially with contrived benchmarks, no matter how good they are. A few years back I remember Brian Goetz (I think) wrote in an article that object creation in Sun's JVM was down to like 10 machine instructions (I assume on x86). How much effort will it take to get that down to 9, 8, 7? On the other hand, choosing a language like Go that (I assume) still has a good deal of room from optimization could over time make applications run faster/better/cheaper without changing a single line of code. As for the "you go to war with the army you have" idea... that's fine, but by far the biggest performance problems in nearly every application I've seen are the result of programming errors/laziness/deadlines, and there is nothing that any platform can do to optimize away those problems
igouy 12y ago
> I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will. If potential improvement becomes actual improvement, you'll most likely see that result when the measurements shown on this website are updated for that version of Go. To-date the measurements for Go have been updated 9 times since Go 1.0 (3 years ago) and another 50 times in the 2 years before Go 1.0.

by bcg1 12y ago

melling 12y ago

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.

torvix 12y ago
not an expert, but i think you are talking about Go's garbage collection, which i don't think is an optimizer.
- pkroll 12y ago
  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.

ori_b 12y ago

As someone who has a fairly strong distaste for Java: It's not unfair at all. If I want to make the most of my CPU, and Java runs faster than Go, then that's the way it is. There may be historical reasons for this. There may be low hanging fruit for Go. But in the end, all that matters to the consumer of my project is "code go fast?".

deleted 12y ago

[deleted]

threeseed 12y ago

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 12y ago
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 12y ago
  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.
peterashford 12y ago
That is utter and complete rubbish. Every major Java release has come with significant performance improvements.

lmm 12y ago

"Fair" to the Go designers? No. Go may indeed improve as time goes by. "Fair" to companies considering Go right now? Absolutely. If you're deploying a production system, you go to war with the army you have.

bcg1 12y ago
To clarify, I was making a point about the implication inherent in a "This vs. That" comparison... IMHO it is a total distraction, especially with contrived benchmarks, no matter how good they are. A few years back I remember Brian Goetz (I think) wrote in an article that object creation in Sun's JVM was down to like 10 machine instructions (I assume on x86). How much effort will it take to get that down to 9, 8, 7? On the other hand, choosing a language like Go that (I assume) still has a good deal of room from optimization could over time make applications run faster/better/cheaper without changing a single line of code. As for the "you go to war with the army you have" idea... that's fine, but by far the biggest performance problems in nearly every application I've seen are the result of programming errors/laziness/deadlines, and there is nothing that any platform can do to optimize away those problems

igouy 12y ago

> I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will. If potential improvement becomes actual improvement, you'll most likely see that result when the measurements shown on this website are updated for that version of Go. To-date the measurements for Go have been updated 9 times since Go 1.0 (3 years ago) and another 50 times in the 2 years before Go 1.0.