4 ms·

The release notes mention the new Go compiler is about 2x slower than the old C based one. It also mentions there's ongoing work to improve this. I wonder if th

by hencq 11y ago

The release notes mention the new Go compiler is about 2x slower than the old C based one. It also mentions there's ongoing work to improve this. I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? For my tiny hobby projects, compile times aren't an issue at all so I'm asking purely out of curiosity.

chimeracoder 11y ago
> I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? I imagine that's just a side-effect of rewriting the entire compiler; I'd expect the next versions to improve on the speed. Though in the meantime, if compilation time is an issue, you can always try gccgo. On my larger projects, it's slightly faster than gc 1.5. YMMV, obviously.
- gillianseed 11y ago
  What's the performance in gccgo nowadays, back when I tried it certain things was slightly faster but a lot was slower compared to the official compiler. I read that it mainly had to do with lack of escape analysis, has this changed in recent gcco releases ?
- Zariel 11y ago
  The new compiler is now garbage collected, and is generating lots of garbage, when the old compiler ran without any garbage collection. There is an interesting thread from the mailing list about this [0] [0] https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/discussion https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/dis...
deleted 11y ago
[deleted]
_ph_ 11y ago
They automatically translated C code to Go code. The objective was to produce correct Go code, speed was not an immediate concern - the auto-translated code mostly is very bad Go code, speed wise. Optimizing the Go code base of the compiler is the next step, planned to happen in subsequent releases.
- coldtea 11y ago
  >the auto-translated code mostly is very bad Go code, speed wise. Is it? It might not be particularly optimized, but why would that ("very bad speed wise") be the case?
  - theseoafs 11y ago
    Generally, compilers aren't very good at compiling code that isn't idiomatic for the language. This is by design, since compiler writers try to make idiomatic, common code fast first and foremost.

by hencq 11y ago

chimeracoder 11y ago

> I wonder if there are any estimates on how close to the original performance they think they can get. Do they expect to reach parity by, say, 1.6 or will it always be slower? I imagine that's just a side-effect of rewriting the entire compiler; I'd expect the next versions to improve on the speed. Though in the meantime, if compilation time is an issue, you can always try gccgo. On my larger projects, it's slightly faster than gc 1.5. YMMV, obviously.

gillianseed 11y ago
What's the performance in gccgo nowadays, back when I tried it certain things was slightly faster but a lot was slower compared to the official compiler. I read that it mainly had to do with lack of escape analysis, has this changed in recent gcco releases ?
Zariel 11y ago
The new compiler is now garbage collected, and is generating lots of garbage, when the old compiler ran without any garbage collection. There is an interesting thread from the mailing list about this [0] [0] https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/discussion https://groups.google.com/d/topic/golang-dev/6obxRcm-rqc/dis...

deleted 11y ago

[deleted]

_ph_ 11y ago

They automatically translated C code to Go code. The objective was to produce correct Go code, speed was not an immediate concern - the auto-translated code mostly is very bad Go code, speed wise. Optimizing the Go code base of the compiler is the next step, planned to happen in subsequent releases.

coldtea 11y ago
>the auto-translated code mostly is very bad Go code, speed wise. Is it? It might not be particularly optimized, but why would that ("very bad speed wise") be the case?
- theseoafs 11y ago
  Generally, compilers aren't very good at compiling code that isn't idiomatic for the language. This is by design, since compiler writers try to make idiomatic, common code fast first and foremost.