5 ms·
Golang's compiler is not great. The main way to achieve acceptable performance in golang is to use their weird asm dialect.
by anonymoushn 3y ago
Golang's compiler is not great. The main way to achieve acceptable performance in golang is to use their weird asm dialect.
- umvi 3y agoGolang'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)
- john_the_writer 3y agoBut by that logic ruby is faster still since the compile time is 0. Less than zero really because it can be modified in flight.
- fredrikholm 3y agoThe 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.
- Mawr 3y agoOnly 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.
- Kiuhrly1 3y agoSomehow 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?
- john_the_writer 3y agoI'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.
- anonymoushn 3y ago> 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.
- anta40 3y agoPerhaps gcc-go is better?
- Patrickmi 3y agogcc-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
- josephg 3y agoAs 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.
- Patrickmi 3y agoIn this context, they are not talking about GC but the compiler
- intelVISA 3y agoYeah 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.
- Patrickmi 3y agoIf 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
- Mawr 3y agoNot 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.