7 ms·

I did not realise GCC supported Go until reading these release notes. What advantage/reason would I have for using GCC over the standard Go compiler?

by gchp 8y ago

gumby 8y ago
As Google has been paying Ian Taylor to write the GCC Go support since the very early days of Go I'd say you could consider GCC to also be a "standard" Go compiler.
pjmlp 8y ago
Performance, GCC does more optimization passes than the reference Go compiler. Supported platforms. Also it does have some extension pragmas and is easier to use for something like trying to use Go baremetal.
- benesch 8y ago
  Before you get too excited about possible performance wins, note that gccgo turns out to be much slower than gc (the standard Go compiler) on a lot of real workloads. Here's one such benchmark, taken recently, though it's admittedly a microbenchmark [0]. Dave Cheney found similar results, though quite a while ago [1]. gccgo didn't support escape analysis for quite a long time, which meant that the performance cost of the increased heap allocations absolutely dwarfed whatever performance gain you got from GCC's smarter optimizations. I think it's recently gained support for escape analysis—it's actually quite difficult to find information about this, and whether you need a compiler flag to enable it, etc.—but I don't think that's going to tip the performance scales in gccgo's favor. EDIT: See below: 8.1 ships on-by-default escape analysis! The primary motivations for gccgo, at least to my understanding, were a) having a second reference implementation that could find bugs in gc and the language specification, and b) support for esoteric platforms that will likely never make it into gc. The announcement of gccgo has more information about its motivation, though it makes some claims about performance that haven't stood the test of time [2]. [0]: https://groups.google.com/forum/#!msg/golang-nuts/mjTmIkWKZ6k/L840PrnAAAAJ https://groups.google.com/forum/#!msg/golang-nuts/mjTmIkWKZ6... [1]: https://dave.cheney.net/2013/11/19/benchmarking-go-1-2rc5-vs-gccgo https://dave.cheney.net/2013/11/19/benchmarking-go-1-2rc5-vs... [2]: https://blog.golang.org/gccgo-in-gcc-471 https://blog.golang.org/gccgo-in-gcc-471
  - tdrd 8y ago
    Author of [0] here. Sadly, those benchmarks (at the bottom of the thread) were done with a GCC that already included all the GCC 8.1 bells and whistles - results were unchanged under 8.1. So it's still _really_ slow.
  - pavanky 8y ago
    Looks like they solved those issues in 8.1 GCC 8 provides a complete implementation of the Go 1.10.1 user packages. The garbage collector is now fully concurrent. As before, values stored on the stack are scanned conservatively, but value stored in the heap are scanned precisely. Escape analysis is fully implemented and enabled by default in the Go frontend. This significantly reduces the number of heap allocations by allocating values on the stack instead.
    - smitherfield 8y ago
      "As before, values stored on the stack are scanned conservatively" Why would values on the stack be garbage-collected at all? Do they mean scanning the stack for live references?
      - gmueckl 8y ago
        I read this as "if it is on the stack and looks like a reference when you squint your eyes, then we treat it as a reference" compared to objects on the heap where the GC seems to know the exact location of all references.
        FullyFunctional 8y ago
        Right that's the standard conservative garbage collection. However, new results show that it's significantly worse than a precise collector (reference pending).
        BlackFingolfin 8y ago
        I'd love to see that reference, as I've not yet seen an example where this was true in practicd, but know several examples where it is definitely false (e.g. we use a modification of the Julia GC which uses consevative stack scanning to allow interop with another system, and it seems to perform very well).
DSingularity 8y ago
You didnt ask, but the main disadvantage is that they dont support new language constructs as fast as the standard Go compiler.
grapeli23 8y ago
Supports x86 processors without sse and mmx, example. https://en.wikipedia.org/wiki/Intel_Quark https://en.wikipedia.org/wiki/Intel_Quark The google go compiler only supports x86 from pentium pro.
- Phylter 8y ago
  I can see why this would be beneficial to a small number of people but I can't imagine a lot of people needing this feature. Isn't Intel Quark no longer supported or at least isn't a product line that Intel is giving much effort to?
apaprocki 8y ago
I use gccgo to bootstrap builds of the real Go releases.

