←back to thread

302 points Bogdanp | 1 comments | | HN request time: 0.207s | 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 #
duped ◴[] No.44391582[source]
I think this is mostly a myth. If you look at Rust compiler benchmarks, while typechecking isn't _free_ it's also not the bottleneck.

A big reason that amalgamation builds of C and C++ can absolutely fly is because they aren't reparsing headers and generating exactly one object file so the linker has no work to do.

Once you add static linking to the toolchain (in all of its forms) things get really fucking slow.

Codegen is also a problem. Rust tends to generate a lot more code than C or C++, so while the compiler is done doing most of its typechecking work, the backend and assembler has a lot of things to chuck through.

replies(6): >>44392553 #>>44392826 #>>44394891 #>>44396127 #>>44396258 #>>44396355 #
fingerlocks ◴[] No.44392826[source]
The swift compiler is definitely bottle necked by type checking. For example, as a language requirement, generic types are left more or less in-tact after compilation. They are type checked independent of what is happening. This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.

This has tradeoffs: increased ABI stability at the cost of longer compile times.

replies(3): >>44393659 #>>44394911 #>>44397467 #
1. windward ◴[] No.44394911[source]
>This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.

Even this can lead to unworkable compile times, to the point that code is rewritten.