8 ms·

There are too many cool languages and too few weekends. It's becoming more problematic, but at the same time it would seem impractical to optimize my life aroun

by qop 8y ago

There are too many cool languages and too few weekends. It's becoming more problematic, but at the same time it would seem impractical to optimize my life around learning every single thing that I want to learn. How do I decide which things are important enough? I am running out of time in my life also. I watched a video a while ago about how the universe is expanding faster than light can travel, which means the portion of the universe that we can observe is an increasingly small subset of what's out there. Sometimes my hobbies and wish-i-had-time-for-that projects feel the same way, they're expanding faster than I'll ever catch up to. I wonder if zig will ever pursue some sort of memory safety. I find rust very difficult and unwieldy, but I can totally grok the appeal of RAII.

espeed 8y ago
> I wonder if zig will ever pursue some sort of memory safety. That's exactly what Zig is designed for [1]. Andrew Kelley (andrewrk) discusses this in the talk. Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought. And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. [1] http://ziglang.org http://ziglang.org [2] https://github.com/ziglang/zig https://github.com/ziglang/zig
- CyberDildonics 8y ago
  I don't understand. Rust has memory safety as a core design principle. Zig has manual memory allocation like C.
  - tiehuis 8y ago
    Zig is memory-safe if you keep runtime checks enabled (e.g. with debug or release-safe optimization levels) but it does not have the compile-time guarantees of Rust. I don't think the parent comment is a fair reflection. That being said, some other potentially interesting safety aspects that are present (or are being explored) to give some idea of the target audience: - compile-time alignment checks [1] - maximum compile-time stack usage/bounding [2] I would expect safety at the end of the day in Zig will be more similar to modern C++ and its smart pointers, alongside (optional) runtime checks, than a full lifetime system. Will have to see what the future holds. [1] https://ziglang.org/documentation/master/#Alignment https://ziglang.org/documentation/master/#Alignment [2] https://github.com/ziglang/zig/issues/1006 https://github.com/ziglang/zig/issues/1006
