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

301–310 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#301

Post by pjmlp »

FartyMcFarter wrote: post #223
pjmlp wrote: post #171

Earlier quoted context omitted.

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.

Yeah, but isn't due to the language, rather to the amount of people that have spent money and resources to implement compilers for all those CPUs and OSs.

Original C was created after UNIX already existed, used for UNIX's first rewrite and until UNIX source code left Bell Labs, it only worked on PDP-11 computers.

Re: Rust is now overall faster than C in benchmarks

#302

Post by pjmlp »

FartyMcFarter wrote: post #252
Someone wrote: post #246

Earlier quoted context omitted.

Devil’s advocate: compared to assembly, C is portable, but compared to a lot of high-level languages, C isn’t very portable. Every “implementation defined” feature ( https://en.wikipedia.org/wiki/Unspecified_behavior#Implement... ) creates two different languages (examples are sizes of basic numeric types, signedness of the char type, and evaluation order of arguments) Also, the standard library is so limited that, h…

> compared to a lot of high-level languages, C isn’t very portable. Right, with C, you may have to fix a few bugs to get a program working properly in a new system due to the reasons you mention. But with many other languages, you'd have to port a compiler and the standard library first, which is probably harder :)

Depends on the language, luckily other languages are equality blessed in portability as other people have spent similar resources making their toolchains available elsewhere.

Re: Rust is now overall faster than C in benchmarks

#303

Post by josephg »

steveklabnik wrote: post #237
burnthrow wrote: post #232

Earlier quoted context omitted.

This topic is of great interest to me, do you know if there is any related official or community documentation on using arena allocation (and the problems you mentioned) in Rust? I've only found https://doc.rust-lang.org/1.1.0/arena/index.html

Crates like https://crates.io/crates/typed-arena and https://github.com/fitzgen/bumpalo are the way you do this in today’s Rust, but what he’s referring to is that types like String manage their own allocations and aren’t yet parameterizable by an allocator. So they’re not super easy to use together. In my experience most of the time you need arenas you’re using your own data structure anyway, but YMMV.

> In my experience most of the time you need arenas you’re using your own data structure anyway, but YMMV.

That makes sense for video games. Recently I was goofing with cyrus-imap. I wanted to parse the emails out of an mbox file into JSON (JMAP). Parsing an email with cyrus currently does about 5-10k calls to malloc, but the objects are all extremely short lived - they just have to live long enough to parse and then convert to JSON. This is a perfect case for a bump allocator - I'd love to allocate all the parsed email fields into an arena and then clear the whole thing when we move on to the next message.

Yes, Cyrus uses a ton of its own internal structs for emails, and they're littered with strings and vectors. (Eg for email headers, lists of email recipients, plain text / HTML message content, etc).

Looks like bumpalo will do the job, since it implements its own Box, Vector and String. I understand why, but it seems jarring that I'd need to replace the data types in order to change out the allocator like this. I'm definitely keen for GAT landing if it means bumpalo and friends don't need to reinvent the world to be able to change the allocation strategy.

Edit: Oooh Vec::new_in is in nightly! Exciting! https://doc.rust-lang.org/beta/std/vec/struct.Vec.html#metho...

Re: Rust is now overall faster than C in benchmarks

#304

Post by slavik81 »

joshuamorton wrote: post #258
loup-vaillant wrote: post #255

Earlier quoted context omitted.

> In my opinion, hash tables, btrees and the like in the standard library should probably swap to flat lists internally when the number of items in the collection is small. I'm surprised more libraries don't do that. If I recall correctly, the STL provides guarantees that prevents it from taking advantage of flat lists. I think some containers (not arrays) guarantee that they don't move the address of whatever they'r…

I seem to recall some of this related to absl's flat_hash_map and co. They can't be stdlib compatible because there are api concerns that the std implementations provide (but that in practice no one uses) that result in real world performance being left on the table.

Specifically, the bucket interface: https://en.cppreference.com/w/cpp/container/unordered_map#Bu...

Re: Rust is now overall faster than C in benchmarks

#305

Post by londons_explore »

mrec wrote: post #54
londons_explore wrote: post #43

Earlier quoted context omitted.

I do some graphics stuff. As soon as you get to "this chunk of code needs to be run for every pixel of every 4k frame at 60fps", suddenly the number of clock cycles and registers matters... Some of my platforms don't have GPU's, so it really is squeezing everything possible out of the language and compiler...

I'm curious, what platforms support 4K output but don't have any kind of GPU?

AWS... When you're cheap and don't want to pay for a GPU. Or a bunch of other cloud providers that don't support GPU's at all.

Re: Rust is now overall faster than C in benchmarks

#306

Post by notorandit »

dodobirdlord wrote: post #234
notorandit wrote: post #141

I am not sure I can buy such a comparison. Someone smarter than me already argued about test implementations. Someone else also put compilers and interpreters into prospective. Of course language expressiveness can gauge in but, IMHO, comparing the same sort algorithm or the same hash table implementation (or n-queens algo) could make much more sense especially with comparable compilers. If Rust implementation is fat…

The Rust language specifically gives more information and thus more optimization opportunities to the compiler. Plus, when comparing Rust code compiled with rustc and C code compiled with Clang, both are using LLVM as the compiler backend, so what primarily comes into play is how expressive each language is, and how idiomatic it is to write code that will be optimized by the compiler. Both C and Rust are capable of j…

OK. So you say that implementations are the same within the respective language capabilities and that the Rust compiler frontend is inherently better than C's thanks to the language expressiveness? Still sounds weird to me, unless the test programs use very different approaches, like parallel programming...

Re: Rust is now overall faster than C in benchmarks

#307

Post by AmericanChopper »

josephg wrote: post #211
michaelmior wrote: post #150

Earlier quoted context omitted.

> null terminated strings feel like idiomatic C to most people Doesn't that mean that null terminated strings is idiomatic C? That is, my understanding of the term idiomatic is that it is defined by whatever is most natural to users of a language regardless of whether it is the most performant.

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…

My go to troubleshooting method for open source tools I use is to just read the code to figure out what it’s doing (if I can’t quickly figure it out from the documentation). I’ve certainly learnt a lot from doing it, and I’ve even written patches for tools written in all sorts of languages that I’d never used before. The first time I ever wrote Rust and Go code, I was patching bugs in open source projects that I needed to have fixed.

Re: Rust is now overall faster than C in benchmarks

#308

Post by pjmlp »

roca wrote: post #207
littlestymaar wrote: post #195

Earlier quoted context omitted.

> If C# and Go preclude 95% of the errors found in Python and JS Well Go and C#[1] still suffer from the billion dollar mistake (null pointers), which represents at least 1/3 of errors I've witnessed in JavaScript code, so I'd say they at best removes 70% of errors. And there's also logic errors, for which neither Go's or C#'s type system helps either, so maybe we're at 50% error reductions with Go and C# compared to…

Newtypes are also pretty great for detecting logic errors. (You can use them in Go and C# but they're not idiomatic and usually not zero-cost so people usually don't.)

Besides the sibling answer about Go, when you are in .NET world there are also F# and C++/CLI to chose from, so C# doesn't stand alone (leaving VB.NET out as it appeals other kind of developers).

Re: Rust is now overall faster than C in benchmarks

#309

Post by pjmlp »

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…

I agree, however from my experiences with lifetime checkers in VC++, it will still take a couple of more years to make it work properly and hardware memory tagging as being pushed by Oracle, Microsoft, Apple, Google and ARM is still a couple of years away to be deployed everywhere.

Re: Rust is now overall faster than C in benchmarks

#310

Post by pjmlp »

sitkack wrote: post #249
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.

As soon as the libraries are RiiR, then the Rust compiler can optimize across those library calls.

Looking at the progress of Rust/WinRT, and C++ renaissance thanks to GPGPU computing and mobile OSes stack, that is still a couple of decades away.

And then there are the whole LLVM and GCC based eco-systems.

Post reply on HN