6 ms·

Fast Compilers for Fast Programs

73 points by pplonski86 7y ago

sandreas 7y ago
This is a really interesting point of view... i don't think that there is a VALID possibility to determine always matching example projects, neither i think, a COMPILER should collect statistical data over time (what, if i lose this data?), but i like the approach. Perhaps it should be a tool, that can be executed on git repositories for existing projects and plot a compile time graph to identify fishy commits... sounds interesting though.
- tracker1 7y ago
  Man, I sometimes feel old seeing these kinds of complaints... and I do appreciate it. When I start certain kinds of projects with an interactive build/rebuild the first pass is S-L-O-W but interactive changes are instant (ie: node/webpack). In rust for a hello world rocket app (just learning rust), it's 0.17s for debug build, 0.18s for production. I have no real frame of reference other than OMG it's so tiny (executable and running in-memory). I'm also starting to work with ARM/Pi devices so Rust is making a lot more sense for that space.
abeppu 7y ago
This person wants compilers to be interactively fast and believes that the outcome will be developers empowered to create fast programs. But I think the key set up during the intro is assuming that a) the compiler runs your tests and b) that test performance is a good proxy for real performance. The counterexample to this in my daily life is working with an IDE that does a pretty good job of interactively invoking the complier as I change code. However, my tests aren't invoked with each compile pass, and the work they do doesn't look like a long running live service, or a giant spark job, or whatever. They're mostly aimed at checking correctness, and spend at least as much time creating and checking values as invoking my real code. If my real program is going to use many threads, do a lot of io and waiting for other services to respond, or decompress and deserialize big chunks of data, it's hard to see how a very fast local test ever could be a close proxy for that performance.
- openfuture 7y ago
  If you want your tests to run on compile time then what you want is static typing.
  - bluGill 7y ago
    Static types are very useful, but they do not catch all problems.
    - mring33621 7y ago
      But they catch many more problems than dynamic typing.
      - fao_ 7y ago
        That's a bit of a domain error. Nobody said that static types don't catch problems, and nobody brought up dynamic typing (until you). The parent poster tried to make a false equivalence between proper tests, and static typing. The former is a category that includes the latter.
- erik_seaberg 7y ago
  This. Integration and load tests do so much work that the compiler is lost in the noise. Running forty (hopefully) concurrent requests through a 200 OPS service does not tell me whether it's going to make prod flaky or more expensive.
shereadsthenews 7y ago
The focus on Go compiler speed is kinda weird to me. Other languages sometimes offer flexible tradeoffs to developers. You can build and test C++ programs fairly quickly if all the optimizations are disabled, or you can spend a long time building a release binary with optimization, load-testing, profile-guided recompilation, link-time optimization, and post-link optimization. But Go only offers the first thing: a fast compiler with almost no optimizations.
- sagichmal 7y ago
  The Go compiler contains lots of optimizations, especially considering its age.
  - limxto0 7y ago
    Can you share some more details about what those optimizations are? Can you point us to a link?
    - foldr 7y ago
      https://quasilyte.dev/blog/post/go_ssa_rules/ https://quasilyte.dev/blog/post/go_ssa_rules/ is maybe a good starting point.
    - __HYde 7y ago
      You could try compiling with and without `-gcflags '-N -l'` `-N` disables optimization and `-l` disables in-lining. I also found this[0] page which lists some optimizations done by the compiler. [0] https://github.com/golang/go/wiki/CompilerOptimizations https://github.com/golang/go/wiki/CompilerOptimizations edit: You can see what the compiler emits as assembly code with `-gcflags '-S'` so you can compare the optimized vs unoptimized assembly.
  - The_rationalist 7y ago
    go is indeed slow, cd benchmarkgames website
