Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Rust slightly slower than C?

github.com

Post reply on HN
Print view View original

231–240 of 251 posts

Re: Why is Rust slightly slower than C?

#231

Post by codesushi42 »

ncmncm wrote: post #126
comex wrote: post #124

Earlier quoted context omitted.

> Given a modern compiler and library, a by-value string temporary can be passed down a chain of calls with no allocations beyond the first, and returned, likewise. For calls (as opposed to returns): If you use std::move, yes. Otherwise, no. But using std::move is similar to changing the type in that it requires noticing the problem first. > Passing a reference means the optimizer cannot optimize accesses, because it…

Again, doing it wrong is Doing It Wrong. But moving can pessimize string-passing and -returning. Just write the code in the clearest way possible, and optimize hot paths where it turns out to matter, according to measurements. People have been demonstrated to be very poor at picking which those are, a priori.

Quotes about Chromium and Firefox are likewise obsolete

Yeah, because neither of those teams had any idea what they were doing, obviously. Even with C++ 11 at their disposal. But somehow, interestingly enough, you do.

Neither uses RAII, so they pay a 20-30% runtime penalty

Who knows where you pulled that number from.

I guess then, according to you at least, there are no performance penalties to be paid for any C++ language features. Please, continue to impart your knowledge and unreferenced benchmark tests on us all.

Re: Why is Rust slightly slower than C?

#232

Post by ncmncm »

monocasa wrote: post #223
otabdeveloper2 wrote: post #125

Earlier quoted context omitted.

> given the right subset of language chosen Yes, if by that you mean "idiomatic C++ as C++ programmers write it". It's the inexperienced "C/C++" (no such thing, BTW) that are 'choosing subsets', and doing it wrong 90% of the time.

> It's the inexperienced "C/C++" (no such thing, BTW) that are 'choosing subsets' That's blatantly not true. Strousup himself contributed to the joint strike fighter C++ coding standard which has things like "Allocation/deallocation from/to the free store (heap) shall not occur after initialization." which means that the STL is off the table for example. Beyond that, there's pieces like RTTI/dynamic_cast that should…

Most of the STL does no allocation. The containers allocate only at known places, permitted during initialization. They also know how to allocate from provided bespoke stores, which are permitted, in JSF code, even after initialization is done.

So, no, the STL is very much on the table, as in any competently constructed work product.

Re: Why is Rust slightly slower than C?

#233

Post by graycat »

monocasa wrote: post #209
graycat wrote: post #159

Earlier quoted context omitted.

I get it now: My view of HN just went down to the sewer: We're into the old, bitter, go out back and fight it out, religious computer language wars. And there C is one of the grand sacred subjects: C is the greatest. The greatest, best ever. The greatest, fastest of all time, never to be improved on. Pure genius. Pure gold. And C programmers are like people who climb Mount Everest barefoot with no tools and the only…

Show me the K&R spec? Oh wait, there isn't one, hence why ANSI C came up with one. And that spec defined the standard library too, back in the 80s. Fortran has always had differences between implementations to where you're generally writing for a specific compiler. PL/I evolved to PL/S, PL/SS II, PL/AS, and now PL/X with multiple breaking changes in each step. This isn't sone religious war defending C, you're just mi…

I really wasn't interested in the role of time. I was just struck that Rust was not a lot faster than C. Even with strcpy, malloc, free, etc. all compiled, C should still be slow due to essentially no support for arrays with more than one subscript. Thus I would expect that a modern language with good array support would beat C and am surprised that Rust does not.

Array support is now very old stuff; gee, now we'd like balanced binary tree support, maybe AVL trees, maybe like the C++ collection classes, but compiled and not just classes with its too much indirection. And we'd like good multi-threading support. Some of that is in the .NET languages; then they have a shot at beating C. I would expect that any language taken seriously today would beat C, the K&R version, the ANSI version, some recent version, etc.

And I'd like a lot more, e.g., some good semantic guarantees from static code analysis.

BTW in my remark above, have to swap "syntax" and "semantics" -- we have good progress on syntax but less good on the more difficult semantics.

A practical challenge is given some code, say, 100 KLOC, maybe 1 MLOC, have some static analysis that reports some useful information. Then have some transformations that have some useful guaranteed properties. If current languages do not admit such, then try to come up with a new language that does and still is easy enough to use and fast enough.

Gee, I assumed that after all these years we'd get some progress -- that Rust doesn't run circles around C is disappointing.

Re: Why is Rust slightly slower than C?

#234

Post by ZoomZoomZoom »

jcelerier wrote: post #211
ZoomZoomZoom wrote: post #155

Earlier quoted context omitted.

Fortunately for your body, this problem is easily solvable by hardware. Modern DAW's performance scales well with multithreading, for regular use cases at least.

But more cores generally means that every core frequency goes down due to heat, which means that you can do less on each individual track.

I don't know your use case, but generally, if you have so many VST processing on a single track that it loads a core of a modern CPU, it means you're doing either something really creative, sculpting a sound, or some heavy-handed audio restoration. Both are candidates for freezing/rendering to a stem. YMMV, of course.

