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

241–250 of 251 posts

Re: Why is Rust slightly slower than C?

#241

Post by igouy »

monocasa wrote: post #240
graycat wrote: post #233

Earlier quoted context omitted.

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

> … meeting or beating Fortran…

Keep in mind that there seem to be more programmers - making more effort - to improve the C and Rust benchmarks game programs.

The Ada and Fortran programs don't get the same work and improvement.

Re: Why is Rust slightly slower than C?

#242

Post by Quekid5 »

harry8 wrote: post #227
Quekid5 wrote: post #188

Earlier quoted context omitted.

> The correct response is always: "Show the benchmark numbers and make your case that the trade off is worth it." Then there is discussion on how compelling a case has been made. Where do you work that allows you to implement everything twice, once in C and once in C++, for a proper comparison to be made? (I realize that's not quite what you said, but if we're going with 'benchmark', then presumably those places have…

As an example, usually there is a default C++ implementation because C++ makes things easier for the programmer so it makes sense if you're at the end of the food chain that requires perfomance (ie you're not using a memory managed language in the first place because that's easier still). So then you benchmark it thorougly. Get stuck into all the perf numbers and analysing those. You note why you think you can shave…

Are you agreeing or disagreeing?

If you're disagreeing, frankly, almost everything you said sounds like a bunch of platitudes... and I don't understand what you disagree with.

If you're agreeing, frankly, almost everything you said sounds like a bunch of platitudes... and I have no idea what your central point is.

Re: Why is Rust slightly slower than C?

#243

Post by ncmncm »

4D1 wrote: post #224
ncmncm wrote: post #122

Earlier quoted context omitted.

I have not encountered any hostility. But if you don't know how to get better performance from C++ than you can get from C and lots of extra work, you probably will not be hired, most places. It's not about hostility, it's about competence. Some places just demand competence more than others. The laughter would not be about measurable performance; you might well be able to get C code to go as fast. The laughter would…

This conversation is no longer of any benefit, but for the sake of you and your co-workers... Saying that C is predictably inferior, more expensive, and less maintainable shows a blatant amount of incompetence on how either languages operate. C++ only offers abstractions to (debatably) more easily allow for an object oriented design for codebases. Semantically everything that you can do in C++, you can do in C. There…

You say you cannot write a C++ program faster than your C program, and I believe you. I say I can, and you may believe me.

Re: Why is Rust slightly slower than C?

#244

Post by ncmncm »

kzrdude wrote: post #214
ncmncm wrote: post #140

Earlier quoted context omitted.

Low-hanging fruit. But there are still bigger fish to fry. Lower-hanging bigger fish? Rust isn't mature yet. Give it ten years. It will either exceed C performance, or fade away. It's still too early to say which.

What's the bigger things that need solving in Rust?

Compile speed. Feature completeness. Tooling maturity.

Re: Why is Rust slightly slower than C?

#245

Post by harry8 »

Quekid5 wrote: post #242
harry8 wrote: post #227

Earlier quoted context omitted.

As an example, usually there is a default C++ implementation because C++ makes things easier for the programmer so it makes sense if you're at the end of the food chain that requires perfomance (ie you're not using a memory managed language in the first place because that's easier still). So then you benchmark it thorougly. Get stuck into all the perf numbers and analysing those. You note why you think you can shave…

Are you agreeing or disagreeing? If you're disagreeing, frankly, almost everything you said sounds like a bunch of platitudes... and I don't understand what you disagree with. If you're agreeing, frankly, almost everything you said sounds like a bunch of platitudes... and I have no idea what your central point is.

I felt it a reasonable answer, if you think not I probably can't help you. I have no idea what you think I'm aggreeing or disagreeing with. Did you reply to the wrong comment?

Re: Why is Rust slightly slower than C?

#246

Post by jcelerier »

ZoomZoomZoom wrote: post #234
jcelerier wrote: post #211

Earlier quoted context omitted.

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.

yes, that is mostly what I'm doing. and I hate waiting 5 minutes for a track to be frozen.

Re: Why is Rust slightly slower than C?

#247

Post by iopq »

haberman wrote: post #219
imtringued wrote: post #201

Earlier quoted context omitted.

Bounds checking is not an abstraction. Therefore you are the one who is twisting the word "zero-cost abstraction" to cover things it doesn't cover.

GC isn't an abstraction either. By that argument, you could claim that you have zero-cost abstractions even if you have stop-the-world GC.

It does abstract over memory management quite a bit taking out the implementation details. What is an abstraction?

Re: Why is Rust slightly slower than C?

#248

Post by maxk42 »

mlindner wrote: post #86
maxk42 wrote: post #44

The two biggest factors involved are (1) Runtime. Even though C has "no" runtime, there is some runtime overhead: Variable allocation / de-allocation and alignment. Function invocation / call stack setup. Et cetera. I don't know enough about Rust to understand what its exact "runtime" is like, but I'd bet it's not exactly like C. (Rust is strongly-typed, is it not? Does it do run-time type-checking?) Exception handli…

Please don't answer the question if you don't know enough to answer it. Rust doesn't have exception handling. Rust doesn't have a runtime.

Yes, rust has a runtime. Even most assemblers have runtimes these days.

Take a look at this: https://imgur.com/lPOPj1G

You see that difference? That's not rust producing less-efficient code. That's the more complex rust runtime.

Think it's an artifact of static linkage? Guess again.

https://imgur.com/KsrApXC

But IIRC rust doesn't statically link glibc by default.

So the difference in runtime overhead is more than 10x the machine code size. That doesn't translate to a 10x slowdown and a lot of that is probably baked-in optimization but rust certainly has a runtime and associated overhead and it has a lot larger runtime than C.

Re: Why is Rust slightly slower than C?

#249

Post by [deleted] »

maxk42 wrote: post #248
mlindner wrote: post #86

Earlier quoted context omitted.

Please don't answer the question if you don't know enough to answer it. Rust doesn't have exception handling. Rust doesn't have a runtime.

Yes, rust has a runtime. Even most assemblers have runtimes these days. Take a look at this: https://imgur.com/lPOPj1G You see that difference? That's not rust producing less-efficient code. That's the more complex rust runtime. Think it's an artifact of static linkage? Guess again. https://imgur.com/KsrApXC But IIRC rust doesn't statically link glibc by default. So the difference in runtime overhead is more than 10x…

[deleted]
Post reply on HN