7 ms·

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 pr

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.
P5fRxh5kUvp2th 4y ago
Sure, but this is only true because C allows for assembly code so you can always write assembly that beats zig. If you limit it to actual C and don't include assembly, it's possible the statement is true but I would expect it to also be false depending on the circumstances. zig is going to have more opportunities to optimize but may be paying a cost in terms of offered features that C doesn't have. But in general, yes, zig is very fast and competes with C in terms of performance.
- pjmlp 4y ago
  Inline Assembly is not part of ISO C and plenty of languages have such extensions.
  - P5fRxh5kUvp2th 4y ago
    If you read closer, my point was that anything Zig can do, can be done in C due to it's ubiquitous ability to bypass the compiler and move straight to assembler. I can't think of a major C compiler that does not allow for this, can you? The only thing I could imagine coming close is something like compiling to a very specific target such as GPU shaders, but even that's a bad example considering shaders have been standardized.
    - pjmlp 4y ago
      MSVC, inline Assembly is only available on x86 mode, everywhere else requires compiler intrisics or MASM.
      - P5fRxh5kUvp2th 4y ago
        Just checked, apparently that's right for MSVC. My point still remains but I take your point about its limitations. My post was more a caveat on the original point anyways, I wouldn't expect most people to drop down to assembly except in very specific circumstances.
- boltzmann-brain 4y ago
azakai 4y ago
A concrete example of idiomatic Zig being faster is MultiArrayList and language features that work well with it, which lets you use the struct-of-arrays pattern in an ergonomic way. You can do it in any other systems language, of course, but the Zig syntax is very convenient so arguably it's more likely to be used. https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-in-userland-40m0 https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-i...

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.

P5fRxh5kUvp2th 4y ago

Sure, but this is only true because C allows for assembly code so you can always write assembly that beats zig. If you limit it to actual C and don't include assembly, it's possible the statement is true but I would expect it to also be false depending on the circumstances. zig is going to have more opportunities to optimize but may be paying a cost in terms of offered features that C doesn't have. But in general, yes, zig is very fast and competes with C in terms of performance.

pjmlp 4y ago
Inline Assembly is not part of ISO C and plenty of languages have such extensions.
- P5fRxh5kUvp2th 4y ago
  If you read closer, my point was that anything Zig can do, can be done in C due to it's ubiquitous ability to bypass the compiler and move straight to assembler. I can't think of a major C compiler that does not allow for this, can you? The only thing I could imagine coming close is something like compiling to a very specific target such as GPU shaders, but even that's a bad example considering shaders have been standardized.
  - pjmlp 4y ago
    MSVC, inline Assembly is only available on x86 mode, everywhere else requires compiler intrisics or MASM.
    - P5fRxh5kUvp2th 4y ago
      Just checked, apparently that's right for MSVC. My point still remains but I take your point about its limitations. My post was more a caveat on the original point anyways, I wouldn't expect most people to drop down to assembly except in very specific circumstances.
boltzmann-brain 4y ago

azakai 4y ago

A concrete example of idiomatic Zig being faster is MultiArrayList and language features that work well with it, which lets you use the struct-of-arrays pattern in an ergonomic way. You can do it in any other systems language, of course, but the Zig syntax is very convenient so arguably it's more likely to be used. https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-in-userland-40m0 https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-i...