- tom_mellior 8y ago
  > And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. Do you know at what timestamp (roughly) this is mentioned in the video? YouTube makes it hard to quickly skip around in the video to find this. Or, better, a link to a written source? I'd be interested in what exactly is being compared. It's easy to cheat on benchmarks, especially when you aren't doing it on purpose.
  - espeed 8y ago
    Right at about the 20m mark: https://youtu.be/Z4oYSByyRak?t=20m2s https://youtu.be/Z4oYSByyRak?t=20m2s
    - tom_mellior 8y ago
      Thanks! Grabbing the sources from https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly and compiling them more or less as recommended (and unlike they are compiled in the talk): $ clang -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 197.2 MB/s Self-check passed Speed: 196.1 MB/s Self-check passed Speed: 196.1 MB/s $ gcc -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 209.7 MB/s Self-check passed Speed: 209.2 MB/s Self-check passed Speed: 209.1 MB/s This is a baseline for us. It has nothing to do with Zig and nothing to do with Andrew's machine (hardware or compiler versions). But wait, the page above suggests that adding -march=native might help. Indeed it does: $ clang -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 255.6 MB/s Self-check passed Speed: 259.0 MB/s Self-check passed Speed: 254.3 MB/s $ gcc -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 275.1 MB/s Self-check passed Speed: 268.4 MB/s Self-check passed Speed: 270.0 MB/s In the talk Andrew suggests that the difference might be due to using rorx instructions, which Zig might be able to do due to aggressive loop unrolling. Does -funroll-all-loops help GCC? It turns out that it doesn't, and that it cannot, on this program, because the C code for sha256_compress is already fully unrolled. But anyway, are we using rorx instructions at all? We are, but only with -march=native: $ clang -O3 -S sha256.c -o - | grep -c rorx 0 $ clang -O3 -march=native -S sha256.c -o - | grep -c rorx 542 And: $ gcc -O3 -S sha256.c -o - | grep -c rorx 0 $ gcc -O3 -march=native -S sha256.c -o - | grep -c rorx 576 [Edit: Changed the grep from "ror" to "rorx", which changed GCC's numbers a bit; it does generate "ror" without x without -march=native.] So. Testable theories: (a) On Andrew's machine, the same setup but with Clang using -march=native would outperform or at least match Zig. (b) Zig's compiler internally uses the equivalent of -march=native, possibly implicitly, at least in --release-fast mode. Nothing here is meant to imply that Andrew is dishonest. There are just lots of variables to take into account, and sometimes we don't. Also, "slower/faster than C" by a few percent is not very meaningful if even C compilers disagree by 6% or so, and the same C compiler with the right flags disagrees with itself by a lot more.
- Yoric 8y ago
  I may be wrong, but if I read the documentation correctly, Rust looks more memory-safe than Zig. What am I missing?
  - mschwaig 8y ago
    Rust has lifetimes and ownership as language concepts so that you have to be explicit about who owns a resource, for example memory, but it does not give you a lot of control about what to do when an allocation fails. Zig is designed so that you can still peogrammatically deal with a failing allocation, as does well-written C, but it does not have a ownership system like Rust.
    - Yoric 8y ago
      Ok, got it. Apparently, espeed was using an unusual definition of "memory safety", which made their comment a bit odd :)
      - tom_mellior 8y ago
        What was unusual about that? Here is Wikipedia: "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences." This is the mainstream definition. Do you think Zig doesn't have this, or Rust has more of this than Zig? What Rust does indeed have is freedom from race conditions, which can be viewed as a concurrent memory safety property. And what Rust also has is static checking of one of the above properties, namely dangling pointers (but not the other, namely buffer overflows). Do you think that if it's not statically checked, it's not safe? Because if you think that, you are wrong.
        Yoric 8y ago
        I was referring to espeed's "Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought", which he later explained with two examples, one of which actually justifies the words "bolted on as an afterthought", but refers to local handling of fallible allocation. While local handling of fallible allocation is a desirable feature for many applications, I confirm that neither me nor Wikipedia had never heard it classified as "memory safety" :)
skybrian 8y ago
If Zig (or some other language) turns out to be the next big thing, we'll be hearing about it again and again.

by qop 8y ago

espeed 8y ago

> I wonder if zig will ever pursue some sort of memory safety. That's exactly what Zig is designed for [1]. Andrew Kelley (andrewrk) discusses this in the talk. Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought. And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. [1] http://ziglang.org http://ziglang.org [2] https://github.com/ziglang/zig https://github.com/ziglang/zig

CyberDildonics 8y ago
I don't understand. Rust has memory safety as a core design principle. Zig has manual memory allocation like C.
- tiehuis 8y ago
  Zig is memory-safe if you keep runtime checks enabled (e.g. with debug or release-safe optimization levels) but it does not have the compile-time guarantees of Rust. I don't think the parent comment is a fair reflection. That being said, some other potentially interesting safety aspects that are present (or are being explored) to give some idea of the target audience: - compile-time alignment checks [1] - maximum compile-time stack usage/bounding [2] I would expect safety at the end of the day in Zig will be more similar to modern C++ and its smart pointers, alongside (optional) runtime checks, than a full lifetime system. Will have to see what the future holds. [1] https://ziglang.org/documentation/master/#Alignment https://ziglang.org/documentation/master/#Alignment [2] https://github.com/ziglang/zig/issues/1006 https://github.com/ziglang/zig/issues/1006
