5 ms·

Not sure if this is a fair comparison/criticism. Java has had 20 years to optimize what it does and doesn't inline and it isn't perfect either.

by chank 9y ago

weberc2 9y ago
I don't think the author meant this to be extrapolated as a critique of the stewardship of Go's developers ("You guys haven't caught up to Java yet!"). I read it as "Go isn't optimizing this case today, and Java shows us that it's at least possible".
- Someone 9y ago
  I read the title as indicating that he did mean it (somewhat) as a critique. It would have been kinder to say "Go does not inline functions when it COULD" instead. On the other hand, I'm not 100% convinced that it could without giving up fast compilation speed, a feature that the language's designers deem very important.
  - weberc2 9y ago
    Fair point. "Should" is pretty opinionated, even if I'm inclined to agree with the opinion.
_ph_ 9y ago
Indeed, and Hotspot is one of the crown jewels of the Java universe. Speed comparisons between Java and Go are not simple, because they are very different beasts. Java has a JIT which compiles code at run time. Hotspot is very good at using run-time information for optimizing the code. The Go compiler of course compiles in advance - so it lacks some information Hotspot might have, and is first of all tuned for compilation speed. But a lot of work has gotten into the Go compiler, and the work continues, so over time one can expect it to emit better code - the Go maintainers are usually very happy about use cases, where components don't behave as expected and improve the corresponding parts. This blog post compared a very small benchmark between the two languages, but for larger applications, the different way of doing things in Java and in Go has a big impact on performance. The Java object model brings a lot of overhead for memory allocations vs. the Go value types. So at minimum one would expect those languages to have different performance characteristics.
hyperpape 9y ago
Who cares about fairness? This isn't about whether you like Go, or like its creators. It's about the performance characteristics of the language. And there the question is whether the comparison is representative, which sounds a bit like "fair", but isn't really the same thing.[0] The point about 20 years to optimize only matters so far as it gives you some reason to believe that Go will improve, and catch up or surpass Java. If your timeline is a decade or more, that's quite important. If your timeline is this year, it's not. [0] I think there's a lot of room to criticize this benchmark's representativeness. It's literally one case.
- deleted 9y ago
  [deleted]

Not sure if this is a fair comparison/criticism. Java has had 20 years to optimize what it does and doesn't inline and it isn't perfect either.

by chank 9y ago

Not sure if this is a fair comparison/criticism. Java has had 20 years to optimize what it does and doesn't inline and it isn't perfect either.

weberc2 9y ago

I don't think the author meant this to be extrapolated as a critique of the stewardship of Go's developers ("You guys haven't caught up to Java yet!"). I read it as "Go isn't optimizing this case today, and Java shows us that it's at least possible".

Someone 9y ago
I read the title as indicating that he did mean it (somewhat) as a critique. It would have been kinder to say "Go does not inline functions when it COULD" instead. On the other hand, I'm not 100% convinced that it could without giving up fast compilation speed, a feature that the language's designers deem very important.
- weberc2 9y ago
  Fair point. "Should" is pretty opinionated, even if I'm inclined to agree with the opinion.

_ph_ 9y ago

Indeed, and Hotspot is one of the crown jewels of the Java universe. Speed comparisons between Java and Go are not simple, because they are very different beasts. Java has a JIT which compiles code at run time. Hotspot is very good at using run-time information for optimizing the code. The Go compiler of course compiles in advance - so it lacks some information Hotspot might have, and is first of all tuned for compilation speed. But a lot of work has gotten into the Go compiler, and the work continues, so over time one can expect it to emit better code - the Go maintainers are usually very happy about use cases, where components don't behave as expected and improve the corresponding parts. This blog post compared a very small benchmark between the two languages, but for larger applications, the different way of doing things in Java and in Go has a big impact on performance. The Java object model brings a lot of overhead for memory allocations vs. the Go value types. So at minimum one would expect those languages to have different performance characteristics.

hyperpape 9y ago

Who cares about fairness? This isn't about whether you like Go, or like its creators. It's about the performance characteristics of the language. And there the question is whether the comparison is representative, which sounds a bit like "fair", but isn't really the same thing.[0] The point about 20 years to optimize only matters so far as it gives you some reason to believe that Go will improve, and catch up or surpass Java. If your timeline is a decade or more, that's quite important. If your timeline is this year, it's not. [0] I think there's a lot of room to criticize this benchmark's representativeness. It's literally one case.

deleted 9y ago
[deleted]