Is it possible to do RCU in Rust? Without unsafe blocks?
I don't know all of the subtleties, but it sounds like https://doc.rust-lang.org/stable/std/sync/struct.RwLock.html to me? At least in some way?
Speed of Rust vs. C
381–390 of 546 posts
Re: Speed of Rust vs. C
#382> There are other kinds of concurrency bugs, such as poor use of locking primitives causing higher-level logical race conditions or deadlocks, and Rust can't eliminate them, but they're usually easier to diagnose and fix. Which is why so many people are creating formal verification languages and spending years in research to fix those ... That just isn't true. It's a very complex problem that is an issue in both hard…
You've just taken the word 'fearless', a word that's clearly subjective, and said that the definition the author gives of it "couldn't be more wrong". That's... a choice.
The word is misrepresenting the problem of synchronization and reducing to only memory safety.
If it was that simple, Tokio wouldn't need to formally verify their implementation with an external tool and it wouldn't have found dozens of well hidden bugs.
Re: Speed of Rust vs. C
#383Its 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.
Bothsidesism is unhelpful in technical discussions just as much as in politics. If you have specific critiques please share them. I have a number of specific critiques of Rust, chief being that APIs and implementations are bound too tightly. &[String] and &[&str] are logically similar but changing from one to the other in your implementation might mean a breaking API change.
[deleted]
Re: Speed of Rust vs. C
#384Its 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.
Can you point to some specific comments like this? None of the top threads seem to show this, as of this writing it's mostly about thread versus process parallelism and which kinds of conditions require unsafe.
[deleted]
Re: Speed of Rust vs. C
#385Earlier quoted context omitted.
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.
Have you ever had to deal with tail latency due to memory pressure on web or backend services? Command-line tools are also ideal for Rust because startup performance matters a lot there.
Yes, writing distributed systems since 1999.
What was done in C, C++ and Tcl, I nowadays use Java and .NET languages.
If we really need something low level that either Java or .NET cannot offer, a native library for a specific component will do, no need to throw the whole thing away and do one of those rewrite blog posts.
Re: Speed of Rust vs. C
#386Earlier quoted context omitted.
The problem is that most people criticising Rust don't make the case very well. If you want to read good critique, I'd recommend this - https://matklad.github.io/2020/09/20/why-not-rust.html . This post up-to-date, succinct and objective. And most pertinently, this critique was written by someone who genuinely loves programming in Rust. Shows you that Rust users aren't blinded to the faults of the language. You shoul…
> You shouldn't think that Rust users are fanboys just because you see push back to low effort, low knowledge critiques. That's too much assuming, btw I read in this thread a comment from a well-known Nim dev working in multithreading (with much knowledge on the subject) and it was downvoted to oblivion.
Could you share a link? I'd be surprised if well founded criticism was downvoted.
Re: Speed of Rust vs. C
#387Earlier quoted context omitted.
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…)
It's not that uncommon in HPC codes. I.e. one of the places where speed matters.
Re: Speed of Rust vs. C
#388Earlier quoted context omitted.
Sometimes your job has few or no inter-task dependencies and so there's no need to share between threads, but there's a heck of a lot of work that needs to be completed.
Essentially any significant task can be made multi threaded for any number of cores, it's just a lot of coding work.
There's a practical question of whether this is true for realistically encountered problems, with a sufficient threshold on both the size and utility of a "significant task" and with realistic numbers of cores.
Without a requirement of utility it's easy to come up with counterexamples from math, eg "does the Collatz starting from Graham's number reach one?" Once you've exhausted cores that can be used for the actual arithmetic, you are still gated by the decision-making at each step so cores cannot work too far "ahead" of each other. There may well be much smarter things we can do than brute force, but that's not "just coding work" at that point.
Theoretically, it doesn't hold - at some point you have split apart everything that can be split, and you are left with some essential chains of data dependency that cannot be further parallelized.
Re: Speed of Rust vs. C
#389Earlier quoted context omitted.
How well do you know Rust, and how it works, and what it guarantees? Like, do you have a specific objection to the way Rust accomplishes this?
"thread safety for all data" is not even a well-defined term, I do not know what you are trying to argue about.
I gave you a definition in my initial reply to you.
Re: Speed of Rust vs. C
#390"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…
>> One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. How did you do that in Rust? Doesnt one of those have to own the scene at a time? Or is there a way to make that exclusive ownership more granular?
Since this got so many upvotes, I'll say a bit more. I'm writing a viewer for a virtual world. Think of this as a general-purpose MMO game client. It has no built-in game assets. Those are downloaded as needed. It's a big world, so as you move through the world, more assets are constantly being downloaded and faraway objects are being removed. The existing viewers are mostly single thread, in C++, and they run out of CPU time.
I'm using Rend3, which is a 3D graphics library for Rust that uses Vulkan underneath. Rend3 takes care of memory allocation in the GPU, which Vulkan leaves to the caller, and it handles all the GPU communication. The Rend3 user has to create all the vertex buffers, normal buffers, texture maps, etc., and send them to Rend3 to be sent to the GPU. It's a light, safe abstraction over Vulkan.
This is where Rust's move semantics ownership transfer helps. The thread that's creating object to be displayed makes up the big vertex buffers, etc., and then asks Rend3 to turn them into a "mesh object", "texture object", or "material object". That involves some locking in Rend3, mostly around GPU memory allocation. Then, the loader puts them together into an "object", and tells Rend3 to add it to the display list. This puts it on a work queue. At the beginning of the next frame, the render loop reads the work queue, adds and deletes items from the display list, and resumes drawing the scene.
Locking is brief, just the microseconds needed for adding things to lists. The big objects are handed off across threads, not recopied. Adding objects does not slow down the frame rate. That's the trouble with the existing system. Redraw and new object processing were done in the same thread, and incoming updates stole time from the redraw cycle.
If this was in C++, I'd be spending half my time in the debugger. In Rust, I haven't needed a debugger. My own code is 100% safe Rust.