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

131–140 of 546 posts

Re: Speed of Rust vs. C

#131

Post by rcxdude »

saagarjha wrote: post #86
NobodyNada wrote: post #37

Earlier quoted context omitted.

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…

Until very recently, memory allocators were more than happy to return you the thing you just deallocated if you asked for another allocation of the same size. It makes sense, too: if you're calling malloc/free in a loop, which is pretty common, this is pretty much the best thing you can do for performance. Countless heap exploits later (mostly attacking heap metadata rather than stale data, to be honest) allocators h…

True of the more common ones, but it should be acknowledged that OpenBSD was doing this kind of thing (and many other hardening techniques) before heartbleed, which was the main reason Theo de Raadt was so upset that they decided to circumvent this, because OpenBSD's allocator could have mitigated the impact otherwise.

Re: Speed of Rust vs. C

#132

Post by pjmlp »

gridspy wrote: post #103
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…

> The evangelism is exhausting. My best guess is that people who are "stuck" working in C or C++ wish they could use Rust at their Jobs. Or that others would make the leap and get over the learning curve.

Not until it reaches the same level as Visual Studio, Android Studio, QtCreator, XCode, CUDA and SYSCL tooling for graphical applications and GPGPU.

For anything else managed languages are a much more productive option, other than writing kernel and drivers.

Re: Speed of Rust vs. C

#133

Post by pjmlp »

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…

Most surveys place the use of static analysis tools at about 11%, and they all go back to early 80's.

Some people are hard learners.

Re: Speed of Rust vs. C

#134

Post by 12thwonder »

I prefer to have great ideas in rust ported over to C instead of rewriting everything with Rust. this approach will benefit all the existing softwares written in C which I think is much larger than Rust in terms of both impact and code size.

am I a minority having this opinion?

Re: Speed of Rust vs. C

#135

Post by JohnStrangeII »

rocqua wrote: post #129
rbanffy wrote: post #115

Earlier quoted context omitted.

I used to say that wrt to memory leaks with Java and C++ and it remains true when comparing C and Rust: It's not that it's easier to write programs in [Java|Rust]. It's that it makes it much harder to write the bugs.

Yesterday I upgraded an entire code-base from C to C++ just because it was faster than writing my own dynamically resizing array in C. Writing programs in C is harder just because there are essentially no containers in the stdlib.

Aren't there good container libraries for C?

Re: Speed of Rust vs. C

#136

Post by PicassoCTs »

rbanffy wrote: post #117
riquito wrote: post #92

Earlier quoted context omitted.

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

The average cellphone today has more than 4 cores. A decent desktop can deal with 16 threads on 8 cores. There is a lot of untapped parallelism readily available waiting for the right code.

Parallelization is the nuclear energy of comp science. Loads of potential, high risk reward and they would have gotten away with it, if it were not for those meddling humans. Its non-trivial and can only be handled by accomplished engineers. Thus it is not used - or is encapsulated, out of sight, out of reach of meddling hands. (CPU Microcode shovelling non-connected work to pipelines comes to mind / NN-Net training frameworks, etc.)

Re: Speed of Rust vs. C

#137

Post by bluejekyll »

pjmlp wrote: post #125
gridspy wrote: post #98

Earlier quoted context omitted.

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.

Accessing files or database content from multiple threads without proper locking, or transactions, in place will compile just fine.

Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time.

If you need to do it across processes, then you need a file system that supports exclusive file opens.

The db question is a red-herring, because to properly solve for concurrency in the db, you need to use locks in the db (table and row locks), not the code accessing the db.

Re: Speed of Rust vs. C

#138

Post by Jweb_Guru »

scorpion95 wrote: post #112
bsder wrote: post #110

Earlier quoted context omitted.

> Code converted from C to Rust seems much more voluminous. This is a fairly odd claim. If you have to deal with strings (ASCII and UTF-8) properly, C is stupidly verbose. If you need a data structure more complex than an array of something, C is stupidly verbose. If you want to deal with pattern matching/regexen, C is ridiculously verbose. Do I agree that Rust is far more verbose for an embedded "blinky" (the embedd…

When I converted code from C to Rust, I was left with much more code. Are you just noting specifics, or was it your experience that there was less Rust required for a full C to Rust conversion?

AFAIK it is a common experience that both C and C++ code tend to become fewer LOC in a move to Rust, a lot of it due to stuff like serde that greatly reduces boilerplate. It probably depends on your application and program size, though. I'm sure that if you're doing a lot of pointer wrangling or something it won't be smaller in Rust, while if your C program was just a bunch of SIMD intrinsics anyway like a lot of high performance code is now it'll probably be basically the same length.

Re: Speed of Rust vs. C

#139

Post by Chilinot »

bluejekyll wrote: post #137
pjmlp wrote: post #125

Earlier quoted context omitted.

Accessing files or database content from multiple threads without proper locking, or transactions, in place will compile just fine.

Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time. If you need to do it across processes, then you need a file system that supports exclusive file opens. The db question is a red-herring, because to properly solve for concurrency in the db, you need t…

You dont necessarily need to use locks in the db. You can use transactions as well, unless you want to do major changes to the DB where transactions would be in constant conflict state.

Re: Speed of Rust vs. C

#140

Post by cb321 »

JohnStrangeII wrote: post #135
rocqua wrote: post #129

Earlier quoted context omitted.

Yesterday I upgraded an entire code-base from C to C++ just because it was faster than writing my own dynamically resizing array in C. Writing programs in C is harder just because there are essentially no containers in the stdlib.

Aren't there good container libraries for C?

https://github.com/glouw/ctl/
Post reply on HN