7 ms·

It's a bold strategy - let's see if it works out for them. But from what I remember, this still uses the LLVM backend, right? Sure, you can beat LLVM on compil

• measurablefunc 1y ago
  I don't really get the obsession w/ compiler performance. At the end of the day you are trading performance optimizations (inlining, dead code elimination, partial evaluation, etc) for compile times. If you want fast compile times then use a compiler w/ no optimization passes, done. The compile times are now linear w/ respect to lines of code & there is provably no further improvement you can make on that b/c any further passes will add linear or superlinear amount of overhead depending on the complexity of the optimization.
  • tom_ 1y ago
    But if those passes (or indeed any other step of the process) are inefficiently implemented, they could be improved. The compiler output would be the same, but now it would be produced more quickly, and the iteration time would be shorter.
  • dustbunny 1y ago
    Any delay between writing code and seeing the result is empty space in my mind where distractions can enter.
  • pfg_ 1y ago
    The reason to care about compile time is because it affects your iteration speed. You can iterate much faster on a program that takes 1 second to compile vs 1 minute. Time complexity may be O(lines), but a compiler can be faster or slower based on how long it takes. And for incremental updates, compilers can do significantly better than O(lines). In debug mode, zig uses llvm with no optimization passes. On linux x86_64, it uses its own native backend. This backend can be significantly faster to compile (2x or more) than llvm. Zig's own native backend is designed for incremental compilation. This means, after the initial build, there will be very little work that has to be done for the next emit. It needs to rebuild the affected function, potentially rebuild other functions which depend on it, and then directly update the one part of the output binary that changed. This will be significantly faster than O(n) for edits.
    • timschmidt 1y ago
      > The reason to care about compile time is because it affects your iteration speed. You can iterate much faster on a program that takes 1 second to compile vs 1 minute. Color me skeptical. I've only got 30 years of development under the belt, but even a 1 minute compile time is dwarfed by the time it takes to write and reason about code, run tests, work with version control, etc. Further, using Rust as an example, even a project which takes 5 minutes to build cold only takes a second or two on a hot build thanks to caching of already-built artifacts. Which leaves any compile time improvements to the very first time the project is cloned and built. Consequently, faster compile times would not alter my development practices, nor allow me to iterate any faster.
      • zdragnar 1y ago
        > Consequently, faster compile times would not alter my development practices, nor allow me to iterate any faster. I think the web frontend space is a really good case for fast compile times. It's gotten to the point that you can make a change, save a file, the code recompiles and is sent to the browser and hot-reloaded (no page refresh) and your changes just show up. The difference between this experience and my last time working with Ember, where we had long compile times and full page reloads, was incredibly stark. As you mentioned, the hot build with caching definitely does a lot of heavy lifting here, but in some environments, such as a CI server, having minutes long builds can get annoying as well. > Consequently, faster compile times would not alter my development practices, nor allow me to iterate any faster. Maybe, maybe not, but there's no denying that faster feels nicer.
        • timschmidt 1y ago
          > Maybe, maybe not, but there's no denying that faster feels nicer. Given finite developer time, spending it on improved optimization and code generation would have a much larger effect on my development. Even if builds took twice as long.
          • hu3 1y ago
  • deleted 1y ago
    [deleted]
  • ben-schaaf 1y ago
    clang -O0 is significantly slower than tcc. So the problem is clearly not (just) the optimisation passes.
  • rudedogg 1y ago
    > If you want fast compile times then use a compiler w/ no optimization passes, done. The compile times are now linear w/ respect to lines of code & there is provably no further improvement you can make on that b/c any further passes will add linear or superlinear amount of overhead depending on the complexity of the optimization. Umm this is completely wrong. Compiling involves a lot of stuff, and the language design, as well as compiler design can make or break them. Parsing is relatively easy to make fast and linear, but the other stuff (semantic analysis) is not. Hence why we have a huge range of compile times across programming languages that are (mostly) the same.
  • OtomotO 1y ago
    I think it highly depends on what you're doing. For some work I tend to take a pen and paper and think about a solution, before I write code. For these problems compile time isn't an issue. For UI work on the other hand, it's invaluable to have fast iteration cycles to nail the design, because it's such an artistic and creative activity
  • loeg 1y ago
    People are (reasonably) objecting to Clang's performance even in -O0. Still, it is a great platform for sophisticated optimizations and code analysis tools.
  • WD-42 1y ago
    When you are writing and thinking about code, you are making progress. You are building your mental model and increasing understanding. Compile time is often an excuse to check hacker news while you wait for the artifact to confirm your assumptions. Of course faster compile times are important, even if dwarfed relatively by writing the code. It’s not the same kind of time.
  • deleted 1y ago
    [deleted]
  • indymike 1y ago
    Faster compiler means developers can go faster.
• bsder 1y ago
  > but when it comes to emitting great assembly, it is almost unbeatable. "Proebsting's Law: Compiler Advances Double Computing Power Every 18 Years" The implication is that doing the easy, obvious and fast optimizations is Good Enough(tm). Even if LLVM is God Tier(tm) at optimizing, the cost for those optimizations swings against them very quickly.
• mitchellh 1y ago
  It only uses the LLVM backend for release builds. For debug builds Zig now defaults to self-hosted (on supported platforms, only x86_64 right now). Debug builds are directly in the hot path of testing your software (this includes building test binaries), and the number of iterations you do on a debug build are multiple orders of magnitude higher than release builds, so this is a good tradeoff.
  • brabel 1y ago
    The post says the llvm is used in all builds they measured since the self hosted backend still can’t compile ghostty.
    • deleted 1y ago
      [deleted]
    • dundarious 1y ago
      Incorrect, the last build is substantially faster and is using the "native" debug backend.