181–190 of 402 posts
Earlier quoted context omitted.
I mean, data races are undefined behavior in C++ the same way that they are in unsafe Rust. The languages are equivalent there.
Only if there is a data race - if there is no data race C++ lets you do it. Rust doesn't let you do things that don't have a race but cannot be proven within the context of rust to not have a data race.
One example where Rust enables better and faster abstractions is traits. C you can do this with some ugly methods like macros and such but in Rust it’s not the implementers choice it’s the callers choice whether to use dynamic dispatch (function pointer table in C) or static dispatch (direct function calls!) In c the caller isn’t choosing typically. The author of some library or api decides this for you. This turns o…
Earlier quoted context omitted.
The main performance difference between Rust, C, and C++ is the level of effort required to achieve it. Differences in level of effort between these languages will vary with both the type of code and the context. It is an argument about economics. I can write C that is as fast as C++. This requires many times more code that takes longer to write and longer to debug. While the results may be the same, I get far better…
> I can write C that is as fast as C++. Only if ignoring the C++ compile time execution capabilites.
These variances pretty much mean that trying to compare with other "low level" languages is far from an apples to apples comparison.
So, to answer the question, "It depends." ... In the end, I think developers tend to optimize for a preferred style or ergonomics over hard technical reasons... it's mostly opinion, IMO.
Earlier quoted context omitted.
Yes! gcc/omp in general solved a lot of the problems which are conveniently left out in the article. The we have the anecdotal "They failed firefox layout in C++ twice then did it in Rust" < to this I sigh in chrome.
The Rust version of this is "turn .iter() into .par_iter()." It's also true that for both, it's not always as easy as "just make the for loop parallel." Stylo is significantly more complex than that. > to this I sigh in chrome. I'm actually a Chrome user. Does Chrome do what Stylo does? I didn't think it did, but I also haven't really paid attention to the internals of any browsers in the last few years.
Earlier quoted context omitted.
It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code. If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more co…
> It's compilers and compiler optimizations that make code run fast Well, then in many cases we are talking about LLVM vs LLVM. > Ultimately, producing fast/optimal code in C kind of is the whole point of C Mostly a nitpick, but I'm not convinced that's true. The performance queen has been traditionally C++. In C projects it's not rare to see very suboptimal design choices mandated by the language's very low expressi…
Earlier quoted context omitted.
>in Rust and C++, the standard library sorting functions are templated on the comparison function. This means it's much easier for the compiler to specialize the sorting function, inline the comparisons and optimize around it. I think this is something of a myth. Typically, a C compiler can't inline the comparison function passed to qsort because libc is dynamically linked (so the code for qsort isn't available). But…
qsort is obviously just an example, this situation applies to anything that takes a callback: in C++/Rust, that's almost always generic and the compiler will monomorphize the function and optimize around it, and in C it's almost always a function pointer and a userData argument for state passed on the stack. (and, of course, it applies not just to callbacks, but more broadly to anything templated). I'm actually very…
Your C comparator function is already “monomirphized” - it’s just not type safe.
What good is speed if you cannot compile? c has both. Maybe in another decade rust will have settled down but now wrangling all the incompatible rust versions makes c the far better option. And no, setting cargo versions doesn't fix this. It's not something you'd run into writing rust code within a company but it's definitely something you run into trying to compile other people's rust code.
The question is what do we mean by "a fast language"? We could mean it to be how fast the fastest code that a performance expert in that language, with no resource constraints, could write. Or, we can restrict it to "idiomatic" code. Or we can say that a fast language is the one where an average programmer is most likely to produce fast code with a given budget (in which case probably none of the languages mentioned…
It's compilers and compiler optimizations that make code run fast. The real question is if the Rust language and the richer memory semantics it has help the Rust compiler to provide a bit more context for optimizing that the C compiler wouldn't have do unless you hand optimize your code. If you do hand optimize your code, all bets are off. With both languages. But I think the notion that the Rust compiler has more co…
Compiler optimisations certainly play a large role, but they're not the only thing. Tracing-moving garbage collectors can trade off CPU usage for memory footprint and allow you to shift costs between them, so depending on the relative cost of CPU and RAM, you could gain speed (throughput) in exchange for RAM at a favourable price.
Arenas also offer a similar tradeoff knob, but they come with a higher development/evolution price tag.
Earlier quoted context omitted.
> I can write C that is as fast as C++. Only if ignoring the C++ compile time execution capabilites.
C++ compile time execution is just a gimmicky code generator, you can do it in any language.