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

421–430 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#421

Post by creato »

pjscott wrote: post #381
creato wrote: post #274

Earlier quoted context omitted.

I would be shocked if those two programs performed the same. C and Rust are using the same compiler backend, better aliasing information probably isn't going to make that big of a difference. Are you sure the rust performance data isn't for one of the other implementations that use the same crufty tricks as the C version? e.g.: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... , https://benchmarksgame-t…

It's pretty startling, but yes, that non-crufty version is "Rust #8" that tops the n-body performance lists: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It looks like the autovectorizer did a really good job on this one.

It also looks like this version is using an algorithm that none of the others use: it precomputes the distance pairs for all bodies. Some of the others precompute the vectors between the pairs, but that's not the expensive part of computing the distance.

As an aside: this made me notice this n-body simulation only has 5 bodies! This is a pretty strange case that makes these O(n^2) optimizations practical. The n-body simulations I've been familiar with in the past had thousands of bodies, where this approach probably isn't a good idea.

Re: Rust is now overall faster than C in benchmarks

#422

Post by leetcrew »

jstimpfle wrote: post #414
leetcrew wrote: post #292

Earlier quoted context omitted.

> Likewise, I believe I have heard of small string optimisation being impossible with std::string for similar reasons. not impossible, SSO is implemented to some extent in most mainstream c++ compilers.

I thought that was impossible because it breaks references when moving strings.

I don't see why this would happen. what problems are you envisioning? moves should leave the original object in a valid but unspecified state. that is, a move should not break a reference to the original object itself, but there are no guarantees as to what data it contains afterwards. in the case of a dynamically allocated string, the moved-from object would probably be empty. with SSO, a move is necessarily a copy, so the moved-from string could either be empty or just contain stale data.

are you maybe thinking of iterators? you have to assume iterators are invalid after a move.

Re: Rust is now overall faster than C in benchmarks

#423

Post by ncmncm »

bluecalm wrote: post #358
ncmncm wrote: post #300

Earlier quoted context omitted.

When a Rust program is faster than the matching C program, it is utterly nonsensical to attribute its speed to C. It is gratifying to see C++ identified, here, as the hands-down fastest implementation language, but odd to see Rust performance still compared, in the headline, to C, as if that were the goal. The headline should say that Rust speed is approaching C++ speed. In principle, Rust speed should someday exceed…

Your claims contradict my experience. One example: C re-write of a popular chess engine Stockfish (written in C++) is significantly faster (10%-30% depending on who measures it at which time and on what hardware). This is a piece of code which was already heavily optimized for many years as speed is critical for the engine's performance. One guy (although very talented one) re-wrote it in C and got the speed gains. A…

This is implausible on its face.

If your new C program is faster than your old C++ program, then you may simply rename files from ".c" to ".cc". Then, you have two C++ programs, one faster than the other.

If your custom hash table really is faster than any library you find, congratulations! Recoding its interfaces, without giving up any performance, you can make it available for use in other C++ programs. As one may deduce, this has already happened, and has produced the better hash table libraries you appear not to know about. Available C++ hash table libraries have benefit of overwhelmingly more optimization attention than could be afforded on behalf of a single program, and they deliver that performance to all dependent programs.

Every programming project is an exercise in practical economics: your strictly-limited available attention goes where you choose. The greater productivity of coding in a more powerful language frees up attention that may then be allocated to areas that would otherwise suffer neglect. Whatever amount of attention you devote to making code in a poor language work at all, you may spend a fraction of coding in a better language, and the balance on other beneficial uses, such as better performance.

That the new program is faster than the old program reliably demonstrates that the old program was not so well optimized as you suggest. (Your comment elsewhere, that "the whole project uses only [a] minimal set of C++ features" reveals perhaps more than you intended.) One may surmise that the old program's authors spent more of their limited attention on its effectiveness at playing chess than the latter program's author needed to.

That the third, assembly-language program is faster still demonstrates that the previous programs left performance on the table. My experience is that it is not hard to double the speed of a typical program just by paying attention to cache and pipeline effects. Most likely, the asm coder just happens to know more about those effects, knowledge that could as well have been applied to the others. Most programs seem fast enough exactly until another, faster one comes along; then they are instantly slow.

Re: Rust is now overall faster than C in benchmarks

#424

Post by JZerf »

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'm the author of that C program. You are correct that the programs are using somewhat different algorithms (and as an author for many other submissions on the site, I can say this is true for many of the benchmarks on the site).

