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

221–230 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#221

Post by nzentzis »

walki wrote: post #143
murderfs wrote: post #127

Earlier quoted context omitted.

restrict and strict aliasing have to do with the same general concept, but aren't the same. They both have to do with allowing the compiler to optimize around assuming that writes to one pointer won't be visible while reading from another. As a concrete example, can the following branches be merged? void foo(/*restrict*/ bool* x, int* y) { if (*x) { printf("foo\n"); *y = 0; } if (*x) { printf("bar\n"); } } Enabling s…

OK thanks, indeed Clang is able to generate better assembly using __restrict__. And -O3 generates the same assembly as -O3 -fstrict-aliasing (which is not as good as __restrict__). I wish there was a C/C++ compiler flag for treating all pointers as __restrict__. However I guess that C/C++ standard libraries wouldn't work with this compiler option (and therefore this compiler option wouldn't be useful in practice).

I think C and C++ have enough problems with accidental undefined behavior already without making aliased pointers into UB.

Re: Rust is now overall faster than C in benchmarks

#222

Post by josephg »

steveklabnik wrote: post #218
josephg wrote: post #211

Earlier quoted context omitted.

One of my long standing complaints about modern programming is how rarely people read code. We don't encourage it in school, and in the workplace most people only read code written by their coworkers. It would be the equivalent of teaching people to write books without encouraging them to read anything. To break myself of the habit I started reading some well regarded programs for fun. And oh boy, have I learned a lo…

What makes you think arenas are considered unidiomatic in Rust? They’re there to be used when appropriate!

They seem unidiomatic because you have to fight the standard library to use them. Using an arena means abandoning String, Vec, Box, std::collections, and so on.

I have no problem doing that if I need to. But it feels like I'm fighting against the grain of rust more than I'd like.

Re: Rust is now overall faster than C in benchmarks

#223

Post by FartyMcFarter »

pjmlp wrote: post #171
FartyMcFarter wrote: post #147

Earlier quoted context omitted.

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.

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

Theoretically portable, maybe. But C is actually portable in practice - you can compile C code for the vast majority of CPUs and OSs.

Re: Rust is now overall faster than C in benchmarks

#224

Post by steveklabnik »

burnthrow wrote: post #203
agumonkey wrote: post #5

Earlier quoted context omitted.

After the rust blossom storm I didn't track cpp implementation evolutions.. did cpp compiler perf/libs increased or was is simply faster and still is the same ?

Was faster and is the same, checking isn't free. Not that Rust is slow. C++ is unsafe by default whereas in Rust it is opt-in (lexically scoped). The Rust implementations don't appear to use `unsafe`.

Checking can often be free, because it’s done at compile time, rather than at runtime.

Re: Rust is now overall faster than C in benchmarks

#225

Post by madacol »

vitus wrote: post #76
FartyMcFarter wrote: post #64

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…

I recall an anecdote about how Haskell actually outperformed C on various tree benchmarks because it was using a better implementation. At some point, the C programmers got fed up with the airs of superiority from Haskell programmers, ported the Haskell implementation, and reclaimed their position. I wouldn't be surprised if there's something similar happening here.

Looked at the git repo https://salsa.debian.org/benchmarksgame-team/benchmarksgame and it seems there's only one committer. So if all scripts are written by the same guy, then his biases are all over the place, and it needs more code diversity before we can arrive to any conclusion.

Am I missing something?, is there a list somewhere of the people who have contributed to this?

Re: Rust is now overall faster than C in benchmarks

#226

Post by infoseek12 »

An unrelated rant about benchmarksgame. Has anyone noticed that the Python implementation of regex beats a lot of the Rust and C implementations? That’s because it uses the PCRE2 library (written in C) which it assumes is installed on the OS. Benchmarks are always artificial but this seems like a step too far: the benchmark hardly says anything about Python and is dependent on the OS environment having the right dependences.

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

Re: Rust is now overall faster than C in benchmarks

#227

Post by dodobirdlord »

walki wrote: post #143
murderfs wrote: post #127

Earlier quoted context omitted.

restrict and strict aliasing have to do with the same general concept, but aren't the same. They both have to do with allowing the compiler to optimize around assuming that writes to one pointer won't be visible while reading from another. As a concrete example, can the following branches be merged? void foo(/*restrict*/ bool* x, int* y) { if (*x) { printf("foo\n"); *y = 0; } if (*x) { printf("bar\n"); } } Enabling s…

OK thanks, indeed Clang is able to generate better assembly using __restrict__. And -O3 generates the same assembly as -O3 -fstrict-aliasing (which is not as good as __restrict__). I wish there was a C/C++ compiler flag for treating all pointers as __restrict__. However I guess that C/C++ standard libraries wouldn't work with this compiler option (and therefore this compiler option wouldn't be useful in practice).

Likely most C code, particularly data structure code, would break if compiled with a setting that treats all pointers as restrict.

Re: Rust is now overall faster than C in benchmarks

#228

Post by blackrock »

dan-robertson wrote: post #197
Matthias247 wrote: post #93

Apart from those benchmark games a lot of real world C is a lot less performant than people think it might be. I spent a fair amount of time reviewing C code in the last 5 years - and things that pop up in nearly every review are costly string operations. Linear counts due to the use of null terminated strings and extra allocations for substrings to attach null terminators, or just deep copies because ownership can’t…

The reason that C programs often perform well is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays. In many ways, modern CPUs are particularly designed to run the machine code generated by C compilers on typical C code like this. Pointers and memo…

Fascinating. I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place.

I assume most C++ programs heavily use more of these advanced data structures, correct?

Re: Rust is now overall faster than C in benchmarks

#229

Post by platinumrad »

gameswithgo wrote: post #184
vitus wrote: post #122

Earlier quoted context omitted.

> Nobody really thinks Rust is faster than C now. The submission title would beg to differ. (I know, it explicitly calls out "benchmarks" as the context.) I think languages like Rust or Swift have significant advantages around safety over C/C++, while not sacrificing much in terms of performance. But if one language's benchmark contributors are willing to put in more effort than another's to eke out additional perfor…

go fix the c implementation then. no single person can maintain optimally implemented solutions over dozens of languages. its up to we the people to help out. you want perfectly equivalent comparisons, make it happen

I don't want perfectly equivalent comparisons. I want people to stop citing this set of imperfect ones as if they mean anything.

Re: Rust is now overall faster than C in benchmarks

#230

Post by dodobirdlord »

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…

> That is the difference between C and Rust to me: for each fast Rust program you are guaranteed that you can write an equivalent performant program in C (or assembly). Worst case scenario you use inline assembly in C and you get that.

Rust also allows inlining assembly.

> Thus the contrary cannot be true for Rust: if I give you a heavily optimized C program not always you can produce an equivalent version in Rust.

This is incorrect for the reason above. Worst case scenario you just inline assembly in Rust to reproduce exactly the same performance of any arbitrarily optimized C program.

Post reply on HN