6 ms·

As for this fragment: > Zig is faster than C. This is partly a result of Andrew’s data-oriented design approach that led to performance-enhancing changes in Zi

As for this fragment: > Zig is faster than C. This is partly a result of Andrew’s data-oriented design approach that led to performance-enhancing changes in Zig programming that would not be possible in other languages. Can anyone comment on this claim? It's quite bold given that the competition usually aims to get close to the speed of C; getting faster would be an amazing feat regardless of syntax used.

ncmncm 4y ago
C performance is no great shakes anymore. C++ and Rust routinely exceed it. Java and Javascript, even, sometimes. People still compare to C because (1) it is easier to beat, (2) you are less likely to be accused of cooking the comparison by coding the reference badly, and (3) you don't provoke the question, "why not just code in that, then?"
jstimpfle 4y ago
The article is quite weak IMO and mixes up a few things. For example, there isn't really a "global allocator" built into the C language. In the case of your quote, this is a misunderstanding on the performance optimizations that were done on the Zig compiler itself (it compiles faster). But that makes no difference to the performance of the compiled program. And the techniques that were mentioned can be used in the implementation of any other compiler as well.
stephc_int13 4y ago
In this case, I think this is poorly written. Andrew was talking about the Zig compiler and the data-oriented approach he used, leading to better compile speed. About the speed of the generated code, I have not seen many benchmarks, but I expect to see minimal differences with C. With better semantics around pointer aliasing and parallel-friendly loops they could produce faster machine code than C, but likely not by a huge margin.
andrepd 4y ago
If "faster than C" means "I can make a Zig program such that no equivalent C program is faster", then that's obviously false. If it means "some idiomatic Zig program is faster than the equivalent idiomatic C", it might be true.
- kaba0 4y ago
  > “I can make a Zig program such that no equivalent C program is faster", then that's obviously false Why would it be obviously false? C is not that low-level of a language, for example it has no native way of doing SIMD - so Rust, C++ (and I guess Zig as well?) all have programs that are simply non-expressible in C (inline assembly is not C) and are possibly orders of magnitude faster. But there are million other things “hard-coded” into C where with more control faster execution could be achieved - e.g. one might want to have better control over stack usage.
- littlestymaar 4y ago
  > If "faster than C" means "I can make a Zig program such that no equivalent C program is faster", then that's obviously false. It could be true though, because compilers aren't perfect, and for instance it actually happens with scientific code written in Fortran: C has restrict but because it's not widely used, C compilers don't make use of it as much as they could for optimization, which means that a language like Fortran that values the non-aliasing guarantee can have a compiler which optimizes it more than what C compilers do. That being said, there's nothing preventing C compilers to add the same level of aliasing-based optimizations in theory, it's just that they don't do it yet in practice (Rust is pushing the boundaries on that for LLVM though, because noalias optimizations is regarded as a promising performance enhancement for Rust).
- notacoward 4y ago
  That is a good point, but I think "idiomatic" here deserves some elaboration. Often people use it in very vague way: this is what (outspoken) programmers agree is the best way to do this thing. In this case, I think a more limited and specific definition is sufficient: don't use escape hatches. Don't use "unsafe" or compiler-specific extensions or inline assembly or libraries that were actually written in assembly. What can you do in the language as it comes out of the box, as every tutorial would lead you to do? I think Zig could indeed be "faster than C" in this sense, as others have pointed out Fortran can be, but Rust might not be able to. There's also an important lesson here about optimization BTW. Everyone thinks of optimizing algorithms in terms of big-O stuff, and that's great, but sometimes data size or layout or frequency of pointer-chasing or mispredicted branches can actually be the real difference makers. Cache-friendly vs. cache-hostile code can be particularly hard to spot, because it often doesn't show up even in most kinds of profiling. It presents only as a sort of general performance degradation across the board unless you're specifically looking for it. I've implemented significant performance gains just by rearranging code and scheduling to make better use of a processor's L1 I-cache. The gains to be had from doing the same for data in L2 and L3 caches are even greater. I appreciate that Zig is being designed with these issues in mind, because it seems like a lot of other newer languages are being designed with the specific goal of defeating modern computers' performance-enhancement techniques.
