My hypothesis is that Zig's compiler passes the equivalent of -march=native to the backend, which is why it should also be given to the C compiler to give a fair comparison (and a speedup of 30% or so).
Much appreciated. Given Zig's design and use of LLVM, for code translated "line by line" (same algorithm) I don't see any reason for Zig's performance not to be substantially identical to C (compiled with Clang).
It wouldn't surprise me if there are reasons Zig can do better or makes it easier to use better algorithms, etc, but you wouldn't expect that to show up in something as computationally straightforward as a cryptographic primitive.
By the way, as a C practitioner, I'm a fan of what you're doing with Zig; keep it up! C++, Go, and Rust don't appeal to me for all of the reasons mentioned in your talk.
Compiling with -march=native makes for brittle binaries, since the binary might contain instructions that are not be available on slightly older CPUs or on virtual machines. So it's only suitable for software that's performance sensitive but won't be distributed to other machines (or at least won't be distributed outside of a strictly controlled environment). It wouldn't make for a good default.
When you are shipping binaries, you usually do not have control over the cpus your users are using. Setting march/mtune to native breaks if the developers machine is noticeably newer than the users machine. Also letting the build machine configuration decide which level of simd to target is too flakey, so most software specifies the target explicitly.
Because your cpu has a base ISA, plus extensions. The compiler doesn't know if you're going to only run this binary on your machine, or distribute it to others that may share your base ISA but possibly not your extensions, so it takes the conservative approach and doesn't use them unless signaled to do so via those compiler flags. Also, I think -march implies -mtune.
In Zig the default target is native, which turns on all the applicable CPU features. If you want to target something other than the native machine you can use --target-os --target-arch parameters. I haven't exposed extra CPU options for cross compiling yet.
Do you consider the default architecture targetted by GCC (e.g. some old Intel) to be cross compiling? That is, can I make a binary that supports most x86 processors rather than just those with the particular extensions I support, with the current Zig compiler?
Yes. You can pass the native OS and native arch as the cross compilation target, and produce a binary that runs on your machine and others that don't have the same extra CPU features.
You'd have to ask the compiler communities that. As an observer, I notice that C compilers are extremely conservative about changing defaults in new versions. And I could imagine some benefits of that approach, and downsides. But I am not involved in e.g. gcc or clang development.
It is if you compile everything yourself on every system you use. Every Gentoo user does it (or at least, the equivalent of it using explicit flags in case they use distcc). But most people don't do that. They use software compiled by other people on very different machines.