In addition to what you've already mentioned, if I'm not mistaken, the programs also take different multi-threading approaches. One of the tasks in this benchmark involves reversing three very large strings. My C program took a fairly simple approach and does that reversal process for each string serially but processes multiple strings in parallel. The Rust program on the other hand does the opposite and does the reversal process for each string in a parallel manner but only processes strings one at a time. The algorithm the Rust program uses is more complicated which results in a considerably larger program size that also is a bit less flexible regarding the input (it assumes each line of input is 60 characters whereas my program will work with lines of any length) but it results in better CPU utilization, less clock time, and less memory use. I've been meaning to submit a faster C program using this faster algorithm but have simply been too busy with other things.

Re: Rust is now overall faster than C in benchmarks

#425

Post by JZerf »

wuxb wrote: post #321

Just took a quick peek at the binary-trees C code. Why using openmp while the others don't? why use recursive functions? The C implementation is not correctly optimized. People just paid more attention to Rust and other languages. Rust can be as fast as C, but "faster" is really misleading. BTW, I use clang all the time since it's better than GCC.

You're probably referring to the C program I submitted.

OpenMP is only available for C, C++, and Fortran so that is why most programs won't use it. However most of the other programming languages have their own ways for doing multi-threading and many of the programs for this benchmark do make use of them.

The rules at https://benchmarksgame-team.pages.debian.net/benchmarksgame/... request that submitters use the same algorithms as existing programs and I try to follow that rule. I believe all the binary-trees programs are using recursive functions so naturally I did the same to avoid breaking the rule about using different algorithms.

Re: Rust is now overall faster than C in benchmarks

#426

Post by JZerf »

Tade0 wrote: post #345
wuxb wrote: post #321

Just took a quick peek at the binary-trees C code. Why using openmp while the others don't? why use recursive functions? The C implementation is not correctly optimized. People just paid more attention to Rust and other languages. Rust can be as fast as C, but "faster" is really misleading. BTW, I use clang all the time since it's better than GCC.

It seems that someone simply tacked openmp on without checking if it actually increases performance in this case - which is unusual, because I remember a course in college, part of which was a project aiming to teach the student that openmp is not a silver bullet and should be used only when it actually helps.

I submitted the C binary-trees program. I did check to see if OpenMP increased the performance and it most certainly does. Just looking at the CPU and clock time usage on https://benchmarksgame-team.pages.debian.net/benchmarksgame/... you can see that the clock time used is about one third of the CPU time that was used.

Re: Rust is now overall faster than C in benchmarks

#427

Post by JZerf »

infoseek12 wrote: post #226

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 depe…

I wrote that program in the hope that it would better illustrate why some of the benchmarks on the site aren't very good since for some benchmarks the program performance is highly dependent on the libraries being used and not the programming language implementation itself. I know at least one person opened an issue regarding this on the site issue tracker at https://salsa.debian.org/benchmarksgame-team/benchmarksgame/... and I also believe I recall one of the Rust regex crate developers mentioning this too.

I know that using PCRE2 in a Python program isn't typical but the Benchmarks Game does allow using other libraries and many of the previously submitted programs have been doing this for a long time already. The pidigits benchmark is the other benchmark that is heavily dependent on the libraries being used as is illustrated by their being a nearly ten way tie for second place by a bunch of programs that all use GMP.

Re: Rust is now overall faster than C in benchmarks

#428

Post by pjmlp »

greyhair wrote: post #405
enedil wrote: post #362

Earlier quoted context omitted.

This is not true. Undefined behaviour can mean that ``` bool b; if (b) printf("1 "); if (!b) printf("2 "); ``` might print `1 2 `.

It's not like that is hard to fix, and modern compilers will flag uninitialized variables. Use your brain and use your tools. C is not really that hard for a large number of problem sets.

Yet, CVE database is full of well known companies that apparently lack such developers.

If their salaries cannot find them, where are they?

Do we have a candidate to prove their secure reports as being wrong?

Re: Rust is now overall faster than C in benchmarks

#429

Post by aldonius »

jstimpfle wrote: post #411
littlestymaar wrote: post #204

Earlier quoted context omitted.

> The reason that C programs often don’t perform as well as an equivalent rust program[1] 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 Brian Cantrill talks[1] about exactly this: in his C version he was using AVL trees because they are eas…

So he's comparing the AVL tree he wrote himself to a B-tree optimized to death by someone else? Out of interest though, does he mention somewhere which actual implementation he used?

Yes, and I suppose that's some of the point: a performant library ecosystem is one hell of a feature.

Re: Rust is now overall faster than C in benchmarks

#430

Post by indolering »

harporoeder wrote: post #2

I was wondering if perhaps this was actually measuring a difference between LLVM and GCC, but they also provide a set of benchmarks of C Clang vs C GCC (1) and Clang is generally slower in those test. Although there is some correlation between the ones Clang wins in C And Rust. 1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The Rust vs C Clang comparison [1] has Rust winning on every benchmark except pidigits, and that's only by .01 seconds. Memory usage and binary size is competitive as well.

[1]: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Post reply on HN