sekao 4y ago
Andrew argues that zig can produce faster programs than c or rust towards the end of the video: https://youtu.be/gn3YsZ6HUHw?t=3566 https://youtu.be/gn3YsZ6HUHw?t=3566
lucozade 4y ago
I'm guessing that the author is just confusing multiple things. Andrew has been using data oriented approaches to make the self hosted compiler fast. And the article mentions an example where he's separated (presumably arrays of) tagged unions into distinct arrays of tags and payloads. Depending on the access pattern, this can definitely speed things up on modern CPUs. The article then goes on to say that this is impossible in Rust, which is probably a fair statement. You may be able to get something quite close with really horrible, unsafe code but no sane person would try. But it's blatantly untrue that you can't do this in C. I mean, C doesn't even have tagged unions so you need to code the tags explicitly if you want them. Separating them into a different array is trivial. I guess it's possible that one could argue, say, Turing idiomatic Zig into highly optimised Zig is easier than the equivalent in C so, in practice, equivalent code is faster. Or some such. I have no idea if anyone's actually shown that quantitively though.
- LegionMammal978 4y ago
  > The article then goes on to say that this is impossible in Rust, which is probably a fair statement. You may be able to get something quite close with really horrible, unsafe code but no sane person would try. As it happens, a crate was just released that does exactly this, using a derive macro [0]. (I wouldn't recommend using it quite yet, though; it still has a few kinks to be worked out.) [0] https://crates.io/crates/peapod https://crates.io/crates/peapod
  - pcwalton 4y ago
    Yeah, in general macros allow for Rust to do these things just fine. I wouldn't say that it's a fair statement at all.
flohofwoe 4y ago
The data oriented design stuff was mostly in the new compiler implementation (which can lead to faster compilation, but is unrelated to the performance of the compiler output). But Zig might have some features which might theoretically allow the compiler to generate slightly more performant code (compared to portable standard C code). E.g. since function arguments are read only, the compiler might be able to avoid a copy on the stack when passing structs > 16 bytes by value. Also since Zig programs are (AFAIK) generally compiled as a unity build, the compiler has more inlining opportunities compared to a conventionally linked C program (without LTO). Etc... etc.. so theoretically it might be possible, but I'd still take such statements with a grain of salt until demonstrated on real world code.
Ygg2 4y ago
See https://m.youtube.com/watch?t=3566&v=gn3YsZ6HUHw https://m.youtube.com/watch?t=3566&v=gn3YsZ6HUHw Transcript with some omission. > Andrew: I claim that Zig is faster than C.... > I can give micro benchmarks of messing around with integers... > I would make argument that based on principles of the language, the conventions that we have, the organization of standard library, there are also results in practice that Zig application tend to be faster... > In C signed integer addition overflow is undefined and unsigned integer overflow is wrapping. In Zig it's consistent and signed and unsigned overflow is illegal behavior.

ncmncm 4y ago

C performance is no great shakes anymore. C++ and Rust routinely exceed it. Java and Javascript, even, sometimes. People still compare to C because (1) it is easier to beat, (2) you are less likely to be accused of cooking the comparison by coding the reference badly, and (3) you don't provoke the question, "why not just code in that, then?"

jstimpfle 4y ago

The article is quite weak IMO and mixes up a few things. For example, there isn't really a "global allocator" built into the C language. In the case of your quote, this is a misunderstanding on the performance optimizations that were done on the Zig compiler itself (it compiles faster). But that makes no difference to the performance of the compiled program. And the techniques that were mentioned can be used in the implementation of any other compiler as well.

stephc_int13 4y ago

In this case, I think this is poorly written. Andrew was talking about the Zig compiler and the data-oriented approach he used, leading to better compile speed. About the speed of the generated code, I have not seen many benchmarks, but I expect to see minimal differences with C. With better semantics around pointer aliasing and parallel-friendly loops they could produce faster machine code than C, but likely not by a huge margin.

andrepd 4y ago

If "faster than C" means "I can make a Zig program such that no equivalent C program is faster", then that's obviously false. If it means "some idiomatic Zig program is faster than the equivalent idiomatic C", it might be true.

kaba0 4y ago
> “I can make a Zig program such that no equivalent C program is faster", then that's obviously false Why would it be obviously false? C is not that low-level of a language, for example it has no native way of doing SIMD - so Rust, C++ (and I guess Zig as well?) all have programs that are simply non-expressible in C (inline assembly is not C) and are possibly orders of magnitude faster. But there are million other things “hard-coded” into C where with more control faster execution could be achieved - e.g. one might want to have better control over stack usage.
littlestymaar 4y ago
> If "faster than C" means "I can make a Zig program such that no equivalent C program is faster", then that's obviously false. It could be true though, because compilers aren't perfect, and for instance it actually happens with scientific code written in Fortran: C has restrict but because it's not widely used, C compilers don't make use of it as much as they could for optimization, which means that a language like Fortran that values the non-aliasing guarantee can have a compiler which optimizes it more than what C compilers do. That being said, there's nothing preventing C compilers to add the same level of aliasing-based optimizations in theory, it's just that they don't do it yet in practice (Rust is pushing the boundaries on that for LLVM though, because noalias optimizations is regarded as a promising performance enhancement for Rust).
notacoward 4y ago
That is a good point, but I think "idiomatic" here deserves some elaboration. Often people use it in very vague way: this is what (outspoken) programmers agree is the best way to do this thing. In this case, I think a more limited and specific definition is sufficient: don't use escape hatches. Don't use "unsafe" or compiler-specific extensions or inline assembly or libraries that were actually written in assembly. What can you do in the language as it comes out of the box, as every tutorial would lead you to do? I think Zig could indeed be "faster than C" in this sense, as others have pointed out Fortran can be, but Rust might not be able to. There's also an important lesson here about optimization BTW. Everyone thinks of optimizing algorithms in terms of big-O stuff, and that's great, but sometimes data size or layout or frequency of pointer-chasing or mispredicted branches can actually be the real difference makers. Cache-friendly vs. cache-hostile code can be particularly hard to spot, because it often doesn't show up even in most kinds of profiling. It presents only as a sort of general performance degradation across the board unless you're specifically looking for it. I've implemented significant performance gains just by rearranging code and scheduling to make better use of a processor's L1 I-cache. The gains to be had from doing the same for data in L2 and L3 caches are even greater. I appreciate that Zig is being designed with these issues in mind, because it seems like a lot of other newer languages are being designed with the specific goal of defeating modern computers' performance-enhancement techniques.

sekao 4y ago

Andrew argues that zig can produce faster programs than c or rust towards the end of the video: https://youtu.be/gn3YsZ6HUHw?t=3566 https://youtu.be/gn3YsZ6HUHw?t=3566

lucozade 4y ago

I'm guessing that the author is just confusing multiple things. Andrew has been using data oriented approaches to make the self hosted compiler fast. And the article mentions an example where he's separated (presumably arrays of) tagged unions into distinct arrays of tags and payloads. Depending on the access pattern, this can definitely speed things up on modern CPUs. The article then goes on to say that this is impossible in Rust, which is probably a fair statement. You may be able to get something quite close with really horrible, unsafe code but no sane person would try. But it's blatantly untrue that you can't do this in C. I mean, C doesn't even have tagged unions so you need to code the tags explicitly if you want them. Separating them into a different array is trivial. I guess it's possible that one could argue, say, Turing idiomatic Zig into highly optimised Zig is easier than the equivalent in C so, in practice, equivalent code is faster. Or some such. I have no idea if anyone's actually shown that quantitively though.

LegionMammal978 4y ago
> The article then goes on to say that this is impossible in Rust, which is probably a fair statement. You may be able to get something quite close with really horrible, unsafe code but no sane person would try. As it happens, a crate was just released that does exactly this, using a derive macro [0]. (I wouldn't recommend using it quite yet, though; it still has a few kinks to be worked out.) [0] https://crates.io/crates/peapod https://crates.io/crates/peapod
- pcwalton 4y ago
  Yeah, in general macros allow for Rust to do these things just fine. I wouldn't say that it's a fair statement at all.

flohofwoe 4y ago

The data oriented design stuff was mostly in the new compiler implementation (which can lead to faster compilation, but is unrelated to the performance of the compiler output). But Zig might have some features which might theoretically allow the compiler to generate slightly more performant code (compared to portable standard C code). E.g. since function arguments are read only, the compiler might be able to avoid a copy on the stack when passing structs > 16 bytes by value. Also since Zig programs are (AFAIK) generally compiled as a unity build, the compiler has more inlining opportunities compared to a conventionally linked C program (without LTO). Etc... etc.. so theoretically it might be possible, but I'd still take such statements with a grain of salt until demonstrated on real world code.

Ygg2 4y ago

See https://m.youtube.com/watch?t=3566&v=gn3YsZ6HUHw https://m.youtube.com/watch?t=3566&v=gn3YsZ6HUHw Transcript with some omission. > Andrew: I claim that Zig is faster than C.... > I can give micro benchmarks of messing around with integers... > I would make argument that based on principles of the language, the conventions that we have, the organization of standard library, there are also results in practice that Zig application tend to be faster... > In C signed integer addition overflow is undefined and unsigned integer overflow is wrapping. In Zig it's consistent and signed and unsigned overflow is illegal behavior.