191–200 of 546 posts
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?
It's doable, but not very easy.
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.
Earlier quoted context omitted.
There are many operations on data that are relatively slow from a CPU’s perspective — filling a cache line, page faulting, cache coherency, acquiring a lock, waiting on I/O to complete, etc. All of these add latency by stalling execution. In conventional software, when these events occur you simply stall execution, possibly triggering a context switch (which is very expensive). In many types of modern systems, these…
Is there some tool like ps/top /time that I can use measure how much “constructive” work my cpu spend doing?
"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 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…
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;
bar();
f->a += 2;
}
Rust on the other hand has two kinds of reference, rather than pointers:
fn foobar(f : &mut foo) {
f.a += 2;
foo();
f.a += 2;
bar();
f.a += 2;
}
(You can see it in action for yourself here: https://godbolt.org/z/hWs67P. Sadly, Rust doesn't do this by default due to problems with LLVM, but eventually it can.)
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?
> C libraries typically return opaque pointers to their data structures, to hide implementation details and ensure there's only one copy of each instance of the struct. This costs heap allocations and pointer indirections. Rust's built-in privacy, unique ownership rules, and coding conventions let libraries expose their objects by value The primary reason c libraries do this is not for safety, but to maintain ABI com…
> ABI compatibility Rust provides ABI compatibility against its C ABI, and if you want you can dynamically link against that. What Rust eschews is the insane fragile ABI compatibility of C++, which is a huge pain to deal with as a user: https://community.kde.org/Policies/Binary_Compatibility_Issu... I don't think we'll ever see as comprehensive an ABI out of Rust as we get out of C++, because exposing that much incid…
"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.
You can mmap files in Rust just fine, but it’s generally as dangerous as it is in C.
"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.
Earlier quoted context omitted.
Indeed, but the fearless concurrency sales pitch tends to overlook that.
The fearless concurrency sales pitch doesn't overpromise. You're trying to stretch it, but it's pretty clear on what kind of concurrency issues it covers (eg. data races).