- bluGill 7y ago
erik_seaberg 7y ago
> The stuttering command line is a subtle UX poke, hey, you just ruined a nice program. Isn't this subtle discouragement from adding powerful features if there's no way to make them super fast? I want to automate everything I can. It's really hard to make a computer slower than doing it myself; I'm made of meat.
- setr 7y ago
  I think he’s suggesting that the tradeoff is larger than compile-time/performance; there are certain compile-time barriers that should be accounted for. Eg such powerful features that would cross the barrier may well only be placed after the barrier (eg -o2) So then you have gc++ with minimal optimizations doesn’t sit at behind the minimal barrier (instantaneous-feeling, whatever 200ms or so), while go does its best too (perhaps the counterargument being that it doesnt offer much for when you want to target barriers 2 and 3 instead of the minimal.
nickpsecurity 7y ago
This author either doesn’t know about Niklaus Wirth or forgot to mention him. Wirth’s main metric for assessing language complexity was how fast the compiler compiles in general and compiles itself. He ditched anything that slowed that down. The resulting compilers could never be as fast as C/C++. However, Oberon-2’s fast development pace with safe code was a major inspiration for Go. If anything, Wirth’s legacy went mainstream when someone finally did something non-academic with it. Author makes another mistake which is widespread: that fast-moving teams need languages with fast compilers. Sort of a half-truth. The alternative I push is a combo of REPL or fast compiler with ultra-optimizing compiler. Most of the iteration happens with the fast one. Everything that seems kind of finished gets compiled in background or on build server with more optimization, followed by lots of testing. It gets integrated into the new, compile-quick builds. Plenty of caching and parallelization in build system, too. See Section 2 in the pdf: https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806
- vidarh 7y ago
  > Wirth’s main metric for assessing language complexity was how fast the compiler compiles in general and compiles itself. He ditched anything that slowed that down. Indeed, one of the old stories about the Oberon compiler (I can't vouch for how strictly he stuck to it) is that optimizations had to "pay for themselves": Once recompiled with the optimization, the compiler needed to compile itself as fast as before the optimization was added. At least one of his thesis students did write papers on applying other optimizations that had no hope of making it into the standard Oberon compiler for that reason. I believe it was either Michael Brandeis PhD thesis or one of his other papers. But even though his optimization pass was "too costly" it was impressive how small it was given it also beat contemporary versions of gcc in terms of resulting performance. > https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 I love diving into old HN threads... Especially seeing my own comments on the top of the page. Less so to have my slow pace on my personal compiler project highlighted on them (apparently a GC was the next step for my Ruby compiler back in 2017 - it's just now sitting in a working state in my home directory; not yet committed). It's definitively not as fast as a Wirth compiler - in large part due to the sheer volume of small objects created. As much as I love to work with Ruby, as a fan of Wirth's work it also makes me want to bang my head through a wall...
pjc50 7y ago
No indication of how large these programs are ... It would be amazing to have a compiler respond in 0.3s. I don't think I've ever experienced that. I've had scripting languages take longer to spin up. My current work test suite takes twenty minutes. I've had C++ programs take over ten minutes just in the linker.
- runevault 7y ago
  We'll see if it holds up in the real world but Jon Blow has been working to keep Jai compiles on his game in it (I think it's at like 80k lines of code? might have that number wrong) under a half second, mind you that's not an optimized build, though you can run it through LLVM at a slower pace.
- Roboprog 7y ago
  I remember back in the early 90s having a copy of both Borland packages Pascal and C++ for Windows (3.x). They had similar demo programs. I compared one of them (forgot which) The C++ demo would build in 5 minutes on my machine. The [Object] Pascal demo would build in 5 seconds. The C++ package got shipped back. Ain’t nobody got time for that.
- shakna 7y ago
  tcc [0] confines you to an older subset of C, and I don't believe it's still under serious development, but it is fast. Fast enough you can use it like a scripting language for most use cases. [0] https://bellard.org/tcc/ https://bellard.org/tcc/
  - flukus 7y ago
    I find GCC compile times to be unnoticeable and perfectly usable as a scripting language, certainly competitive with the startup time of many scripting languages. By the time you're getting to noticable compile times your well into "this should be a proper project" territory, but everything from small scripts to simple GUI programs compile quickly. I wrote my own shebang scripts but there's a more full featured implementation here: https://github.com/RhysU/c99sh https://github.com/RhysU/c99sh
walshemj 7y ago
I am probably going to get downvoted to hell here but have we lost sight of making haste slowly here. Id rather people spent time making compilers better than just faster.
averros 7y ago
If compiler speed is your problem, then you're not doing development right. Tweaking the code until it produces something which looks right (and/or passes the tests) as the primary means of achieving correct operation is guaranteed to produce poor quality code. The only way to produce correct and reliable code is to do that by design and deliberation. Tests merely check a tiny part of the input vector space; they are safety against brain farts and gross errors. If you build code carefully, you spend most of the time thinking and compilation is something which happens not too often. Having a slow compiler teaches to be careful; rapid-fire hack-compile-test-fix-compile-test-fix cycle positively encourages sloppiness. Another reason why compilation can be slow is simple bloat, indicative of poor architecture or poor design or use of inappropriate tools. If you need to write 200 KLOC and most of that code is variations on the same theme, you needed to start by finding or designing a DSL which takes the repetitiveness out or doing some other form of meta-programming.

