2 ms·
> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads. This is a huge limitation of C'
by gf000 9mo ago
> The example you gave of a compiler is canonically implemented as multiple process making .o files from .c files, not threads.
This is a huge limitation of C's compilation model, and basically every other language since then does it differently, so not sure if that's a good example. You do want some "interconnection" between translation units, or at least less fine-grained units.
- groundzeros2015 9mo agoAnd yet despite that theoretical limit C compiles faster than any other language. Even C++ is very fast if you are not using header-only style. What’s better? Rust? Haskell? Swift? It’s very hard to do multithreading at a more granular level without hitting amdahl’s law and synchronization traps.
- pjmlp 9mo agoNo it doesn't, try it against a language with modules support, even the oldie Turbo Pascal for MS-DOS.
- groundzeros2015 9mo agoTurbo pascal compiles faster because of better parallelization?
- gf000 9mo agoIt reminds me of the joke that "I can do math very fast", probed with a multiplication and immediately answering some total bollocks answer. - "That's not even close" - "Yeah, but it was fast" Sure, it's not a trivial problem, but why wouldn't we want better compilation results/developer ergonomics at the price of more compiler complexity and some minimal performance penalty? And it's not like the performance doesn't have its own set of negatives, like header-only libraries are a hack directly manifested from this compilation model.
- groundzeros2015 9mo agoyour topic is shifting from multi-threading benefits in language compilation, to ergonomics of C headers.