Hacker News Reader

Comment by anonymoushn | Hacker News Reader

Golang's compiler is not great. The main way to achieve acceptable performance in golang is to use their weird asm dialect.

View on HN

Somehow I can't find a source for this but it's well known that Go prefers compilation speed over runtime performance. Doesn't help that they implement the entire compiler stack themselves so it definitely misses optimisations that other compilers can already do.

Also, I've never heard of anyone using assembly for performance optimisations. It would never happen where Go in commonly used (server programming), maybe if you're doing graphics or something nonstandard?

I've done it for a c++ parser. I grabbed the compiled c++ and disassembled it into assembly, then reworked it. Got a massive increase in speed when I tweeked the registry use.

> Also, I've never heard of anyone using assembly for performance optimisations. It would never happen where Go in commonly used (server programming), maybe if you're doing graphics or something nonstandard?

It's in the standard library. It's also how you write parsers and formatters with acceptable performance if you don't have SIMD intrinsics.

As well as differences in code gen, as I understand it Go also has worse tail latencies than servers written in C/C++/Rust because of the GC.

In this context, they are not talking about GC but the compiler

Golang's compiler is so fast though that I can iterate much faster so I'm willing to accept slightly worse performance than C++. C++ I waste so much time just waiting (esp. if I'm using a lot of templatized header only libraries)

But by that logic ruby is faster still since the compile time is 0. Less than zero really because it can be modified in flight.

The trade offs between the two are huge.

Go programs compile in less than a second, or several seconds for huge projects, where idiomatic Go gets you within the same order of magnitude to that of C(++), with some memory overhead. Concurrency is first class, GC pauses exist but are seldom an issue.

Idiomatic Ruby runs several orders of magnitude slower, with a huge memory overhead, and is rife with runtime gymnastics. Concurrency is an expensive hack, with stop-the-world GC.

Only if the compilation speed difference is worth the loss of performance. That seems unlikely for most use cases because the speed gain is small while the performance loss is severe.

Not at all. The main way is to reduce pressure on the GC by reducing allocations, which is a fairly straightforward process thanks to good support from the tooling.

Past that, you either call out to C via FFI or give up and rewrite in C/C++/Rust. Nobody really bothers with the asm.

If this was 4 years ago I would say “fair enough” but now Go 1.21 ? This claim is no longer Valid, just like saying CGO is slow, just because one language uses LLVM or GCC doesn’t mean they have state of the compiler

Yeah it's not fair to put Go in the same bracket as fast langs tbh.

It's a lang to ship MVPs quickly without much thought & cheaper devs - not a high perf one.

Perhaps gcc-go is better?

gcc-go, gollvm there’s actually no difference in comparison to the go compiler, heck in some cases gcc-go perform worse, Go internals are built with a different mindset and architecture there’re certain features that’s can perform worse than just hard coded assembly

Reply on news.ycombinator.com