73 points by pplonski86 7y ago

This is a really interesting point of view... i don't think that there is a VALID possibility to determine always matching example projects, neither i think, a COMPILER should collect statistical data over time (what, if i lose this data?), but i like the approach. Perhaps it should be a tool, that can be executed on git repositories for existing projects and plot a compile time graph to identify fishy commits... sounds interesting though.

tracker1 7y ago
Man, I sometimes feel old seeing these kinds of complaints... and I do appreciate it. When I start certain kinds of projects with an interactive build/rebuild the first pass is S-L-O-W but interactive changes are instant (ie: node/webpack). In rust for a hello world rocket app (just learning rust), it's 0.17s for debug build, 0.18s for production. I have no real frame of reference other than OMG it's so tiny (executable and running in-memory). I'm also starting to work with ARM/Pi devices so Rust is making a lot more sense for that space.

abeppu 7y ago

This person wants compilers to be interactively fast and believes that the outcome will be developers empowered to create fast programs. But I think the key set up during the intro is assuming that a) the compiler runs your tests and b) that test performance is a good proxy for real performance. The counterexample to this in my daily life is working with an IDE that does a pretty good job of interactively invoking the complier as I change code. However, my tests aren't invoked with each compile pass, and the work they do doesn't look like a long running live service, or a giant spark job, or whatever. They're mostly aimed at checking correctness, and spend at least as much time creating and checking values as invoking my real code. If my real program is going to use many threads, do a lot of io and waiting for other services to respond, or decompress and deserialize big chunks of data, it's hard to see how a very fast local test ever could be a close proxy for that performance.

openfuture 7y ago
If you want your tests to run on compile time then what you want is static typing.
- bluGill 7y ago
  Static types are very useful, but they do not catch all problems.
  - mring33621 7y ago
    But they catch many more problems than dynamic typing.
    - fao_ 7y ago
      That's a bit of a domain error. Nobody said that static types don't catch problems, and nobody brought up dynamic typing (until you). The parent poster tried to make a false equivalence between proper tests, and static typing. The former is a category that includes the latter.
erik_seaberg 7y ago
This. Integration and load tests do so much work that the compiler is lost in the noise. Running forty (hopefully) concurrent requests through a 200 OPS service does not tell me whether it's going to make prod flaky or more expensive.

shereadsthenews 7y ago

The focus on Go compiler speed is kinda weird to me. Other languages sometimes offer flexible tradeoffs to developers. You can build and test C++ programs fairly quickly if all the optimizations are disabled, or you can spend a long time building a release binary with optimization, load-testing, profile-guided recompilation, link-time optimization, and post-link optimization. But Go only offers the first thing: a fast compiler with almost no optimizations.

sagichmal 7y ago
The Go compiler contains lots of optimizations, especially considering its age.
- limxto0 7y ago
  Can you share some more details about what those optimizations are? Can you point us to a link?
  - foldr 7y ago
    https://quasilyte.dev/blog/post/go_ssa_rules/ https://quasilyte.dev/blog/post/go_ssa_rules/ is maybe a good starting point.
  - __HYde 7y ago
    You could try compiling with and without `-gcflags '-N -l'` `-N` disables optimization and `-l` disables in-lining. I also found this[0] page which lists some optimizations done by the compiler. [0] https://github.com/golang/go/wiki/CompilerOptimizations https://github.com/golang/go/wiki/CompilerOptimizations edit: You can see what the compiler emits as assembly code with `-gcflags '-S'` so you can compare the optimized vs unoptimized assembly.
- The_rationalist 7y ago
  go is indeed slow, cd benchmarkgames website
bluGill 7y ago

erik_seaberg 7y ago

> The stuttering command line is a subtle UX poke, hey, you just ruined a nice program. Isn't this subtle discouragement from adding powerful features if there's no way to make them super fast? I want to automate everything I can. It's really hard to make a computer slower than doing it myself; I'm made of meat.

