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

351–360 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#351

Post by pjmlp »

jcelerier wrote: post #344
pjmlp wrote: post #176

Earlier quoted context omitted.

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.

> you mean 90's style C++ GUI frameworks inheritance are no longer idiomatic in modern C++ I mean, as much of a Qt user I am, that's definitely the case. All the libs you listed are still around, but no one writes new libraries in that style (sometimes at a performance cost, e.g. using a ton of std:: function instead of virtuals)

Right,

https://microsoft.github.io/microsoft-ui-xaml/

https://developer.apple.com/documentation/driverkit

https://www.khronos.org/registry/SYCL/

https://developer.nvidia.com/optix

https://docs.unrealengine.com/en-US/ProgrammingAndScripting/...

I could keep adding a couple more, but I think you got the point by now.

Re: Rust is now overall faster than C in benchmarks

#352

Post by MaxBarraclough »

pjmlp wrote: post #335
typedef_union wrote: post #320

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 Reliability is very often the name of the game with C, and part of the reason you might see it written in…

The irony is that most C developers rebelled against Pascal and similar languages for being programming with a straitjacket, and in the end need to comply with MISRA-C and similar security enforcement regulations to ship anything worth using when human lives are at risk.

And even MISRA C isn't enough to assure the absence of undefined behaviour.

C is a tricky beast to tame.

Re: Rust is now overall faster than C in benchmarks

#353

Post by tormeh »

MaxBarraclough wrote: post #352
pjmlp wrote: post #335

Earlier quoted context omitted.

The irony is that most C developers rebelled against Pascal and similar languages for being programming with a straitjacket, and in the end need to comply with MISRA-C and similar security enforcement regulations to ship anything worth using when human lives are at risk.

And even MISRA C isn't enough to assure the absence of undefined behaviour. C is a tricky beast to tame.

Not such a big deal in embedded, where the compiler and hardware is always the same, which means that the behavior is still predictable even if undefined

Re: Rust is now overall faster than C in benchmarks

#354

Post by [deleted] »

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…

[deleted]

Re: Rust is now overall faster than C in benchmarks

#355

Post by ghostwriter »

naniwaduni wrote: post #271
spiffytech wrote: post #216

Earlier quoted context omitted.

PyPy has a JIT because using Python as the implementation language made it simple to build a runtime generator instead of a single runtime implementation, so RPython (the underlying PyPy tech) can generate a JIT and non-JIT runtime from the same source code. Conversely, the CPython team doesn't have the resources to make a JIT runtime the bespoke way that's more typical for these projects. https://morepypy.blogspot.c…

CPython isn't a JIT because its goals as a portable reference implementation would be much harder to achieve with a JIT. To put it another way, there's a reason PyPy trails CPython language features on the scale of literal years. This is not explained by the affordances of the language they're written in! They're just projects with very different requirements which, on some platforms, happen to run a lot of similar-l…

> there's a reason PyPy trails CPython language features on the scale of literal years.

the reason is under-funding, and the lack of developers to the cause as a consequence, not the portability complexities of jit.

Re: Rust is now overall faster than C in benchmarks

#357

Post by johnisgood »

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.

It is always like that. There is no way that X is faster than C. It most definitely has to do with algorithm. What I can believe is Fortran being faster than C in some circumstances, but that is about it. Can you guys please stop this nonsense? No, your equivalent Rust code is not faster, sorry.

Re: Rust is now overall faster than C in benchmarks

#358

Post by bluecalm »

ncmncm wrote: post #300
mh7 wrote: post #89

Some of the rust versions calls C libraries for its heavy lifting (gmp, pcre) so I wouldn't take this too seriously.

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. Another guy (also very talented one) re-wrote it in assembly and got even bigger speed gains (see CFish and asmFish projects)

It looks to me that you are comparing badly written C to decently written C++ and claiming speed gains. I use C for my own software(solver for a popular game) and I wouldn't dream of using stuff like "pointer chasing structures". If you need to use stuff like hash tables in your performance critical code you have to code them yourself anyway as using some generic hash and memory handling algorithm is a recipe for being slow.

Re: Rust is now overall faster than C in benchmarks

#359

Post by ghostwriter »

gameswithgo wrote: post #183
zeroimpl wrote: post #156

Earlier quoted context omitted.

That's the whole point of the metaphor - comparing apples to apples is good, apples to oranges is bad.

and its a bad metaphor. there are many reasonable comparisons to be made between any two things even when both are not fruits

Technically speaking, there are limits and you cannot compare incomparable. You can find distinctions between two phenomena, a.k.a. inherent traits that make them different-by-definition from one another, but you cannot compare (liken, collate, contrast) them in any meaningful way. Like, what's the outcome of comparing "soft" with "warm"? And hence, comparing apples to apples are not pointless, quite contrary - they are comparable items and it makes total sense to compare them in the context of superiority by desirable value axes.

Re: Rust is now overall faster than C in benchmarks

#360

Post by ghostwriter »

steinuil wrote: post #103
harporoeder wrote: post #92

Earlier quoted context omitted.

There was a long period where a fairly unknown theorem proving language ATS (1) was beating C in many test cases on the benchmark game (2) the benchmarks were removed though (3). I expect many languages could be made to win with sufficient effort. 1. http://www.ats-lang.org/ 2. http://web.archive.org/web/20121218042116/http://shootout.al... 3. https://stackoverflow.com/questions/26958969/why-was-the-ats...

ATS is not really a theorem proving language, it's almost a superset of C with a very long list of type system and language features that lets you write anything from C code with no safety to very high level recursive functional code with lifetime tracking which will translate to efficient C code, if the transformations are proved to be correct. It's a weird beast, but I'm not surprised it outperformed some C impleme…

> ATS is not really a theorem proving language

What is "real theorem-proving language" in this context? ATS has ATS/LF that is designed for writing formal proofs in the language.

http://ats-lang.sourceforge.net/DOCUMENT/INT2PROGINATS/HTML/...

Post reply on HN