Hacker News Reader

Comment by pjmlp | Hacker News Reader

> 1. It's typically at least as fast as C, unlike C++/Rust

The typical urban myth that never comes with profiler proofs.

TBF, Zig with the LLVM backend may be faster than C or C++ compiled with Clang out of the box just because Zig uses more fine-tuned default compilation options. That's true even for C or C++ code compiled with 'zig cc'.

But apart from that the performance should be pretty much identical, after all it's LLVM that does the heavy lifting.

That is a big may, given that it depends pretty much on what is being done in terms of code, and compile time execution (C++ and Rust), and many of the same compiler knobs are also available for C++ code, if not even more.

And was you point out, at the end of the day it is the same LLVM IR.

That was the point I was trying to make, Zig isn't inherently faster than the other three. It just uses different default compilation options than clang, so any gains can be achieved in clang-compiled C or C++ too by tweaking compile options (and maybe using a handful non-standard language extensions offered by clang). Other then that it's just LLVMs "zero cost abstraction via optimization passes" and this works equally well across all 4 languages.

Or: the "optimization wall" in those languages is the same, only the effort to reach that wall might be slightly different (and this is actually where Zig and its stdlib might be better, it's more straightforward to reach the optimization wall because the Zig design philosophy prefers explicitness over magic)

I don't need to prove you anything. Go and give it a try yourself.

https://programming-language-benchmarks.vercel.app/c-vs-cpp

https://programming-language-benchmarks.vercel.app/c-vs-rust

I understand that anytime someone brings benchmarks out, the next response points out that benchmarks are not real world use cases. Nonetheless, they are data points, and your claims are against the commonly accepted view of C being roughly as fast as C++ and Rust. If you have absolutely no data to back it up, you shouldn't expect anyone to believe you.

I don't need any data to say that Zig is typically faster than Rust because I know that Vec<T> will do a shitload of useless work when it leaves the scope, even if the T does not implement Drop. You can do vec.set_len() but that's unsafe, so... Typical Rust is slower than typical Zig.

Zig does not do any work because it does not have smart pointers and it does not try to be safe. It tries to be explicit and predictable, the rest is my job.

BTW: This is very real, I've been profiling this and I couldn't believe my eyes. And even if they fixed it already there would be many similar footguns. You can't write performant software if you can't tell what work will be done.

You are comparing different memory management strategies, not languages features. All of those languages (C, Zig, C++ and Rust) give you enough choices when it comes to memory management.

You can decide to not use frequent heap allocations in Rust or C++ just as you can in Zig (it means not using large areas of the C++ or Rust standard libraries, while Zig definitely has the better approach when it comes to allocations in the standard library, but these are stdlib features, not language features).

That "just" seems to mean "you'll need to take 10x the time to write the equivalent Rust/C++ program". What a language makes easy to accompish matters.

Yes, it's true that you can do arenas in Rust, but they are harder to use in Rust, due to borrow-checking. For example you can't store arena in a struct without lifetime.

So in a language which actively makes your life miserable in the name of safety, you will likely just use Vec<T> because it's easy. Hence, back to the previous point - Vec<T> is slow -> your code is slow and it's not even obvious why because everybody does that so it looks like you're doing it right.

I'm a Zig fan and all, but you should probably check if your C/C++/Rust code uses the equivalent of "-march=native", that might already be responsible for most of the performance difference between those and Zig - they all use the same LLVM optimization passes after all, so excluding obvious implementation differences (like doing excessive heap allocations) there isn't any reason why one would be faster than the other.

The point was typical, typical Rust code is using Vec<>, typical Zig code is using arenas. Typical Rust code is using smart pointers, typical Zig/C code prefers plain, copyable structs.

It is 100% possible to use such style in Rust/C++ (and then the performance will be same or maybe even in favor of rust, it might be the case) but people usually do not do that.

It shouldn't be hard to make Zig go to top place then, which is great opportunity to shine, given that they are still missing Zig entries,

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://www.techempower.com/benchmarks/

Zig can and does win plenty of those benchmarks, but ultimately it boils down to who is it that gets nerdsniped into working on a specific challenge.

For example in this case Zig won big time over what C/C++/Rust people submitted: https://youtu.be/pSvSXBorw4A?t=1075

Zig is in the same ballpark as the ones mentioned above, so flohofwoe is right. But nevertheless I do think that cztomsik's point also still stands: how hard it is to make something fast will end up impacting the performance characteristics of the average program and library out there, and Zig does make it easier to write performant code than some other languages.

Which is basically what happened here: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

In truth the same applies to correctness, which is also a point that the blog post above touches upon.

> basically what happened here

Pico benchmarks!

https://github.com/zackradisic/rust-vs-zig/blob/master/bench...

> Zig can and does win plenty of those benchmarks, but ultimately it boils down to who is it that gets nerdsniped into working on a specific challenge.

> For example in this case Zig won big time over what C/C++/Rust people submitted: https://youtu.be/pSvSXBorw4A?t=1075

That was a faulty benchmark with a simple unnatural footgun that the Rust people overlooked. I don't think it supports your claim that benchmarks typically boil down to who is it that gets nerdsniped into them. Sure, it can happen, it happened at least once, but in general?

It goes both ways.

Reply on news.ycombinator.com