setr 7y ago
I think he’s suggesting that the tradeoff is larger than compile-time/performance; there are certain compile-time barriers that should be accounted for. Eg such powerful features that would cross the barrier may well only be placed after the barrier (eg -o2) So then you have gc++ with minimal optimizations doesn’t sit at behind the minimal barrier (instantaneous-feeling, whatever 200ms or so), while go does its best too (perhaps the counterargument being that it doesnt offer much for when you want to target barriers 2 and 3 instead of the minimal.

nickpsecurity 7y ago

This author either doesn’t know about Niklaus Wirth or forgot to mention him. Wirth’s main metric for assessing language complexity was how fast the compiler compiles in general and compiles itself. He ditched anything that slowed that down. The resulting compilers could never be as fast as C/C++. However, Oberon-2’s fast development pace with safe code was a major inspiration for Go. If anything, Wirth’s legacy went mainstream when someone finally did something non-academic with it. Author makes another mistake which is widespread: that fast-moving teams need languages with fast compilers. Sort of a half-truth. The alternative I push is a combo of REPL or fast compiler with ultra-optimizing compiler. Most of the iteration happens with the fast one. Everything that seems kind of finished gets compiled in background or on build server with more optimization, followed by lots of testing. It gets integrated into the new, compile-quick builds. Plenty of caching and parallelization in build system, too. See Section 2 in the pdf: https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806

vidarh 7y ago
> Wirth’s main metric for assessing language complexity was how fast the compiler compiles in general and compiles itself. He ditched anything that slowed that down. Indeed, one of the old stories about the Oberon compiler (I can't vouch for how strictly he stuck to it) is that optimizations had to "pay for themselves": Once recompiled with the optimization, the compiler needed to compile itself as fast as before the optimization was added. At least one of his thesis students did write papers on applying other optimizations that had no hope of making it into the standard Oberon compiler for that reason. I believe it was either Michael Brandeis PhD thesis or one of his other papers. But even though his optimization pass was "too costly" it was impressive how small it was given it also beat contemporary versions of gcc in terms of resulting performance. > https://news.ycombinator.com/item?id=15704806 https://news.ycombinator.com/item?id=15704806 I love diving into old HN threads... Especially seeing my own comments on the top of the page. Less so to have my slow pace on my personal compiler project highlighted on them (apparently a GC was the next step for my Ruby compiler back in 2017 - it's just now sitting in a working state in my home directory; not yet committed). It's definitively not as fast as a Wirth compiler - in large part due to the sheer volume of small objects created. As much as I love to work with Ruby, as a fan of Wirth's work it also makes me want to bang my head through a wall...

pjc50 7y ago

No indication of how large these programs are ... It would be amazing to have a compiler respond in 0.3s. I don't think I've ever experienced that. I've had scripting languages take longer to spin up. My current work test suite takes twenty minutes. I've had C++ programs take over ten minutes just in the linker.

runevault 7y ago
We'll see if it holds up in the real world but Jon Blow has been working to keep Jai compiles on his game in it (I think it's at like 80k lines of code? might have that number wrong) under a half second, mind you that's not an optimized build, though you can run it through LLVM at a slower pace.
Roboprog 7y ago
I remember back in the early 90s having a copy of both Borland packages Pascal and C++ for Windows (3.x). They had similar demo programs. I compared one of them (forgot which) The C++ demo would build in 5 minutes on my machine. The [Object] Pascal demo would build in 5 seconds. The C++ package got shipped back. Ain’t nobody got time for that.
shakna 7y ago
tcc [0] confines you to an older subset of C, and I don't believe it's still under serious development, but it is fast. Fast enough you can use it like a scripting language for most use cases. [0] https://bellard.org/tcc/ https://bellard.org/tcc/
- flukus 7y ago
  I find GCC compile times to be unnoticeable and perfectly usable as a scripting language, certainly competitive with the startup time of many scripting languages. By the time you're getting to noticable compile times your well into "this should be a proper project" territory, but everything from small scripts to simple GUI programs compile quickly. I wrote my own shebang scripts but there's a more full featured implementation here: https://github.com/RhysU/c99sh https://github.com/RhysU/c99sh

walshemj 7y ago

I am probably going to get downvoted to hell here but have we lost sight of making haste slowly here. Id rather people spent time making compilers better than just faster.

averros 7y ago

If compiler speed is your problem, then you're not doing development right. Tweaking the code until it produces something which looks right (and/or passes the tests) as the primary means of achieving correct operation is guaranteed to produce poor quality code. The only way to produce correct and reliable code is to do that by design and deliberation. Tests merely check a tiny part of the input vector space; they are safety against brain farts and gross errors. If you build code carefully, you spend most of the time thinking and compilation is something which happens not too often. Having a slow compiler teaches to be careful; rapid-fire hack-compile-test-fix-compile-test-fix cycle positively encourages sloppiness. Another reason why compilation can be slow is simple bloat, indicative of poor architecture or poor design or use of inappropriate tools. If you need to write 200 KLOC and most of that code is variations on the same theme, you needed to start by finding or designing a DSL which takes the repetitiveness out or doing some other form of meta-programming.