3 ms·

In addition, a lot of optimizations (like loop unrolling) are left on the table to preserve Go's fast compile times.

by icholy 4y ago

pjmlp 4y ago
Gccgo is the answer here.
- Patrickmi 4y ago
  Gccgo at its core may be fast but when it comes to how the go frontend interpret it to gcc ir that pales in comparison than just straight up optimizating the Go compiler There’ll more opportunities for more optimizations since they move to SSA ir since 1.5 and in turn compile time will definitely go down
59nadir 4y ago
I was surprised with the announcement that Go's standard compiler had register allocation for function arguments[0] added to it. This seemed like table stakes for a very long time but it really illustrated just how Go's compiler is much, much simpler than most in many areas. On one hand it makes you wonder how much could be squeezed out of Go and how many basic things they're still leaving out of the compiler. On the other it tells part of the story of why Go compiles fast with the backdrop that despite this lack of work by the compiler people use Go productively all day and deliver services they are happy with from a performance perspective. [0] - https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.17#compiler (2021-08)
- zimpenfish 4y ago
  I wonder if they'll ever switch to a "normal = fast compile, low optimisation; release = slow compile, high optimisation" model like Rust. Although I suppose other languages already have the "high optimisation" parts covered (rust, julia, python+numpy, etc.) which might make it a fool's errand.
- Mawr 4y ago
  It goes to show the impact of optimizing from top-down instead of bottom-up can have. Go was designed with performance in mind ("mechanical sympathy") as opposed to most other GC languages for which performance was an afterthought. If you get high-level language constructs right, you'll get great performance by default, even with a simple compiler: - structs instead of objects - value types - exposed pointers - straightforward allocation semantics Most compilers out there are busy fighting bad language designs. There's only so much a compiler can do when faced with fat objects hidden behind a spider web of pointers. So they have to do these microoptimizations to claw back at least some performance.

In addition, a lot of optimizations (like loop unrolling) are left on the table to preserve Go's fast compile times.

by icholy 4y ago

In addition, a lot of optimizations (like loop unrolling) are left on the table to preserve Go's fast compile times.

pjmlp 4y ago

Gccgo is the answer here.

Patrickmi 4y ago
Gccgo at its core may be fast but when it comes to how the go frontend interpret it to gcc ir that pales in comparison than just straight up optimizating the Go compiler There’ll more opportunities for more optimizations since they move to SSA ir since 1.5 and in turn compile time will definitely go down

59nadir 4y ago

I was surprised with the announcement that Go's standard compiler had register allocation for function arguments[0] added to it. This seemed like table stakes for a very long time but it really illustrated just how Go's compiler is much, much simpler than most in many areas. On one hand it makes you wonder how much could be squeezed out of Go and how many basic things they're still leaving out of the compiler. On the other it tells part of the story of why Go compiles fast with the backdrop that despite this lack of work by the compiler people use Go productively all day and deliver services they are happy with from a performance perspective. [0] - https://go.dev/doc/go1.17#compiler https://go.dev/doc/go1.17#compiler (2021-08)

zimpenfish 4y ago
I wonder if they'll ever switch to a "normal = fast compile, low optimisation; release = slow compile, high optimisation" model like Rust. Although I suppose other languages already have the "high optimisation" parts covered (rust, julia, python+numpy, etc.) which might make it a fool's errand.
Mawr 4y ago
It goes to show the impact of optimizing from top-down instead of bottom-up can have. Go was designed with performance in mind ("mechanical sympathy") as opposed to most other GC languages for which performance was an afterthought. If you get high-level language constructs right, you'll get great performance by default, even with a simple compiler: - structs instead of objects - value types - exposed pointers - straightforward allocation semantics Most compilers out there are busy fighting bad language designs. There's only so much a compiler can do when faced with fat objects hidden behind a spider web of pointers. So they have to do these microoptimizations to claw back at least some performance.