On 8/6/24 14:53, ma...@mohawksoft.com wrote:
I call BS on that whole paragraph. Rust is OK, but ANYTHING you can write
in Rust can be written to be faster in C/C++.
Both are compiled languages, frequently using related compilers. Both
are going to approach as-fast-as-possible. Theoretically.
The practical is going to be different.
Practical case 1: Rust's advantage.
There are various reports of programmers with years old, very familiar,
finely optimized C/C++ programs, deciding to rewrite in Rust, sometimes
as a first Rust project, and having the naïve Rust program be
significantly faster than the mature C/C++. In digging a little these
all seem to be due to Rust "std" library having some very well written
data structures that are both very fast and, because of the way Rust
does generics, very easy to use with the data that are sitting around
the old C program.
There is no reason these fast std data structures could not be written
in C/C++, and be as fast, but Rust has a practical advantage here, at
least some of the time.
A freaky thing about Rust libraries is it is common for the exact same
"crate" (as Rust calls libraries) to be maybe used in a tiny embedded
machine with no OS, inside an OS kernel, in some big container in the
cloud, inside a "smartphone", in browsers via WASM, or running on the
zillion CPUs of some some gigantic cluster that we call a
"supercomputer" these days.
Not just core stuff, as C/C++ programmers do with something like
strncpy() in glibc, but maybe an obscure open source crate created by
some programmer in Nebraska, it doesn't have to be in std. (In fact the
tiny embedded is likely "no_std".)
Practical case 2: Rust's Advantage.
Moore's Law has been sputtering and clawing and *barely* wheezing along
for years now. Computers have gotten faster by doing more and more
cacheing, and by having more CPUs. For multiple CPUs, with view to
shared RAM (clever cacheing), multi-threaded programs can be screaming fast.
It is handy that writing a multi-threaded program in C/C++ is easy. The
catch is that maintaining a multi-threaded program in C/C++ is…kinda
impossible. Too much of a multi-threaded "program" is in the comments,
explaining key relationships to the next programmer (or same programmer,
if the programmer and project both survive long enough).
So multi-threaded programming needs to be approached carefully, and with
discipline to not do dangerous things that might start out okay but will
inevitably turn into bugs——nasty, subtle bugs. At least for C/C++.
Rust is different. For beginners Rust is can be annoying, as the
compiler insists on lots of extra detail that isn't needed in a C/C++
program. But all that extra detail *is* also in the C/C++ program, but
it is just in the comments. For the programmer to maintain and obey.
Because Rust insists the programmer tell the compiler these things, the
compiler will help out and prevent a range of bugs. They simply won't be
there. This doesn't make Rust faster, per se, but it can allow Rust
programmers to be much more aggressive about how they use multi-tasking,
to do things that would be reckless in C/C++. And in that can be
significant speed.
Practical case 3: C/C++'s advantage.
C/C++ compilers are more mature, so there are better optimizers for
C/C++ programmers. This is an advantage for C. Though, not always:
sometimes the machine code will simply be as fast as it possible, and
sometimes Rust will be that fast, making it a wash. But on average, at
least for the moment, C/C++ has the advantage.
Future Case
I don't hear others talking about this, and I might be wrong (would
anyone here expect me to ever be wrong??), but because the Rust compiler
has more information about the program than does the C/C++ compiler, and
because it compiles both the "program" and the libraries, I expect the
Rust compiler should be able, in the future, to optimize on a larger
scalem and get better results. But I might be wrong. (Me‽‽)
A Why: "Zero Cost Abstractions".
Rust has lots of cool features that one would expect in, say, Python.
And Python is a pig. Fat and slow. And though you might expect those
features to make Rust slower, you would be wrong.
Rust is a strongly typed, compiled language. It has a compiler that is
picky as hell (though also helpful in its complaints). They push this to
the extreme. All of these features that seem like they would be slow are
implemented at compile time. By the time the machine code is emitted,
there is no speed penalty. Rust is obsessed about this.
If you can get Rust to do the array index computation (iterators and the
like), it trusts its own index math, there will be no runtime checks to
slow down array access, yet the result is still safe array access, as if
there were runtime checks.
Yes, there are ways to slow down a Rust program. If you have to do some
chaotic array accessing there might not be a way to get Rust to do that
for you, in which case you can choose to have those accesses have a
runtime check, and that will take a little speed. Or, you could decide
to do unchecked array access (the "unsafe {}" feature is useful). Or,
maybe be a little more clean, figure out how to put your index
computation in as clean a little package as possible, prove it up and
down that it is correct, and kind of simulate Rust's trust of its own
index calculations.
Similarly, there is no speed penalty of doing runtime dispatch unless
the programmer decides to do so. Maybe there are code size
considerations, and runtime dispatch can be smaller, maybe some key
stuff decides to fit in a small cache that way and the result is faster
even with the extra indirection. Cool. But the programmer chooses.
Aren't vtables part of C++? Okay, same idea, it costs a little, not a
lot. Nice to be able to choose. That is the level Rust is at, they sweat
runtime dispatch and avoid it by default.
Rust is that way all along. Every feature is designed to be as fast as
is theoretically possible, the price for those fancy features is paid at
compile time, not runtime. Zero cost abstractions.
-kb, the Kent who calls BS.
_______________________________________________
Discuss mailing list
Discuss@driftwood.blu.org
https://driftwood.blu.org/mailman/listinfo/discuss
