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

171–180 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#171

Post by pjmlp »

FartyMcFarter wrote: post #147
fsloth wrote: post #126

Earlier quoted context omitted.

What does "idiomatic" C even mean? It's a high level assembler and as such should not limit the creativity of programmers using it. C code that pretends it does not need to care about it's platform is not idiomatic, it's just suboptimal.

By "idiomatic C" I meant any of the following: - Code that most C books/courses would teach you how to write - Portable C code (arguably portability is one of C's biggest successes!) - Code that you'd expect to find in the K&R book

One of C's biggest marketing successes.

All high level languages are portable, including some older than C.

It helps when one drags the OS the language was born on, along via parallel standards like POSIX.

Re: Rust is now overall faster than C in benchmarks

#172

Post by roca »

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.

"Just use 'restrict'" isn't as easy as it sounds. You need to only use 'restrict' where you are 100% sure pointers can't alias. Wherever you get this wrong you have introduced a subtle bug that a) only shows up in optimized code b) may or may not show up at all depending on compiler version and target architecture and c) only shows up when two pointers actually alias at runtime, which may be rare, and may be intermittent ... in other words these bugs will be hell to debug. So in fact in a large codebase it will be a lot of work to figure out where you can safely put 'restrict' and you will probably introduce some very nasty bugs. Most people aren't going to be willing to do this.

Re: Rust is now overall faster than C in benchmarks

#174

Post by saagarjha »

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…

> For the same reason Rust is the ideal language to write viruses, since it's difficult to reverse engineer.

Eh, not really.

Re: Rust is now overall faster than C in benchmarks

#175

Post by rurban »

zarkov99 wrote: post #33
skohan wrote: post #24

Earlier quoted context omitted.

How does c++ manage to win here? I'm not doubting, just curious

In he case of std::sort the C++ compiler can inline the comparison function when it generates the actual sort implementation from the std::sort template. In C the qsort implementation is fixed and must call the comparison via an indirect reference.

Don't use a libc qsort then. The compiler could generated it (but they don't even generate optimized memcmp yet).

Or the CTL is a header only STL for C, which inlines the sort function and the comparator. And because of the C++ bloat and indirect calls the C version is faster.

Inlining with macros == constexpr with templates.

You can decide which syntax you prefer.

Re: Rust is now overall faster than C in benchmarks

#176

Post by pjmlp »

jandrewrogers wrote: post #99
vitus wrote: post #74

Earlier quoted context omitted.

At the same time, a lot of those mechanics involve additional overhead (e.g. vtable lookups for dynamic dispatch per inheritance). But yes, some of these do provide hints for the compiler, e.g. constexpr, ownership semantics per unique_ptr. There's nothing stopping a human from writing equivalent C, so my suspicion is that the performance gap is primarily due to the benchmark implementation.

While nothing prevents you from writing C that will generate the equivalent code, it requires several times more lines of C than the equivalent C++. At which point, it becomes an economics discussion. C is usually a choice when pure performance is secondary to other considerations like portability. Most C++ code I see has few vtables, and what vtables exist are mostly removed by the compiler. Java-style inheritance h…

Just a small, correction, you mean 90's style C++ GUI frameworks inheritance are no longer idiomatic in modern C++.

Naturally we have to ignore that wxWidgets, Gtkmm, MFC, ATL, Qt, COM, DirectX, IO Kit, DriverKit, Skia are still around.

Re: Rust is now overall faster than C in benchmarks

#177

Post by akkartik »

michaelmior wrote: post #162
rcoveson wrote: post #158

Earlier quoted context omitted.

Null terminated strings are often called cstrings. They’re beyond idiomatic; they’re part of the C standard library.

True. I was skipping over that, but the fact that functions manipulating null terminated strings are part of the standard library is certainly a reason in itself to consider them idiomatic.

They're agreeing with you.

Re: Rust is now overall faster than C in benchmarks

#178

Post by pjmlp »

morelisp wrote: post #164
jandrewrogers wrote: post #99

Earlier quoted context omitted.

While nothing prevents you from writing C that will generate the equivalent code, it requires several times more lines of C than the equivalent C++. At which point, it becomes an economics discussion. C is usually a choice when pure performance is secondary to other considerations like portability. Most C++ code I see has few vtables, and what vtables exist are mostly removed by the compiler. Java-style inheritance h…

> Most C++ code I see has few vtables, and what vtables exist are mostly removed by the compiler. Java-style inheritance hierarchies are not idiomatic in C++. FWIW I feel like this is a fairly recent (good!) development. Up through TR/TR1 I think at least half the C++ code I saw was pretty heavy on the "Java envy" and not at all concerned about the cost of dynamic dispatch or memory allocation. Avoiding vtables was d…

Quite natural given that Java was created to be attractive to 90's C++ developers, which carried their development practices into Java.

Re: Rust is now overall faster than C in benchmarks

#179

Post by throwaway894345 »

jerf wrote: post #125
nindalf wrote: post #110

Earlier quoted context omitted.

How often does benchmark code have a function that takes two pointers that could potentially alias each other? If it's as rare as I think it is, it might not have that much of an impact on Rust's position in the benchmarks game. Still, real world performance will probably benefit from this fix so it's a positive change regardless.

I've been fairly convinced for a while that once Rust matures (which is probably fairly close to "now", but I've held this opinion for years) that it's going to have a performance advantage in real code that's going to be hard to capture in benchmarks, because it's easy in a small benchmark to be very careful and ensure that you don't have aliasing, avoid extra copies, etc. Where I expect Rust to really shine perform…

I agree with this. Benchmark code differs from real code in in that it approximates the performance ceiling for a language implementation; it's not "ordinary code" or even "somewhat optimized" but usually the most optimal code one can conceive of with little respect paid to competing concerns, like maintainability. Rust aspires to make idiomatic, maintainable code almost as performant as benchmark code by way of zero-cost abstractions; probably more so than any other language, including C and C++, and all the while keeping the ceiling high relative to other languages.

Unfortunately, I'm still of the opinion that "idiomatic Rust" is quite a lot harder to write than idiomatic Go or C# or etc, and many applications absolutely index on developer velocity and performance and quality are "nice-to-haves". Many companies are making money hand over fist with Python and JavaScript, and Go and C# are quite a lot more performant and typesafe than those languages already; Rust is better still in these areas, but returns diminish. If C# and Go preclude 95% of the errors found in Python and JS, it's not worth trading tens or hundreds of percents of developer velocity for that extra 4% or so improvement in quality (a Go developer could recoup a bit more of that 4% by writing tests in the time they save over Rust).

Of course, this is all subjective, and I've met smart people who argue with a straight face that Rust is better for developer velocity than languages like Go, so YMMV.

Re: Rust is now overall faster than C in benchmarks

#180

Post by efaref »

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…

There's a translator for C99 to (unsafe) Rust: https://github.com/immunant/c2rust

So probably you can give me any C program and I'll be able to give you an equivalent Rust program. It'll probably perform about the same, too.

Post reply on HN