5 ms·

@AndyKelley I'm super curious what you think the main factors are that make languages like Zig super fast at compiling where languages like Rust and Swift are q

@AndyKelley I'm super curious what you think the main factors are that make languages like Zig super fast at compiling where languages like Rust and Swift are quite slow. What's the key difference?

AndyKelley 1y ago
Basically, not depending on LLVM or LLD. The above is only possible because we invested years into making our own x86_64 backend and our own linker. You can see all the people ridiculing this decision 2 years ago https://news.ycombinator.com/item?id=36529456 https://news.ycombinator.com/item?id=36529456
- unclad5968 1y ago
  LLVM isnt a good scapegoat. A C application equivalent in size to a rust or c++ application will compile an order of magnitude quicker and they all use LLVM. I'm not a compiler expert, but it doesn't seem right to me that the only possible path to quick compilation for Zig was a custom backend.
  - MobiusHorizons 1y ago
    Be that as it may, many C compilers are still an order of magnitude faster than LLVM. Probably the best example is tcc, although it is not the only one. C is a much simpler language than rust, so it is expected that compilation should take less time for C. That doesn’t mean llvm isn’t a significant contributor to compilation speed. I believe cranelift compilation of rust is also much faster than the llvm path
    - unclad5968 1y ago
      > That doesn’t mean llvm isn’t a significant contributor to compilation speed. That's not what I said. I said it's unlikely that fast compilation cannot be achieved while using LLVM which, I would argue, is proven by the existence of a fast compiler that uses LLVM.
  - int_19h 1y ago
    It will compile an order of magnitude quicker because it often doesn't do the same thing - e.g. functions that are aggressively inlined in C++ or Rust or Zig would be compiled separately and linked normally, and generally there's less equivalent of compile-time generics in C code (because you have to either spell out all the instantiations by hand or use preprocessor or a code generator to do something that is two lines of code in C++).
  - pjmlp 1y ago
    Not all do use LLVM.
- zozbot234 1y ago
  The Rust folks have cranelift and wild BTW. There are alternatives to LLVM and LLD, even though they might not be as obvious to most users.
- VeejayRampay 1y ago
  what is even the point of quoting reactions from two years ago? this is a terrible look for your whole community
  - elktown 1y ago
    Honestly I think it's good to highlight it. As a industry we're too hampered by "Don't even try that, use the existing thing" and it's causing these end results.
coolsunglasses 1y ago
I'm also curious because I've (recently) compiled more or less identical programs in Zig and Rust and they took the same amount of time to compile. I'm guessing people are just making Zig programs with less code and fewer dependencies and not really comparing apples to apples.
- kristoff_it 1y ago
  Zig is starting to migrate to custom backends for debug builds (instead of using LLVM) plus incremental compilation. All Zig code is built in a single compilation unit and everything is compiled from scratch every time you change something, including all dependencies and all the parts of the stdlib that you use in your project. So you've been comparing Zig rebuilds that do all the work every time with Rust rebuilds that cache all dependencies. Once incremental is fully released you will see instant rebuilds.
  - metaltyphoon 1y ago
    When does this land in Zig? Will aarch64 be supported?
    - mlugg 1y ago
      When targeting x86_64, the self-hosted backend is already enabled by default on the latest builds of Zig (when compiling in Debug mode). The self-hosted aarch64 backend currently isn't generally usable (so we still default to LLVM when targeting aarch64), but it's likely to be the next ISA we focus on codegen for.
      - metaltyphoon 1y ago
        I assume x86_64 is Linux only correct?
        AndyKelley 1y ago
        Not quite- any ELF or MachO target is enabled by default already. Windows is waiting on some COFF linker bug fixes.
steveklabnik 1y ago
I'm not Andrew, but Rust has made several language design decisions that make compiler performance difficult. Some aspects of compiler speed come down to that. One major difference is the way each project considers compiler performance: The Rust team has always cared to some degree about this. But, from my recollection of many RFCs, "how does this impact compiler performance" wasn't a first-class concern. And that also doesn't really speak to a lot of the features that were basically implemented before the RFC system existed. So while it's important, it's secondary to other things. And so while a bunch of hard-working people have put in a ton of work to improve performance, they also run up against these more fundamental limitations at the limit. Andrew has pretty clearly made compiler performance a first-class concern, and that's affected language design decisions. Naturally this leads to a very performant compiler.
- rtpg 1y ago
  > Rust has made several language design decisions that make compiler performance difficult Do you have a list off the top of your head/do you know of a decent list? I've now read many "compiler slow" thoughtpieces by many people and I have yet to see someone point at a specific feature and say "this is just intrinsically harder". I believe that it likely exists, but would be good to know what feature to get mad at! Half joking of course
  - Mawr 1y ago
    You can have your house built fast, cheap, or well. Pick two; or a bit of all three that adds up to the same effort required. You can't have all three. You can't have a language with 100% of the possible runtime perf, 100% of the possible compile speed and 100% of the possible programmer ease-of-use. At best you can abuse the law of diminishing returns aka the 80-20 rule, but that's not easy to balance and you run the risk of creating a language that's okay at everything, but without any strong selling points, like the stellar runtime performance Rust is known for. So a better way to think about it is: Given Rust's numerous benefits, is having subpar compilation time really that big of a deal?
    - 1y ago
AlienRobot 1y ago
One difference that Zig has is that it doesn't have multiline comments or multiline strings, meaning that the parser can parse any line correctly without context. I assume this makes parallelization trivial. There is ino operator overloading like C, so A + B can only mean one thing. You can't redeclare a variable, so foo can only map to one thing. The list goes on. Basically it was designed to compile faster, and that means many issues on Github have been getting rejected in order to keep it that way. It's full of compromises.