I did not realise GCC supported Go until reading these release notes. What advantage/reason would I have for using GCC over the standard Go compiler?

by gchp 8y ago

I did not realise GCC supported Go until reading these release notes. What advantage/reason would I have for using GCC over the standard Go compiler?

gumby 8y ago

As Google has been paying Ian Taylor to write the GCC Go support since the very early days of Go I'd say you could consider GCC to also be a "standard" Go compiler.

pjmlp 8y ago

Performance, GCC does more optimization passes than the reference Go compiler. Supported platforms. Also it does have some extension pragmas and is easier to use for something like trying to use Go baremetal.

benesch 8y ago
Before you get too excited about possible performance wins, note that gccgo turns out to be much slower than gc (the standard Go compiler) on a lot of real workloads. Here's one such benchmark, taken recently, though it's admittedly a microbenchmark [0]. Dave Cheney found similar results, though quite a while ago [1]. gccgo didn't support escape analysis for quite a long time, which meant that the performance cost of the increased heap allocations absolutely dwarfed whatever performance gain you got from GCC's smarter optimizations. I think it's recently gained support for escape analysis—it's actually quite difficult to find information about this, and whether you need a compiler flag to enable it, etc.—but I don't think that's going to tip the performance scales in gccgo's favor. EDIT: See below: 8.1 ships on-by-default escape analysis! The primary motivations for gccgo, at least to my understanding, were a) having a second reference implementation that could find bugs in gc and the language specification, and b) support for esoteric platforms that will likely never make it into gc. The announcement of gccgo has more information about its motivation, though it makes some claims about performance that haven't stood the test of time [2]. [0]: https://groups.google.com/forum/#!msg/golang-nuts/mjTmIkWKZ6k/L840PrnAAAAJ https://groups.google.com/forum/#!msg/golang-nuts/mjTmIkWKZ6... [1]: https://dave.cheney.net/2013/11/19/benchmarking-go-1-2rc5-vs-gccgo https://dave.cheney.net/2013/11/19/benchmarking-go-1-2rc5-vs... [2]: https://blog.golang.org/gccgo-in-gcc-471 https://blog.golang.org/gccgo-in-gcc-471
- tdrd 8y ago
  Author of [0] here. Sadly, those benchmarks (at the bottom of the thread) were done with a GCC that already included all the GCC 8.1 bells and whistles - results were unchanged under 8.1. So it's still _really_ slow.
- pavanky 8y ago
  Looks like they solved those issues in 8.1 GCC 8 provides a complete implementation of the Go 1.10.1 user packages. The garbage collector is now fully concurrent. As before, values stored on the stack are scanned conservatively, but value stored in the heap are scanned precisely. Escape analysis is fully implemented and enabled by default in the Go frontend. This significantly reduces the number of heap allocations by allocating values on the stack instead.
  - smitherfield 8y ago
    "As before, values stored on the stack are scanned conservatively" Why would values on the stack be garbage-collected at all? Do they mean scanning the stack for live references?
    - gmueckl 8y ago
      I read this as "if it is on the stack and looks like a reference when you squint your eyes, then we treat it as a reference" compared to objects on the heap where the GC seems to know the exact location of all references.
      - FullyFunctional 8y ago
        Right that's the standard conservative garbage collection. However, new results show that it's significantly worse than a precise collector (reference pending).
        BlackFingolfin 8y ago
        I'd love to see that reference, as I've not yet seen an example where this was true in practicd, but know several examples where it is definitely false (e.g. we use a modification of the Julia GC which uses consevative stack scanning to allow interop with another system, and it seems to perform very well).

DSingularity 8y ago

You didnt ask, but the main disadvantage is that they dont support new language constructs as fast as the standard Go compiler.

grapeli23 8y ago

Supports x86 processors without sse and mmx, example. https://en.wikipedia.org/wiki/Intel_Quark https://en.wikipedia.org/wiki/Intel_Quark The google go compiler only supports x86 from pentium pro.

Phylter 8y ago
I can see why this would be beneficial to a small number of people but I can't imagine a lot of people needing this feature. Isn't Intel Quark no longer supported or at least isn't a product line that Intel is giving much effort to?

apaprocki 8y ago

I use gccgo to bootstrap builds of the real Go releases.