271–280 of 402 posts
Earlier quoted context omitted.
Rust has linker optimizations that can make it faster in some cases
Huh? Both have LTO. There are linker optimizations available to Rust and not to C and C++. They all use the same God damn linker.
When I compiled the final binary, I ran llvm LTO across all 3 languages. That was incredibly cool.
Earlier quoted context omitted.
> For instance, in C, qsort() takes a function pointer for the comparison function, in Rust and C++, the standard library sorting functions are templated on the comparison function. That's more of a critique of the standard libraries than the languages themselves. If someone were writing C and cared, they could provide their own implementation of sort such that the callback could be inlined (LLVM can inline indirect…
"could" and "should" are doing some very theoretical heavy lifting here. Sure, at the limit, I agree with you, but in reality, relying on the compiler to do any optimization that you care about (such as inlining an indirect function call in a hot loop) is incredibly unwise. Invariably, in some cases it will fail, and it will fail silently. If you're writing performance critical code in any language, you give the comp…
It's just a generic sorting function. If you need more you're supposed to write it yourself. The C standard library exists for convenience not performance.
Earlier quoted context omitted.
Right, but almost all APIs in Rust use something like fn foo(bar: impl BarTrait) and AFAIK it isn't possible to write that in C (though C++ does allow this kind of thing).
C++ you either use templates or classes and virtuals. In either case the caller doesn't get to decide.
Earlier quoted context omitted.
Apart from multi threading, there is more information in the Rust type system. Would that would allow more optimizations?
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).
tl;dr: Rust officially allows you to write inline assembly so it's fast, but in C it's not officially specified as part of the language. Plus more points which do not actually indicate Rust is faster than C. ... well, that's what I get for reading an article with a silly title.
The article felt fairly dispassionate and even-handed to me, and I say this as someone who dislikes Klabnik very much and also dislikes the Rust community (especially its insidious, forced MIT rewrites of popular GPL software, with which they also break backwards compatibility). It is worth mentioning that there are certain things about Rust that conceivably could make it faster, e.g., const by default (theoretically…
Is this some sort of movement?
I was aware that some Rust software had been released under permissive licenses but I didn't know it was activism besides the obvious C-is-obsolete angle.
Earlier quoted context omitted.
The article felt fairly dispassionate and even-handed to me, and I say this as someone who dislikes Klabnik very much and also dislikes the Rust community (especially its insidious, forced MIT rewrites of popular GPL software, with which they also break backwards compatibility). It is worth mentioning that there are certain things about Rust that conceivably could make it faster, e.g., const by default (theoretically…
> especially its insidious, forced MIT rewrites of popular GPL software Is this some sort of movement? I was aware that some Rust software had been released under permissive licenses but I didn't know it was activism besides the obvious C-is-obsolete angle.
Monomorphizarion makes the GPL weird.
Rust is dual licensed under Apache/MIT, and so most people choose the same as a default if they don’t feel strongly about licensing.
Earlier quoted context omitted.
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 ra…
> To be honest, I think a lot of the justification here is just a difference in standard library and ease of use. I really liked this article by Bryan Cantrill from 2018: https://bcantrill.dtrace.org/2018/09/28/the-relative-perform... He straight ported some C code to rust and found the rust code outperformed it by ~30% or something. The culprit ended up being that in C, he was using a hash table library he's been co…
Edit, I also see that your reply was specifically about the point that the libs by themselves can help the performance with no work, and I do agree with you, as you were to the guy above.Earlier quoted context omitted.
"could" and "should" are doing some very theoretical heavy lifting here. Sure, at the limit, I agree with you, but in reality, relying on the compiler to do any optimization that you care about (such as inlining an indirect function call in a hot loop) is incredibly unwise. Invariably, in some cases it will fail, and it will fail silently. If you're writing performance critical code in any language, you give the comp…
> qsort, it's an API design flaw It's just a generic sorting function. If you need more you're supposed to write it yourself. The C standard library exists for convenience not performance.
I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer. I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people. A particular language doesn't have a "speed", a par…
I will admit the title was a bit of a gamble, but thank you for taking the time to read it and I'm glad that you enjoyed it in the end.
I almost ignored this post because I can't stand this particular war, where examples are cherry picked to prove either answer. I'm very happy to see the nuanced take in this article, slowly deconstructing the implicit assumptions proposed by the person asking this question, to arrive at the same conclusion that I long have. I hope this post reaches the right people. A particular language doesn't have a "speed", a par…
I will admit the title was a bit of a gamble, but thank you for taking the time to read it and I'm glad that you enjoyed it in the end.