Somewhere I heard that zig performance is faster than rust.
- Really if it is then why?.
- How to overcome it.
3 Likes
This is such a nebulous question that it's not really possible to answer or even really discuss. You're leaving so much of the question itself undefined and asking us to define it for you.
In what sense would you consider one language to be "faster" than another? Do you have a use case in mind? Are you talking purely about the core language or do you mean the standard library?
21 Likes
See for yourself: Rust VS Zig benchmarks, Which programming language or compiler is faster
Different problems, different solutions, different problem set sizes. Apparently one language wins sometimes the other some other times.
You decide.
Do you have an actual problem in mind? No one can advise how to boost performance of an unspecified problem.
10 Likes
Its about core language
2 Likes
Zig only requires 75% of the text that Rust requires.
Zig is faster to type and faster to say than Rust. Though way behind "C", Rust comes out way ahead of Zig, alphabetically.
76 Likes
Both are based on LLVM and low-level enough that the user can control almost everything given to LLVM. In this way their best-case run-time performance is pretty much identical.
There's a more nebulous question which language makes faster programs when they're written in an idiomatic way, which is faster while keeping safety guarantees, which is fast-enough when used naively without tuning code for performance, etc. These factors matter, but are hard to objectively specify and measure. Still, I'd expect Rust and Zig to be similar in this area.
Where Zig is faster is compilation time. Zig doesn't have as many high-level constructs as Rust, and doesn't have as strong safety guarantees, so the Zig compiler has less work to do.
If you look at benchmarks of some basic programming problems, both languages are similar. Often variability between different implementations in the same language is bigger than difference between the languages:
20 Likes
This statement is generally not meaningful. One can write slow programs in any language.
And really, "high level of control" languages -- which are sometimes called "fast" -- actually make it easier to write slow programs, in a way, because there's more things that can be done wrong.
7 Likes
Andrew Kelley the zig lang creator make comments on zig even faster than rust.
He also described how zig achieved it.
Open the above link and see it from 01-00-00
3 Likes
I think Andrew Kelley has done an amazing job with Zig. However I'm not prepared to accept that it is faster than Rust in general. At least the evidence I have seen indicates Zig and Rust are pretty much neck and neck. See benchmark links above.
Speed is only one criteria in selecting between languages. And of vanishingly small priority as they are more similar in performance.
So, for now I have many reasons to stick with Rust.
4 Likes
The arguments in the video basically boil down to Zig making some patterns easy which are not easy in C or Rust respectively. I have seen the same kind of claim be used to argue that Rust is faster than C++, but I have also seen actual pieces of real code be implemented in both idiomatic C++ and idiomatic Rust, and the actual outcome is that there's no clear winner — sometimes Rust is a bit faster and sometimes C++ is.
Until I see evidence otherwise, I will assume that the same holds for Zig vs Rust.
33 Likes
Hmm, I tried to find an example, but besides the benchmark sites that have already been posted, I couldn't find any public descriptions of one. My experience mainly comes from people telling me about their experiences rewriting projects in Rust, and the people who get large speedups are generally rewriting something written in a language with a garbage collector.
4 Likes
There’s also Kostya’s benchmark:
Last updated 2021/12/22. Rust surpasses Zig in 4 benchmarks out of 6.
4 Likes
I think this summarizes what we've seen so far... Rust and Zig are in the same ballpark when it comes to performance, so the correct answer to "which language is faster?" is "it depends on how you write your code".
Both languages are languages that use LLVM to AOT compile to machine code, their standard libraries are both pretty well written, and both let you write code as fast/slow as you want.
As many people have mentioned, performance is a lot more nuanced than "language X is faster than Y". It's naive to expect anything more precise than rules of thumb and ballpark figures. The micro-benchmarks you often see when comparing languages are almost always overly simplistic to the point of being useless for anything other than religious wars on the internet.
18 Likes
Absolutely. They tend to devolve into boring transliterations of whatever version is currently winning, regardless of whether anyone would ever write it that way in reality in the language.
8 Likes
Completely agree. Plus, with just that number "4 out of 6", that's basically two thirds of a really small sample size, whatever the population is. Basically chance.
4 Likes
learn to code with performance in mind
8 Likes
Of course, speed of a programming language always depends on
- the computational problem you address,
- the way you use the language (e.g. idiomatic code vs optimized code).
Nonetheless, I feel like it's okay to colloquially assume that some languages are slower than others. Rust with unsafe certainly is faster than safe Rust. C is faster than (pure) Python. Machine code is faster than Java (in execution time, not in development time).
"Is zig lang faster than rust?" No idea, as I haven't heard of Zig before, but it seems to be an interesting approach. Thanks to the OP @Amigo for pointing me/us to it. I think it's always good to look at other languages to see if some things can be improved (or are slower for a good reason).
Why ask a question like "Is zig lang faster than rust?" – Because Rust aims to come with little runtime overhead, so it's just natural to become curious when some other language claims to be faster in some matters and to raise such a (colloquial) question.
Speaking of overhead, I feel like Rust generally has a lot of overhead (not as in execution time at runtime or memory consumtion, but in other ways such as binary size or complexity of the compiler). Even small programs I developed in Rust quickly result in a huge dependency tree. I also found the following note from another thread interesting:
I just tried to see how big hello world (with --release) is on my FreeBSD system. It is 3.5 MB big. Comparing that to a hello world C program (with -g -O2), which is just 15 kB (and that includes debugging code).
This is where I see one of the big challenges for Rust: Rust isn't lightweight, it seems.
Note that "overhead" isn't always bad. But I find it noteworthy that a compiled hello world program in Rust is (with default options) more than 240 times bigger than a hello world C program. How about hello world in Zig?
Please insert Hello World, Disc 2, and press any key to continue.
Edit: When I use cc -O2 -g -static, I get 3.9 MB for hello world in C, so my example isn't valid. But I still think Rust binaries may be bigger than C binaries in many cases?
Edit 2: I just noticed that my 3.5 MB hello world program in Rust wasn't statically linked:
% ldd hellorust
hellorust:
libthr.so.3 => /lib/libthr.so.3 (0x8010b0000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8010dd000)
libc.so.7 => /lib/libc.so.7 (0x8010f6000)
1 Like
I believe there's been cases of the compiler being able to better optimize some safe code than an unsafe version, which was supposed to be faster. So if you're adding a bit of unsafe to squeeze out more performance, be sure to time it to make sure it actually helped!
6 Likes
In the podcast, he says the following thing about his untagged union trick:
And here's the kicker: This code is safe in Zig, because we have safety on untagged unions. We have both, it's safe. We didn't have to give up safety to accomplish this.
I have since then came across this comment that explains how this actually works:
In a safe build mode, bare unions have an extra, secret tag that the language uses to insert runtime safety checks when union fields are accessed. This causes the array of 8-byte bare unions to actually become an array of 16-byte bare unions due to 8-byte alignment. A heavy cost to pay for this runtime safety.
But we don't ship a safe build of the Zig compiler to our users. We ship a ReleaseFast build. In this build mode, bare unions do not have a secret safety tag, and they do not have runtime safety checks. Accessing the wrong field in this case is Undefined Behavior.
If you want to claim that your language does something better than Rust without giving up safety in the process, then I find it really disingenuous if it turns out that you achieved it by using a different definition of "safe" that allows for UB in optimized builds. You certainly gave up safety in comparison to Rust.
42 Likes
I wonder what it actually means for one programming language to be faster than another?
I mean, a programming language is only a specification of a syntax and a semantics of some language. Basically it determines how you can arrange characters in a file of human readable text. As such that does not have a speed. In that same way as mathematical expressions do not have a speed. They just are.
On the other hand, the intention is that that mess of characters in a file can be transformed into a pile of binary instructions that a machine can step through.
The speed of that resulting binary clearly depends on the abilities of the compiler to turn source text into efficient machine code. So we see the compiler determines the speed of the executable. Not the programming language definition.
But, seems to me that some syntax and semantics may well make it easier for the compiler to produce efficient code than some other syntax and semantics. Is it so then that the programming language definition can help or hinder the final speed of execution?
Arguably a compiler could be built to transform any source text in any language into an optimally fast executable. But is it so that it becomes more difficult for some language definitions than others? So much so that it is easier to define a more helpful source syntax/semantics than to build that super clever compiler.
Why, for example can't one compile Java, or Javascript programs into binary executables as fast as C/C++/Rust?
1 Like