←back to thread

302 points Bogdanp | 3 comments | | HN request time: 0.604s | source
Show context
taylorallred ◴[] No.44390996[source]
So there's this guy you may have heard of called Ryan Fleury who makes the RAD debugger for Epic. The whole thing is made with 278k lines of C and is built as a unity build (all the code is included into one file that is compiled as a single translation unit). On a decent windows machine it takes 1.5 seconds to do a clean compile. This seems like a clear case-study that compilation can be incredibly fast and makes me wonder why other languages like Rust and Swift can't just do something similar to achieve similar speeds.
replies(18): >>44391046 #>>44391066 #>>44391100 #>>44391170 #>>44391214 #>>44391359 #>>44391671 #>>44391740 #>>44393057 #>>44393294 #>>44393629 #>>44394710 #>>44395044 #>>44395135 #>>44395226 #>>44395485 #>>44396044 #>>44401496 #
lordofgibbons ◴[] No.44391100[source]
The more your compiler does for you at build time, the longer it will take to build, it's that simple.

Go has sub-second build times even on massive code-bases. Why? because it doesn't do a lot at build time. It has a simple module system, (relatively) simple type system, and leaves a whole bunch of stuff be handled by the GC at runtime. It's great for its intended use case.

When you have things like macros, advanced type systems, and want robustness guarantees at build time.. then you have to pay for that.

replies(9): >>44391549 #>>44391582 #>>44391630 #>>44391910 #>>44394240 #>>44395833 #>>44397304 #>>44401934 #>>44402705 #
cogman10 ◴[] No.44391630[source]
Yes but I'd also add that Go specifically does not optimize well.

The compiler is optimized for compilation speed, not runtime performance. Generally speaking, it does well enough. Especially because it's usecase is often applications where "good enough" is good enough (IE, IO heavy applications).

You can see that with "gccgo". Slower to compile, faster to run.

replies(2): >>44392046 #>>44399907 #
1. cherryteastain ◴[] No.44392046[source]
Is gccgo really faster? Last time I looked it looked like it was abandoned (stuck at go 1.18, had no generics support) and was not really faster than the "actual" compiler.
replies(1): >>44393453 #
2. cogman10 ◴[] No.44393453[source]
Digging around, looks like it's workload dependent.

For pure computational workloads, it'll be faster. However, anything with heavy allocation will suffer as apparently the gccgo GC and GC related optimizations aren't as good as cgo's.

replies(1): >>44402614 #
3. haiku2077 ◴[] No.44402614[source]
As of about five years ago gccgo was slower for almost all workloads: https://meltware.com/2019/01/16/gccgo-benchmarks-2019.html