4 ms·

> Speaking of performance, Zig is faster than C. These kinds of claims make me so dubious for a language. Also who is trying to switch from C to get an ever-so

> Speaking of performance, Zig is faster than C. These kinds of claims make me so dubious for a language. Also who is trying to switch from C to get an ever-so-slightly performance improvement? That use-case goes to specialized hardware such as FPGAs.

AnIdiotOnTheNet 7y ago
It's not about the speed being a benefit per-se, but rather not a determent. One of the big reasons people still use C over other languages is that C is perceived to be faster (and indeed usually is).
trulyrandom 7y ago
Whether the claim hold up or not. If you developed a language that's faster than C, would you not advertise that as a feature?
- 0xdead 7y ago
  I would, first of all, call bullshit on this claim. A language can't be "faster than C". Comparing a good implementation with a bad C implementation is where these claims come from.
  - ogoffart 7y ago
    > A language can't be "faster than C". Why not? For instance, with current hardware, the good use of SIMD is critical. If you can't write vectorized code in (standard) C while you can do it in another Language, that would be a "faster" language. Same for other language features that enable faster code: Compile-time computations, better memory model with different pointer aliasing semantic, ...
  - Bootvis 7y ago
    You can dispute Zig, but in practice there is FORTRAN that is faster for many math procedures.
    - 7thaccount 7y ago
      Yea. It's always funny when people say C is faster than Fortran for scientific computing. I mean, it's true, but only for a very limited amount of people who want to do serious numeric work. C/C++ certainly aren't rare in this area, but Fortran is pleasant to work with for most numeric work and has lots of helpful built-ins and runs close to C in speed.
  - mratsim 7y ago
    If a language allows you: - to map cleanly with what compilers know to optimize best - fine control over stack and heap allocation - has intrinsics / assembly escape hatch - allows you to specify that pointers don't alias (restrict in C, or default in Fortran) - gives you prefetching primitives You will be able to reach hand-tuned Assembly-like performance (and not just C-like performance). Case in-point, I tuned my own matrix multiplication algorithms in Nim to carefully control register allocations, L1, L2 and L3 cache usage, and vector intrinsics to reach the speed of assembly tuned OpenBLAS and Intel MKL-DNN (no assembly at all): bench: https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/gemm/gemm_bench_float32.nim#L379-L441 https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/g... code: https://github.com/numforge/laser/tree/c7ddceb0/laser/primitives/matrix_multiplication https://github.com/numforge/laser/tree/c7ddceb0/laser/primit... And matrix multiplication has decades of research and now dedicated hardware (tensor cores, EPU, TPU, NPU, ...) as this is a key algorithm for most numerical workloads.
lkey 7y ago
You picked that quote from the main page, not from the release notes, here is what directly follows: * The reference implementation uses LLVM as a backend for state of the art optimizations. * What other projects call "Link Time Optimization" Zig does automatically. * For native targets, advanced CPU features are enabled (-march=native), thanks to the fact that Cross-compiling is a first-class use case. * Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C. Zig directly exposes a SIMD vector type, making it easy to write portable vectorized code. So the argument is "exact same compiler as C/C++, but more opportunities for optimization thanks to better semantics and better access to native instructions". This seems reasonable on its face, so care to elaborate on the doubt? The arguments for not switching from C are often performance or target related, so a language that purports to be an alternative to C would want to point out that those issues aren't a problem. The reasons to switch away from C are numerous and well documented.
- saagarjha 7y ago
  > For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. Huh, that's a strange choice. What's the safety story for Zig? Are these always undefined, or is that only in an "unchecked" build?
  - AnIdiotOnTheNet 7y ago
    The latter. Zig actually kinda does define this behavior as "`a + b` shall not overflow" and inserts checks in debug and safe builds for it. To get overflow, which zig defines as wrapping overflow, you use a different operator and no check is inserted "`a +% b`". For speed optimized builds, unless you've explicitly told the compiler to insert checks in that scope, it will turn the checks into nops. So, while it is technically correct to say that it has undefined behavior for overflow, the practical reality is quite different.
    - steveklabnik 7y ago