tom_mellior 8y ago
> And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. Do you know at what timestamp (roughly) this is mentioned in the video? YouTube makes it hard to quickly skip around in the video to find this. Or, better, a link to a written source? I'd be interested in what exactly is being compared. It's easy to cheat on benchmarks, especially when you aren't doing it on purpose.
- espeed 8y ago
  Right at about the 20m mark: https://youtu.be/Z4oYSByyRak?t=20m2s https://youtu.be/Z4oYSByyRak?t=20m2s
  - tom_mellior 8y ago
    Thanks! Grabbing the sources from https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly https://www.nayuki.io/page/fast-sha2-hashes-in-x86-assembly and compiling them more or less as recommended (and unlike they are compiled in the talk): $ clang -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 197.2 MB/s Self-check passed Speed: 196.1 MB/s Self-check passed Speed: 196.1 MB/s $ gcc -O3 sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 209.7 MB/s Self-check passed Speed: 209.2 MB/s Self-check passed Speed: 209.1 MB/s This is a baseline for us. It has nothing to do with Zig and nothing to do with Andrew's machine (hardware or compiler versions). But wait, the page above suggests that adding -march=native might help. Indeed it does: $ clang -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 255.6 MB/s Self-check passed Speed: 259.0 MB/s Self-check passed Speed: 254.3 MB/s $ gcc -O3 -march=native sha256-test.c sha256.c -o sha256-test ; for i in 1 2 3; do ./sha256-test ; done Self-check passed Speed: 275.1 MB/s Self-check passed Speed: 268.4 MB/s Self-check passed Speed: 270.0 MB/s In the talk Andrew suggests that the difference might be due to using rorx instructions, which Zig might be able to do due to aggressive loop unrolling. Does -funroll-all-loops help GCC? It turns out that it doesn't, and that it cannot, on this program, because the C code for sha256_compress is already fully unrolled. But anyway, are we using rorx instructions at all? We are, but only with -march=native: $ clang -O3 -S sha256.c -o - | grep -c rorx 0 $ clang -O3 -march=native -S sha256.c -o - | grep -c rorx 542 And: $ gcc -O3 -S sha256.c -o - | grep -c rorx 0 $ gcc -O3 -march=native -S sha256.c -o - | grep -c rorx 576 [Edit: Changed the grep from "ror" to "rorx", which changed GCC's numbers a bit; it does generate "ror" without x without -march=native.] So. Testable theories: (a) On Andrew's machine, the same setup but with Clang using -march=native would outperform or at least match Zig. (b) Zig's compiler internally uses the equivalent of -march=native, possibly implicitly, at least in --release-fast mode. Nothing here is meant to imply that Andrew is dishonest. There are just lots of variables to take into account, and sometimes we don't. Also, "slower/faster than C" by a few percent is not very meaningful if even C compilers disagree by 6% or so, and the same C compiler with the right flags disagrees with itself by a lot more.
Yoric 8y ago
I may be wrong, but if I read the documentation correctly, Rust looks more memory-safe than Zig. What am I missing?
- mschwaig 8y ago
  Rust has lifetimes and ownership as language concepts so that you have to be explicit about who owns a resource, for example memory, but it does not give you a lot of control about what to do when an allocation fails. Zig is designed so that you can still peogrammatically deal with a failing allocation, as does well-written C, but it does not have a ownership system like Rust.
  - Yoric 8y ago
    Ok, got it. Apparently, espeed was using an unusual definition of "memory safety", which made their comment a bit odd :)
    - tom_mellior 8y ago
      What was unusual about that? Here is Wikipedia: "Memory safety is the state of being protected from various software bugs and security vulnerabilities when dealing with memory access, such as buffer overflows and dangling pointers.[1] For example, Java is said to be memory-safe because its runtime error detection checks array bounds and pointer dereferences." This is the mainstream definition. Do you think Zig doesn't have this, or Rust has more of this than Zig? What Rust does indeed have is freedom from race conditions, which can be viewed as a concurrent memory safety property. And what Rust also has is static checking of one of the above properties, namely dangling pointers (but not the other, namely buffer overflows). Do you think that if it's not statically checked, it's not safe? Because if you think that, you are wrong.
      - Yoric 8y ago
        I was referring to espeed's "Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought", which he later explained with two examples, one of which actually justifies the words "bolted on as an afterthought", but refers to local handling of fallible allocation. While local handling of fallible allocation is a desirable feature for many applications, I confirm that neither me nor Wikipedia had never heard it classified as "memory safety" :)

skybrian 8y ago

If Zig (or some other language) turns out to be the next big thing, we'll be hearing about it again and again.