Speed of Rust vs. C • Hacker News Board

Re: Speed of Rust vs. C

#211

Post by cb321 » Sat, Mar 13, 2021, 2:06 PM UTC

rocqua wrote: post #191

JohnStrangeII wrote: post #135

Earlier quoted context omitted.

Aren't there good container libraries for C?

They are either based on void * with performance issues, or macro based with weird ergonomics that look like function calls, but aren't. It's doable, but not very easy.

You are right in a library-demographical sense, but not in a fundamental sense. There is a 3rd way. Have a look at the CTL I linked to (downvoted..maybe I should have explained more?).

Once you give up the closed source/prebuilt binary library idea and embrace the C++-like header library idea and write implemenations in terms of "assumed macro/inline function" definitions, the problem becomes straightforward with no performance issue and different ergonomics issues than you probably think.

It's a more "manual instantiation" than C++ templates or generics in other languages where just refering to them works, but most of C is quite manual. So, it fits the headspace & the hard parts of data structures/meddlesome hands remain factored out. Since you parameterize your files/code with #define/#include, you have to name your parameters which can make the instantiating client code more obvious than C++ templates with many arguments. OTOH, there is no/poor type checking of these parameters.

Re: Speed of Rust vs. C

#212

Post by bluejekyll » Sat, Mar 13, 2021, 2:08 PM UTC

amelius wrote: post #202

bluejekyll wrote: post #198

Earlier quoted context omitted.

It doesn’t say it “works badly” it says the borrow checker can’t protect against external modifications to the file while memory-mapped, which has a host of issues in C as well. You can mmap files in Rust just fine, but it’s generally as dangerous as it is in C.

But that may be of little solace. If you snapshot your entire heap into an mmapped file for fast I/O, then basically the entire advantage of Rust is gone.

Is there literally no other code in the application?

Rust has plenty of situations where you do unsafe things but wrap that in safe APIs. If you’re returning regions of that mmapped file, for example, a lifetime can be associated to those references to ensure that those are valid for the duration of the file being mmapped in the program.

It can be used to ensure that if you need to write back to that mmapped file (inside the same program) that there are no existing references to it, because those would be invalid after an update to the file. You need to do the same in C, but there are no guardrails you can build in C to make that same assurance.

Re: Speed of Rust vs. C

#213

Post by creata » Sat, Mar 13, 2021, 2:12 PM UTC

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's just ugly and looks like design by committee.

I don't think it's ugly because it's design-by-committee, I think they intentionally made it ugly so that it's familiar to C++ people.

> I also wonder why corporations are pushing Rust.

You said it yourself: undisciplined people can't write C without introducing memory-related bugs, and it's much easier to hire undisciplined people than disciplined people.

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

Do you have an example of a project that is (a) built in such a way, (b) large, and (c) has a good track record on memory safety?

Re: Speed of Rust vs. C

#214

Post by cygx » Sat, Mar 13, 2021, 2:16 PM UTC

TazeTSchnitzel wrote: post #195

scorpion95 wrote: post #90

Earlier quoted context omitted.

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…

C being barebones does not mean it is faster. Because it has such weak typing and gives a huge amount of programmer freedom, compilers have to do a lot of work to be able to understand a C program well enough to optimise it. Rust, on the other hand, requires the programmer to give the compiler more information about what they're doing. A very simple example: void foobar(struct foo *f) { f->a += 2; foo(); f->a += 2; b…

That's what restrict is for:

    void foobar(struct foo *restrict f) { ... }

Re: Speed of Rust vs. C

#215

Post by JulianMorrison » Sat, Mar 13, 2021, 2:20 PM UTC

high_density wrote: post #199

amelius wrote: post #194

Earlier quoted context omitted.

But Rust works badly with mmapped (memory-mapped) files, as the article notes. So in C you could load (and save!) stuff almost instantly, whereas in Rust you still have to de-serialize the input stream.

is it something deeply ingrained to rust? or is it something rust is working on?

It's more like, Rust wants to make guarantees that just aren't possible for a block of memory that represents a world-writable file that any part of your process, or any other process in the OS, might decide to change on a whim.

In other words, mmaped files are hard, and Rust points this out. C just provides you with the footgun.

Re: Speed of Rust vs. C

#216

Post by TazeTSchnitzel » Sat, Mar 13, 2021, 2:22 PM UTC

cygx wrote: post #214

TazeTSchnitzel wrote: post #195

Earlier quoted context omitted.

C being barebones does not mean it is faster. Because it has such weak typing and gives a huge amount of programmer freedom, compilers have to do a lot of work to be able to understand a C program well enough to optimise it. Rust, on the other hand, requires the programmer to give the compiler more information about what they're doing. A very simple example: void foobar(struct foo *f) { f->a += 2; foo(); f->a += 2; b…

That's what restrict is for: void foobar(struct foo *restrict f) { ... }

Yes, C99 added that keyword, and you can use it in C code. (C++ is a more complicated matter, I believe…)

But I think it's pretty uncommon in practice. One reason is that the C compiler has no borrow checker to help you notice when you're using `restrict` unsafely.

(Also, there's the whole “strict aliasing” hell…)

Re: Speed of Rust vs. C

#217

Post by jedisct1 » Sat, Mar 13, 2021, 2:29 PM UTC

planetis wrote: post #176

Its just amusing, in this thread everyone with critical thinking and skeptical is down voted, even if one expresses himself moderately. It shows how much of zealots, Rust fanboys have become.

This is the case every time there's a post about Rust.

Re: Speed of Rust vs. C

#218

Post by burntsushi » Sat, Mar 13, 2021, 2:29 PM UTC

amelius wrote: post #194

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…

But Rust works badly with mmapped (memory-mapped) files, as the article notes. So in C you could load (and save!) stuff almost instantly, whereas in Rust you still have to de-serialize the input stream.

No you don't. I've written multiple programs that load things instantly off the file system via memory maps. See the fst crate[1], for example, which is designed to work with memory maps. imdb-rename[2] is a program I wrote that builds a simple IR index on your file system that can then instantly search it by virtue of memory maps.

Rust "works badly with memory mapped files" doesn't mean, "Rust can't use memory mapped files." It means, "it is difficult to reconcile Rust's safety story with memory maps." ripgrep for example uses memory maps because they are faster sometimes, and its safety contract[3] is a bit strained. But it works.

[1] - https://github.com/BurntSushi/fst/

[2] - https://github.com/BurntSushi/imdb-rename

[3] - https://docs.rs/grep-searcher/0.1.7/grep_searcher/struct.Mma...

Re: Speed of Rust vs. C

#219

Post by nyc_pizzadev » Sat, Mar 13, 2021, 2:29 PM UTC

Shouldn’t this be Rust vs C++? C++ has a lot more parallels to Rust. Both are big, complex, and safe languages that can tuned for high performance. Infact, I would like to see more comparisons of Rust and C++ in the future.

Re: Speed of Rust vs. C

#220

Post by ReactiveJelly » Sat, Mar 13, 2021, 2:30 PM UTC

amelius wrote: post #202

bluejekyll wrote: post #198

Earlier quoted context omitted.

It doesn’t say it “works badly” it says the borrow checker can’t protect against external modifications to the file while memory-mapped, which has a host of issues in C as well. You can mmap files in Rust just fine, but it’s generally as dangerous as it is in C.

But that may be of little solace. If you snapshot your entire heap into an mmapped file for fast I/O, then basically the entire advantage of Rust is gone.

> If you snapshot your entire heap into an mmapped file for fast I/O,

I've never heard of this trick. And my first reaction is "That would be a nightmare of memory unsafety if I did it in C++"

What's it used for? IPC?