6 ms·

Go does not inline functions when it should

61 points by lladnar 9y ago

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]
copx 9y ago
>My expectation would be that Go and Java should have similar performance in due time. Indeed, both are modern garbage-collected languages supported by major corporations with deep pockets. Google only dedicates a small amount of resources to Go, the vast majority of Google's software is not written in Go nor is that planned. In contrast Java has enormous enterprise support, and not just one company throwing money and manpower at it. You can run a profitable company which does nothing but develop and sell a special purpose garbage collector for Java.. try that with Go. No, the comparison does not fit at all. Java is in a completely different league.
stcredzero 9y ago
Micro benchmarks don't matter. Only particular benchmarks of your project/system matter. Benchmarks of how fast your team produces value matter most.
- abainbridge 9y ago
  As Daniel says in the article, "Of course, my benchmark is probably not representative of whatever systems people build, but it is also not crazily unrealistic. It is likely representative of many performance bottlenecks."
- ovao 9y ago
  A benchmark of how quickly a development team produces value has no relevance whatsoever to whether a language can, or should, be more aggressive at function inlining. These two notions are orthogonal. The benchmark detailed doesn't necessarily make a bulletproof case for the usefulness of more inlining in the Go compiler, as it's only a single benchmark, but for its intended purpose it at least shines a light on one aspect of the Go compiler the team may wish to evaluate more extensively in the future.
pstuart 9y ago
All in good time....
- akerro 9y ago
  He could wait 2 weeks before Java9 is released.

61 points by lladnar 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]

copx 9y ago

>My expectation would be that Go and Java should have similar performance in due time. Indeed, both are modern garbage-collected languages supported by major corporations with deep pockets. Google only dedicates a small amount of resources to Go, the vast majority of Google's software is not written in Go nor is that planned. In contrast Java has enormous enterprise support, and not just one company throwing money and manpower at it. You can run a profitable company which does nothing but develop and sell a special purpose garbage collector for Java.. try that with Go. No, the comparison does not fit at all. Java is in a completely different league.

stcredzero 9y ago

Micro benchmarks don't matter. Only particular benchmarks of your project/system matter. Benchmarks of how fast your team produces value matter most.

abainbridge 9y ago
As Daniel says in the article, "Of course, my benchmark is probably not representative of whatever systems people build, but it is also not crazily unrealistic. It is likely representative of many performance bottlenecks."
ovao 9y ago
A benchmark of how quickly a development team produces value has no relevance whatsoever to whether a language can, or should, be more aggressive at function inlining. These two notions are orthogonal. The benchmark detailed doesn't necessarily make a bulletproof case for the usefulness of more inlining in the Go compiler, as it's only a single benchmark, but for its intended purpose it at least shines a light on one aspect of the Go compiler the team may wish to evaluate more extensively in the future.

pstuart 9y ago

All in good time....

akerro 9y ago
He could wait 2 weeks before Java9 is released.