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

Speed of Rust vs. C

kornel.ski

Post reply on HN
Print view View original

91–100 of 546 posts

Re: Speed of Rust vs. C

#91

Post by brwell »

> "Clever" memory use is frowned upon in Rust. In C, anything goes.

No, it does not. If Rust programmers don't have discipline in C, other people have.

And don't drag out some random CVE numbers again. These are about a fraction of existing C projects, many of them were started 1980-2000.

It is an entirely different story if a project is started with sanitizers, Valgrind and best practices.

I'm not against Rust, except that they managed to take OCaml syntax and make it significantly worse. It's just ugly and looks like design by committee.

But the evangelism is exhausting. I also wonder why corporations are pushing Rust. Is it another method to take over C projects that they haven't assimilated yet?

Re: Speed of Rust vs. C

#92

Post by riquito »

pmarin wrote: post #89
Animats wrote: post #26

"But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…

Without real world data "fearlessly parallelizing all the things!" is an awful idea due to all the overhead involved. The most important design decision while writing a parallel algorithm is to decide for what amount of data is not worth it.

He tried with few effort and noticed that for his use case the code is faster, I fail to understand this rebuttal of the parent's comment

Re: Speed of Rust vs. C

#93

Post by fulafel »

NobodyNada wrote: post #37
waterhouse wrote: post #30

Earlier quoted context omitted.

That is nice, although I think Heartbleed was due to a missing bounds check enabling the reading of adjacent memory, not due to reusing the same buffer...

If my memory is correct: yes, the root cause was a missing bounds check, but the vulnerability was much worse than it could have been because OpenSSL tended to allocate small blocks of memory and aggressively reuse them — meaning the exploited buffer was very likely to be close in proximity to sensitive information. I don’t have time right now to research the full details, but the Wikipedia article gives a clue: > Th…

That's what happens by using normal malloc/free anyway, no? Implementations of malloc have a strong performance incentive to allocate from the cache hot most recently freed blocks.

Re: Speed of Rust vs. C

#94

Post by mfru »

brwell wrote: post #91

> "Clever" memory use is frowned upon in Rust. In C, anything goes. No, it does not. If Rust programmers don't have discipline in C, other people have. And don't drag out some random CVE numbers again. These are about a fraction of existing C projects, many of them were started 1980-2000. It is an entirely different story if a project is started with sanitizers, Valgrind and best practices. I'm not against Rust, exce…

> It is an entirely different story if a project is started with sanitizers, Valgrind and best practices.

What are the agreed upon tools and best practices in the C community as of right now?

Re: Speed of Rust vs. C

#95

Post by [deleted] »

riquito wrote: post #92
pmarin wrote: post #89

Earlier quoted context omitted.

Without real world data "fearlessly parallelizing all the things!" is an awful idea due to all the overhead involved. The most important design decision while writing a parallel algorithm is to decide for what amount of data is not worth it.

He tried with few effort and noticed that for his use case the code is faster, I fail to understand this rebuttal of the parent's comment

[deleted]

Re: Speed of Rust vs. C

#96

Post by Lvl999Noob »

scorpion95 wrote: post #90
Animats wrote: post #26

"But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…

Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…

The author did say that there is nothing that Rust does that C cannot. The difference is that in Rust, those things are easier, or many times, the default way, while in C, you would have to take care of way too many things to make sure things work.

Re: Speed of Rust vs. C

#97

Post by truckerbill »

jandrewrogers wrote: post #55
CJefferson wrote: post #48

Earlier quoted context omitted.

I don't understand -- isn't what you are suggesting single threaded async code? That might be useful for servers, where you are mostly waiting for other things (like databases and networks), but in ithe places the point of parallel is to get all your CPUs doing useful work, and then (in my experience, happy to be shown counterexamples), coroutines aren't very useful. You just want to blast a bunch of threads (or righ…

Yes, roughly single-threaded async, with each core running a disjoint subset of the workload on data private to that core. You can’t beat the operation throughput. The software architecture challenge is shedding load between cores, since this will hotspot under real workloads with a naive design. Fortunately, smoothly and dynamically shedding load across cores with minimal overhead and latency is a solved design prob…

Do you know of any resources to learn more about this approach?

Re: Speed of Rust vs. C

#98

Post by gridspy »

scorpion95 wrote: post #90
Animats wrote: post #26

"But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…

Which form of Rust parallelism did you choose? I’ve read that the old one sucks. Certainly Rust is different beast than C. Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well? I cannot believe at first that Rust is ever more performant than C, as C could be made parallel and seems more barebones. One of the languages that CUDA can be used with is C, so I sus…

The very short version:

There are many things which cause both frequent and rare strange crashes in multi-threaded code.

In C, all these things will compile OK. In safe Rust, practically none of them will compile.

It is much easier to fix compile issues in Rust to do with dangerous memory usage or thread sharing than it is to debug a compiled program.

Re: Speed of Rust vs. C

#99

Post by eptcyka »

jandrewrogers wrote: post #29
oivey wrote: post #8

Earlier quoted context omitted.

> As an observation, performance optimized code is almost always effectively single-threaded these days, even when using all the cores on a CPU to very efficiently process workloads. Not my experience at all. One big problem is that most languages in 2021 have very, very poor support for thread-based parallelism. It’s crazy how many languages make it hard to do basic data parallel tasks. That steers people toward wri…

Parallelism in 2021 should not be tightly coupled across threads if performance matters, the limitations of that model are well-understood. There is no way to make that comparatively efficient; the CPU cache waste alone ensures that. Nothing you can do with thread support in a programming language will be competitive with e.g. a purpose-built scheduler + native coroutines. That’s right up against the theoretical limi…

You are mistaking parallelism for concurrency.

Re: Speed of Rust vs. C

#100

Post by gridspy »

vlmutolo wrote: post #4

> "Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). This made me laugh

> in C I'd be tempted to reuse a buffer allocated for one purpose

... In rust I'd just declare an enum for this. Enums in Rust can store data. In this way they are like a safe union.

Post reply on HN