Sorry, maybe stupid question. But can't this be decided by some benchmarks, using some of the features in the article that purport to make Rust faster?
Is Rust faster than C?
111–120 of 402 posts
Re: Is Rust faster than C?
#112In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…
To be honest, I think a lot of the justification here is just a difference in standard library and ease of use.
I wouldn't consider there to be any notable effort in making thread build on target platforms in C relative to normal effort levels in C, but it's objectively more work than `std::thread::spawn(move || { ... });`.
Despite benefits, I don't actually think the memory safety really plays a role in the usage rate of parallelism. Case in point, Go has no implicit memory safety with both races and atomicity issues being easy to make, and yet relies much heavier on concurrency (with a parallelism degree managed by the runtime) with much less consideration than Rust. After all, `go f()` is even easier.
(As a personal anecdote, I've probably run into more concurrency-related heisenbugs in Go than I ever did in C, with C heisenbugs more commonly being memory mismanagement in single-threaded code with complex object lifetimes/ownership structures...)
Re: Is Rust faster than C?
#113Earlier quoted context omitted.
> On the other hand, signed integer overflow being UB would count for C/C++ C and C++ don't actually have an advantage here because this is only limited to signed integers unless you use compiler-specific intrinsics. Rust's standard library allows you to make overflow on any specific arithmetic operation UB on both signed and unsigned integers.
It's interesting, because it's a "cultural" thing like the author discusses, it's a very good point. Sure, you can do unsafe integer arithmetic in Rust. And you can do safe integer arithmetic with overflow in C/C++. But in both cases, do you? Probably you don't in either case. "Culturally", C/C++ has opted for "unsafe-but-high-perf" everywhere, and Rust has "safe-but-slightly-lower-perf" everywhere, and you have to g…
C++ isn't always "unsafe-but-high-perf". Move semantics are a good example. The spec goes to great lengths to ensure safety in a huge number of scenarios, at the cost of performance. Mostly shows up in two ways: one, unnecessary destructor calls on moved out objects, and two, allowing throwing exceptions in move constructors which prevents most optimizations that would be enabled by having move constructors in the first place (there was an article here recently on this topic).
Another one is std::shared_ptr. It always uses atomic operations for reference counting and there's no way to disable that behavior or any alternative to use when you don't need thread safety. On the other hand, Rust has both non-atomic Rc and atomic Arc.
Re: Is Rust faster than C?
#114That article did not contribute anything to the answer of the question quoted.
Re: Is Rust faster than C?
#115Earlier quoted context omitted.
I agree with this whole-heartedly. Rust is a LANGUAGE and C is a LANGUAGE. They are used to describe behaviours. When you COMPILE and then RUN them you can measure speed, but that's dependent on two additional bits that are not intrinsically part of the languages themselves. Now: the languages may expose patterns that a compiler can make use of to improve optimizations. That IS interesting, but it is not a question o…
No. As you've made clear, it's a question of being able to express things in a way that gives more information to a compiler, allowing it to create executables that run faster. Saying that a language is about "expressability" is obvious. A language is nothing other than a form of expression; no more, no less.
Yes. But the speed is dependent on whether or not the compiler makes use of that information and the machine architecture the compiler is running it on.
Speed is a function of all three -- not just the language.
Optimizations for one architecture can lead to perverse behaviours on another (think cache misses and memory layout -- even PROGRAM layout can affect speed).
These things are out of scope of the language and as engineers I think we ought to aim to be a bit more precise. At a coarse level I can understand and even would agree with something like "Python is slower than C", but the same argument applies there as well.
But at some point objectivity ought to enter the playing field.
Re: Is Rust faster than C?
#116In short, the maximum possible speed is the same (+/- some nitpicks), but there can be significant differences in typical code, and it's hard to define what's a realistic typical example. The big one is multi-threading. In Rust, whether you use threads or not, all globals must be thread-safe, and the borrow checker requires memory access to be shared XOR mutable. When writing single-threaded code takes 90% of effort…
Multithreading does not make code more efficient. It still takes the same amount of work and power (slightly more). On a backend system where you already have multiple processes using various cores (databases, web servers, etc) it usually doesn’t make sense as a performance tool. And on an embedded device you want to save power so it also rarely makes sense.
Multithreading can made an application more responsive and more performant to the end user. If multithreading causes an end user to have to wait less, the code is more performant.
Re: Is Rust faster than C?
#117Earlier quoted context omitted.
Yes. All `&mut` references in Rust are equivalent to C's `restrict` qualified pointers. In the past I measured a ~15% real world performance improvement in one of my projects due to this (rustc has/had a flag where you can turn this on/off; it was disabled by default for quite some time due to codegen bugs in LLVM).
Not just all &mut T, but also all &T, where the T does not transitively contain an UnsafeCell . Click "show llvm ir" instead of "build" here: https://play.rust-lang.org/?version=stable&mode=release&edit...
I was confused by this at first since `&T` clearly allows aliasing (which is what C's `restrict` is about). But I realize that Steve meant just the optimization opportunity: you can be guaranteed that (in the absence of UB), the data behind the `&T` can be known to not change in the absence of a contained `UnsafeCell`, so you don't have to reload it after mutations through other pointers.
Re: Is Rust faster than C?
#118Earlier quoted context omitted.
Code is typically run many more times than it's compiled, so this is a perfectly good tradeoff to make.
For release builds yes. For debug builds slow compile times kill productivity.
A lot of C++ devs advocate for simple replacements for the STL that do not rely too much on zero-cost abstractions. That way you can have small binaries, fast compiles, and make a fast-debug kinda build where you only turn on a few optimizations.
That way you can get most of the speed of the Release version, with a fairly good chance of getting usable debug info.
A huge issue with C++ debug builds is the resulting executables are unusably slow, because the zero-cost abstractions are not zero cost in debug builds.
Re: Is Rust faster than C?
#119Sorry, maybe stupid question. But can't this be decided by some benchmarks, using some of the features in the article that purport to make Rust faster?
Not a stupid question :)
Part of what I'm getting at here is that you have to decide what is in those benchmarks in the first place. Yes, benchmarks would be an important part of answering this question, but it's not just one question: it's a bunch of related but different questions.
Re: Is Rust faster than C?
#120Earlier quoted context omitted.
Multithreading does not make code more efficient. It still takes the same amount of work and power (slightly more). On a backend system where you already have multiple processes using various cores (databases, web servers, etc) it usually doesn’t make sense as a performance tool. And on an embedded device you want to save power so it also rarely makes sense.
Multithreading can made an application more responsive and more performant to the end user. If multithreading causes an end user to have to wait less, the code is more performant.
Yes it can used to reduce latency of a particular task. Did you read my points about when it’s not helpful?
Are people making user facing apps in rust with GUIs?