3 ms·

This seems too simplistic. I am almost tempted to download the two frontends just to see why it is so much bigger. Lots of inlining (which -O3 would cause, it

This seems too simplistic. I am almost tempted to download the two frontends just to see why it is so much bigger. Lots of inlining (which -O3 would cause, it always does. I often find -O2 produces faster executables)? Debugging information? Pulling in the standard library? A compiler doesn't produce an extra 3MB of code for no good reason.

blinkingled 14y ago
Yeah, static linking could explain the code size difference. On my machine where I have gccgo 4.8 built and installed the Gccgo produced executable is way smaller than go 1.1 rc1 built. Go builds static executables whereas installed gccgo with just -O3 builds a dynamic one.
- hrez 14y ago
  Run 'strip' on it.
  - blinkingled 14y ago
    'strip' will remove symbols - debug or unused, but that doesn't change the way static libraries work - all the code, instead of being in the shared library dependency is stuffed into the executable. That's still going to be there.
  - CoffeeDregs 14y ago
    Just did. Huge difference. Updating.
CoffeeDregs 14y ago
This seems too simplistic. Definitely. I intended it as a reasonably quick comparison of Go and GCCGo, to see if GCCGo warranted further investigation right now. I really like the GCC toolchain so look forward to it supporting Go fully, but, as someone else noted, the Go compiler seems "fast enough". I often find -O2 produces faster executables)? Agreed. Probably should have used O2 or Os. I just recompiled with them and didn't see any significant difference. Anyhow, the post was really about answering the question: should you as a user of (and not developer of) Go check out GCCGo right now? From my perspective, I'm sticking with Go's compiler.
- DannyBee 14y ago
  Just FYI: Os hasn't been faster than O2 or O3 on desktop computers for many years, except for the apple branch of 4.2. The only reason it was ever faster is because of backend related issues that should be long since solved.

blinkingled 14y ago

Yeah, static linking could explain the code size difference. On my machine where I have gccgo 4.8 built and installed the Gccgo produced executable is way smaller than go 1.1 rc1 built. Go builds static executables whereas installed gccgo with just -O3 builds a dynamic one.

hrez 14y ago
Run 'strip' on it.
- blinkingled 14y ago
  'strip' will remove symbols - debug or unused, but that doesn't change the way static libraries work - all the code, instead of being in the shared library dependency is stuffed into the executable. That's still going to be there.
- CoffeeDregs 14y ago
  Just did. Huge difference. Updating.

CoffeeDregs 14y ago

This seems too simplistic. Definitely. I intended it as a reasonably quick comparison of Go and GCCGo, to see if GCCGo warranted further investigation right now. I really like the GCC toolchain so look forward to it supporting Go fully, but, as someone else noted, the Go compiler seems "fast enough". I often find -O2 produces faster executables)? Agreed. Probably should have used O2 or Os. I just recompiled with them and didn't see any significant difference. Anyhow, the post was really about answering the question: should you as a user of (and not developer of) Go check out GCCGo right now? From my perspective, I'm sticking with Go's compiler.

DannyBee 14y ago
Just FYI: Os hasn't been faster than O2 or O3 on desktop computers for many years, except for the apple branch of 4.2. The only reason it was ever faster is because of backend related issues that should be long since solved.