@AndyKelley I'm super curious what you think the main factors are that make languages like Zig super fast at compiling where languages like Rust and Swift are quite slow. What's the key difference?

AndyKelley 1y ago

Basically, not depending on LLVM or LLD. The above is only possible because we invested years into making our own x86_64 backend and our own linker. You can see all the people ridiculing this decision 2 years ago https://news.ycombinator.com/item?id=36529456 https://news.ycombinator.com/item?id=36529456

unclad5968 1y ago
LLVM isnt a good scapegoat. A C application equivalent in size to a rust or c++ application will compile an order of magnitude quicker and they all use LLVM. I'm not a compiler expert, but it doesn't seem right to me that the only possible path to quick compilation for Zig was a custom backend.
- MobiusHorizons 1y ago
  Be that as it may, many C compilers are still an order of magnitude faster than LLVM. Probably the best example is tcc, although it is not the only one. C is a much simpler language than rust, so it is expected that compilation should take less time for C. That doesn’t mean llvm isn’t a significant contributor to compilation speed. I believe cranelift compilation of rust is also much faster than the llvm path
  - unclad5968 1y ago
    > That doesn’t mean llvm isn’t a significant contributor to compilation speed. That's not what I said. I said it's unlikely that fast compilation cannot be achieved while using LLVM which, I would argue, is proven by the existence of a fast compiler that uses LLVM.
- int_19h 1y ago
  It will compile an order of magnitude quicker because it often doesn't do the same thing - e.g. functions that are aggressively inlined in C++ or Rust or Zig would be compiled separately and linked normally, and generally there's less equivalent of compile-time generics in C code (because you have to either spell out all the instantiations by hand or use preprocessor or a code generator to do something that is two lines of code in C++).
- pjmlp 1y ago
  Not all do use LLVM.
zozbot234 1y ago
The Rust folks have cranelift and wild BTW. There are alternatives to LLVM and LLD, even though they might not be as obvious to most users.
VeejayRampay 1y ago
what is even the point of quoting reactions from two years ago? this is a terrible look for your whole community
- elktown 1y ago
  Honestly I think it's good to highlight it. As a industry we're too hampered by "Don't even try that, use the existing thing" and it's causing these end results.

coolsunglasses 1y ago

I'm also curious because I've (recently) compiled more or less identical programs in Zig and Rust and they took the same amount of time to compile. I'm guessing people are just making Zig programs with less code and fewer dependencies and not really comparing apples to apples.

kristoff_it 1y ago
Zig is starting to migrate to custom backends for debug builds (instead of using LLVM) plus incremental compilation. All Zig code is built in a single compilation unit and everything is compiled from scratch every time you change something, including all dependencies and all the parts of the stdlib that you use in your project. So you've been comparing Zig rebuilds that do all the work every time with Rust rebuilds that cache all dependencies. Once incremental is fully released you will see instant rebuilds.
- metaltyphoon 1y ago
  When does this land in Zig? Will aarch64 be supported?
  - mlugg 1y ago
    When targeting x86_64, the self-hosted backend is already enabled by default on the latest builds of Zig (when compiling in Debug mode). The self-hosted aarch64 backend currently isn't generally usable (so we still default to LLVM when targeting aarch64), but it's likely to be the next ISA we focus on codegen for.
    - metaltyphoon 1y ago
      I assume x86_64 is Linux only correct?
      - AndyKelley 1y ago
        Not quite- any ELF or MachO target is enabled by default already. Windows is waiting on some COFF linker bug fixes.

steveklabnik 1y ago

I'm not Andrew, but Rust has made several language design decisions that make compiler performance difficult. Some aspects of compiler speed come down to that. One major difference is the way each project considers compiler performance: The Rust team has always cared to some degree about this. But, from my recollection of many RFCs, "how does this impact compiler performance" wasn't a first-class concern. And that also doesn't really speak to a lot of the features that were basically implemented before the RFC system existed. So while it's important, it's secondary to other things. And so while a bunch of hard-working people have put in a ton of work to improve performance, they also run up against these more fundamental limitations at the limit. Andrew has pretty clearly made compiler performance a first-class concern, and that's affected language design decisions. Naturally this leads to a very performant compiler.

rtpg 1y ago
> Rust has made several language design decisions that make compiler performance difficult Do you have a list off the top of your head/do you know of a decent list? I've now read many "compiler slow" thoughtpieces by many people and I have yet to see someone point at a specific feature and say "this is just intrinsically harder". I believe that it likely exists, but would be good to know what feature to get mad at! Half joking of course
- Mawr 1y ago
  You can have your house built fast, cheap, or well. Pick two; or a bit of all three that adds up to the same effort required. You can't have all three. You can't have a language with 100% of the possible runtime perf, 100% of the possible compile speed and 100% of the possible programmer ease-of-use. At best you can abuse the law of diminishing returns aka the 80-20 rule, but that's not easy to balance and you run the risk of creating a language that's okay at everything, but without any strong selling points, like the stellar runtime performance Rust is known for. So a better way to think about it is: Given Rust's numerous benefits, is having subpar compilation time really that big of a deal?
  - 1y ago

AlienRobot 1y ago

One difference that Zig has is that it doesn't have multiline comments or multiline strings, meaning that the parser can parse any line correctly without context. I assume this makes parallelization trivial. There is ino operator overloading like C, so A + B can only mean one thing. You can't redeclare a variable, so foo can only map to one thing. The list goes on. Basically it was designed to compile faster, and that means many issues on Github have been getting rejected in order to keep it that way. It's full of compromises.