AnIdiotOnTheNet 7y ago

It's not about the speed being a benefit per-se, but rather not a determent. One of the big reasons people still use C over other languages is that C is perceived to be faster (and indeed usually is).

trulyrandom 7y ago

Whether the claim hold up or not. If you developed a language that's faster than C, would you not advertise that as a feature?

0xdead 7y ago
I would, first of all, call bullshit on this claim. A language can't be "faster than C". Comparing a good implementation with a bad C implementation is where these claims come from.
- ogoffart 7y ago
  > A language can't be "faster than C". Why not? For instance, with current hardware, the good use of SIMD is critical. If you can't write vectorized code in (standard) C while you can do it in another Language, that would be a "faster" language. Same for other language features that enable faster code: Compile-time computations, better memory model with different pointer aliasing semantic, ...
- Bootvis 7y ago
  You can dispute Zig, but in practice there is FORTRAN that is faster for many math procedures.
  - 7thaccount 7y ago
    Yea. It's always funny when people say C is faster than Fortran for scientific computing. I mean, it's true, but only for a very limited amount of people who want to do serious numeric work. C/C++ certainly aren't rare in this area, but Fortran is pleasant to work with for most numeric work and has lots of helpful built-ins and runs close to C in speed.
- mratsim 7y ago
  If a language allows you: - to map cleanly with what compilers know to optimize best - fine control over stack and heap allocation - has intrinsics / assembly escape hatch - allows you to specify that pointers don't alias (restrict in C, or default in Fortran) - gives you prefetching primitives You will be able to reach hand-tuned Assembly-like performance (and not just C-like performance). Case in-point, I tuned my own matrix multiplication algorithms in Nim to carefully control register allocations, L1, L2 and L3 cache usage, and vector intrinsics to reach the speed of assembly tuned OpenBLAS and Intel MKL-DNN (no assembly at all): bench: https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/gemm/gemm_bench_float32.nim#L379-L441 https://github.com/numforge/laser/blob/c7ddceb0/benchmarks/g... code: https://github.com/numforge/laser/tree/c7ddceb0/laser/primitives/matrix_multiplication https://github.com/numforge/laser/tree/c7ddceb0/laser/primit... And matrix multiplication has decades of research and now dedicated hardware (tensor cores, EPU, TPU, NPU, ...) as this is a key algorithm for most numerical workloads.

lkey 7y ago

You picked that quote from the main page, not from the release notes, here is what directly follows: * The reference implementation uses LLVM as a backend for state of the art optimizations. * What other projects call "Link Time Optimization" Zig does automatically. * For native targets, advanced CPU features are enabled (-march=native), thanks to the fact that Cross-compiling is a first-class use case. * Carefully chosen undefined behavior. For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. This facilitates optimizations that are not available in C. Zig directly exposes a SIMD vector type, making it easy to write portable vectorized code. So the argument is "exact same compiler as C/C++, but more opportunities for optimization thanks to better semantics and better access to native instructions". This seems reasonable on its face, so care to elaborate on the doubt? The arguments for not switching from C are often performance or target related, so a language that purports to be an alternative to C would want to point out that those issues aren't a problem. The reasons to switch away from C are numerous and well documented.

saagarjha 7y ago
> For example, in Zig both signed and unsigned integers have undefined behavior on overflow, contrasted to only signed integers in C. Huh, that's a strange choice. What's the safety story for Zig? Are these always undefined, or is that only in an "unchecked" build?
- AnIdiotOnTheNet 7y ago
  The latter. Zig actually kinda does define this behavior as "`a + b` shall not overflow" and inserts checks in debug and safe builds for it. To get overflow, which zig defines as wrapping overflow, you use a different operator and no check is inserted "`a +% b`". For speed optimized builds, unless you've explicitly told the compiler to insert checks in that scope, it will turn the checks into nops. So, while it is technically correct to say that it has undefined behavior for overflow, the practical reality is quite different.
  - steveklabnik 7y ago