Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

61–70 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#61

Post by jandrewrogers »

jolux wrote: post #11

I think benchmarking C vs C++ vs Rust must only really be useful for researchers. They’re all making a similar tradeoff for performance: forcing you to consider how you use memory. Does anyone work in a field where the performance difference between these specific three platforms matters? I’m genuinely curious. Edit: also, if you could explain briefly why and what makes particular choices out of the three unsuitable,…

It matters for real-world software development, though the reason may not be intuitive. In theory, for any particular bit of software, you can write code in any of these three languages that has nearly identical performance. In practice, the complexity of expressing equivalent performance can vary considerably depending on what you are trying to do.

There are finite limits to the complexity cost developers are willing to pay for performance. Because the cost in each of these three languages is different to express some thing, sometimes there will be a threshold where in one or more of these languages most developers will choose a less optimal design. This manifests as practical performance differences in real software even though in theory they are equally expressive with enough effort.

This comes with another tradeoff. Efficient expressiveness relative to software performance comes at a cost of language complexity. C is a simple language that has enough efficient expressiveness for simple software architectures. C++ is at the extreme opposite; you can do mind-boggling magic with its metaprogramming facilities that can express almost anything optimally but god help you if you are trying to learn how to do this yourself. Rust sits in the middle; much more capable than C, not as expressive as C++.

This suggests the appropriate language is partly a function of the investment a developer is willing to make in learning a language and what they need to do with it. Today, I use modern C++ even though it is a very (unnecessarily) complex language and write very complex software. Once you pay the steep price of learning C++ well, you acutely feel the limitations of what other languages can't express easily when it comes to high performance software design.

I used to write a lot of C. It still has critical niches but not for high-performance code in 2021, giving up far too much expressiveness. C++17/20 is incredibly powerful but few developers really learn how to wield that power, though usage of it has been growing rapidly in industry as scale and efficiency have become more important. Rust is in many ways an heir apparent to C and/or Java, for different reasons. Or at least, that is how I loosely categorize them in my head, having a moderate amount of contact with all three. They all have use cases where you probably wouldn't want to use the others.

Re: Rust is now overall faster than C in benchmarks

#63

Post by jeffbee »

ma2rten wrote: post #58

I'm having a hard time making sense of this page. Why is this comparing fastest implementation with slowest implementation? Why is the metric busy time/least busy? Why is C++ so much better than C?

Speaking generally and about no specific program, you should expect C++ to be faster than C. C++ has more ways for the programmer to communicate with the compiler.

Re: Rust is now overall faster than C in benchmarks

#64

Post by FartyMcFarter »

Looking at the reverse-complement code, it appears that the Rust and C implementations are using different algorithms:

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

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

On a quick inspection:

- The Rust code is about twice as long.

- The Rust code has CPU feature detection and SSE intrinsics, while the C code is more idiomatic.

- The lookup table is larger in the Rust code.

Re: Rust is now overall faster than C in benchmarks

#65

Post by lmilcin »

Which is not at all surprising. Rust has much larger compilation unit and knows more about what can read/write a particular piece of memory. This allows some occasions for optimization where C compiler must be conservative.

An example of simpler version of this is Fortran that can be faster for numerical loads due to the fact that Fortran disallows aliasing of function arguments. C on the other hand, must pay the price of having to be conservative with how it treats arguments just in case they overlap.

Re: Rust is now overall faster than C in benchmarks

#66

Post by steveklabnik »

mlyle wrote: post #47
fmntf wrote: post #41

Earlier quoted context omitted.

If that's possible, why should not binaries be small (without too many downsides, eg execution speed) by default?

A big part of why binaries are "big" is dynamic linking and external symbols. That Rust hello world is just hand-crafted to never be linkable to anything else at runtime and invoke a system call with a buffer. This isn't really how we'd like to do most things.

Interestingly enough, I would say that dynamic linking makes binaries smaller, that code no longer lives in the binary, but another place instead.

Re: Rust is now overall faster than C in benchmarks

#67

Post by [deleted] »

stabbles wrote: post #53
Svetlitski wrote: post #49

Once LLVM fixes some bugs with `noalias`, at which point Rust will begin using it again in more circumstances [1], I'd expect to see Rust get even faster in these benchmarks, given that the Rust compiler knows much more about which pointers do/do-not alias than most other programming languages [2] and the myriad optimizations this knowledge allows. [1] https://github.com/rust-lang/rust/issues/54878#issuecomment-... […

I doubt there's any performance to be gained that way, but if so, the C implementation can just use `restrict` to the same effect.

[deleted]

Re: Rust is now overall faster than C in benchmarks

#68

Post by tetromino_ »

yudlejoza wrote: post #8

When Rust is faster than C in a benchmark in which C++ is also faster than C, I know I can safely ignore such benchmark.

The problem is not with C the language, but with the C standard library, which has many inefficiency warts. Examples:

* Strings. Any form of string access other than scanning the string's characters one by one from start to finish can benefit from knowing the string's length in advance. In C++, std::string and std::string_view know their lengths; plain C strings don't. Thus, in performance-optimal plain C, almost any function that takes a string parameter ought to also take the string length as a separate parameter - but most C standard library functions neglect to do so.

* Callbacks. When the callback is static, you want to give the compiler the opportunity to inline it into the call site. In C++, this is natural: pass the callback as a template parameter. In performance-optimal C, you'd want to provide macro version of functions that take callbacks. But the C standard library only supports callbacks as function pointers (e.g. in bsearch(3), qsort(3) etc.), which means unnecessary pointer dereferences and which makes inlining impossible.

Re: Rust is now overall faster than C in benchmarks

#69

Post by arcticbull »

alerighi wrote: post #51
arcticbull wrote: post #42

Earlier quoted context omitted.

Rust can be faster than C because in general C compilers have to assume that pointers to memory locations can overlap (unless you mark them __restrict). Rust forbids aliasing pointers. This opens up a whole world of optimizations in the Rust compiler. Broadly speaking this is why Rust can genuinely be faster than C. Same is true in FORTRAN, for what it's worth.

Well you are saying that even in C you can use the restrict keyword to tell the compiler that 2 memory locations can overlap. Of course is in the hand of the programmer to tell the compiler to do so. I don't think there is a fair comparison between Rust and C: C is just an higher level assembler, if the programmer knows what he's doing he can use the hardware 100% of its potential. That is the reason why C is still u…

I think you'd be hard pressed to find more than a handful of usual C programmers, even in embedded, who know what the __restrict keyword does, let alone are rigorous in its application.
Post reply on HN