Re: Why is Rust slightly slower than C?

#235

Post by fulafel »

CodesInChaos wrote: post #166

Currently Rust doesn't make proper use of its aliasing rules because of bugs in LLVM. This can reduce performance of code by forcing unnecessary memory accesses. As an experiment you could try the `-Zmutable-noalias=yes` option, which should enable these optimizations (but exposes you to those bugs). See [masklynn's comment]( https://news.ycombinator.com/item?id=20948779 ). In general Rust suffers a bit because LLVM…

The infinite-loop Rust issue is old, and the asm "" fix had been known for a long time. I wonder what is behind this seeming perf over correctness decision.

Re: Why is Rust slightly slower than C?

#236

Post by masklinn »

eximius wrote: post #204
masklinn wrote: post #131

Earlier quoted context omitted.

> It uses slightly more base RAM to load the binary. It's mostly vmem until / unless the data actually gets used though, no?

I don't know. I wouldn't be surprised that it loaded the whole thing. How could the OS predict how much to load (or wait on)? Waiting for a page to load just for the next function call would be hugely expensive.

> How could the OS predict how much to load (or wait on)?

The same way it does for every other bit of allocated memory: it allocates the physical page on a page fault in a valid mapping.

Re: Why is Rust slightly slower than C?

#237

Post by account42 »

kahlonel wrote: post #208
ncmncm wrote: post #75

C is the wrong language to compare to. More precisely, Rust should be able to beat C, routinely. Presumably it will, when it gets more optimizer attention. With any luck, that improvement can go into LLVM proper, and speed up many other languages besides. Why should Rust beat C? First, it does not suffer from the pointer aliasing faults C has. Second, const really means const, where in C the compiler has to assume an…

> it does not suffer from the pointer aliasing faults C has. There's a `restrict` keyword in C99. > const really means const, where in C the compiler has to assume any pointer-to-const might be use to write through Lookup what `const int *const ptr` does in C.

Look up what (int*)ptr does in C.

Re: Why is Rust slightly slower than C?

#238

Post by account42 »

steveklabnik wrote: post #93
glangdale wrote: post #59

Earlier quoted context omitted.

This, imo, is absolutely correct (it is a dark idea to have a "let's be unsafe for more performance" flag) but maybe a experimental build of the Rust compiler could have this as a configuration option? Possibly the toolchain could warn every step of the way if such a 'tainted' module is ever linked, etc. It just seems like this sort of question is going to recur, and being able to persistently track the overhead of c…

If it is implemented, it will be used. And people will put it in their own builds. We already have one “secret” escape flag feature, and people do use it, as much as we don’t talk about it and tell people not to use it when they find it.

This attitude is the best argument for not using rust I have seen so far.

Re: Why is Rust slightly slower than C?

#239

Post by Zarel »

wbl wrote: post #63
Zarel wrote: post #58

Earlier quoted context omitted.

Their initial explanation is bounds checking specifically. While most abstractions are zero-cost, bounds checking isn't. I do wish there were a way to track expectations about integer ranges in a type system, but there currently aren't.

Might I intrest you in dependent types? Sadly we don't even have a self hosted compiler yet.

I really like dependent types as a concept! But they're not really in any mainstream languages, so I haven't had much opportunity to play around with them. :(

Re: Why is Rust slightly slower than C?

#240

Post by monocasa »

graycat wrote: post #233
monocasa wrote: post #209

Earlier quoted context omitted.

Show me the K&R spec? Oh wait, there isn't one, hence why ANSI C came up with one. And that spec defined the standard library too, back in the 80s. Fortran has always had differences between implementations to where you're generally writing for a specific compiler. PL/I evolved to PL/S, PL/SS II, PL/AS, and now PL/X with multiple breaking changes in each step. This isn't sone religious war defending C, you're just mi…

I really wasn't interested in the role of time. I was just struck that Rust was not a lot faster than C. Even with strcpy, malloc, free, etc. all compiled, C should still be slow due to essentially no support for arrays with more than one subscript. Thus I would expect that a modern language with good array support would beat C and am surprised that Rust does not. Array support is now very old stuff; gee, now we'd li…

> I really wasn't interested in the role of time. I was just struck that Rust was not a lot faster than C. Even with strcpy, malloc, free, etc. all compiled, C should still be slow due to essentially no support for arrays with more than one subscript. Thus I would expect that a modern language with good array support would beat C and am surprised that Rust does not.

What do you think "array support" means to the compiler? Fortran has historically been faster just because of the the aliasing rules, but C has the restrict keyword now that brings it up to snuff there. The standard library inlining is more a hack around the fact that the c stdlib is dynamically linked, and that doesn't always make sense for heavily used functions.

I'm not really sure where you got this idea that C is a low bar. For instance here's C meeting or beating Fortran on every benchmark except one (where statistically they're probably tied). https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Post reply on HN