Human-friendlyness and bug-prevention is very important, of course everthing in Rust can be created in C or Assembler och in machine-code but the question is how feasible is it that a typical human can do it? Rust has a lot of potential I think
Speed of Rust vs. C
111–120 of 546 posts
Re: Speed of Rust vs. C
#112Earlier 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…
> 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?
Re: Speed of Rust vs. C
#113Earlier 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…
I was really struck by a comment Jonathan Blow made on stream recently: he said he’s never written a parallel for loop in his whole career. I seem to recall the implication being that they’re often not really necessary for performant code. There’s also been some discussion lately about issues with asynchronous code both in Rust and Python. Point being that parallelism still had a ways to go before it’s proven it’s us…
I never wrote a parallel for-loop in 15 years working on Firefox, because it's hard in C++, it's risky and difficult to maintain the thread-safety invariants, and it's not all that useful in most parts of the browser.
I write them quite often in Rust, because Rayon makes it super easy, there is almost no risk because the compiler checks the relevant thread-safety invariants, and I'm working on different problems where data parallelism is much more useful.
Re: Speed of Rust vs. C
#114Human-friendlyness and bug-prevention is very important, of course everthing in Rust can be created in C or Assembler och in machine-code but the question is how feasible is it that a typical human can do it? Rust has a lot of potential I think
Yeah, the sooner we move away from cowboy/Hero coding, the better. We could use a bit of humility in our field.
Re: Speed of Rust vs. C
#115Earlier 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…
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.
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.
Re: Speed of Rust vs. C
#116"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…
> Code converted from C to Rust seems much more voluminous. Perhaps it’s easier to maintain if you know Rust well?
My experience is mostly the opposite. For many tasks Rust can be much more concise (see anything with string handling, for example).
Re: Speed of Rust vs. C
#117Earlier 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
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.
Re: Speed of Rust vs. C
#118Earlier quoted context omitted.
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.
Yes. But it’s not just taking care of those things that must be done; it seems to bloat the code. I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services. For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby. Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? I…
Firefox's is compiled code is mostly written in C++ not C. You conflate C with C++, Java, and C#. C++ while has source compatibility with C tends to end up much different than C. C will not give you the OOP hell-scape you can dig yourself into with those three languages. C code tends be simpler and much more close to the assembly that will be generated than you would get in those language. Moreover, Java and C# are not even compiled. Anyways C != C++. C++ has changed quite a bit since it's earlier days and has diverged from plain C in a lot of ways. Some people even feel C++ keeps adding too many new features too fast.
Re: Speed of Rust vs. C
#119Earlier quoted context omitted.
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.
Yes. But it’s not just taking care of those things that must be done; it seems to bloat the code. I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services. For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby. Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? I…
Ruby is not fast.
Re: Speed of Rust vs. C
#120> Rust can't count on OSes having Rust's standard library built-in, so Rust executables bundle bits of the Rust's standard library (300KB or more). Fortunately, it's a one-time overhead.
No, it's not, especially if you have multiple binaries. There are hacks, like using a multi-call single binary, (forget about file-based privilege separation), or using an unmaintained fork of cargo to build a rust toolchain capable of dynamic linking libstd. See: https://users.rust-lang.org/t/link-the-rust-standard-library... and https://github.com/johnthagen/min-sized-rust
I'd be interested in any up-to-date trick to do better than this.