7 ms·
C++ is faster and safer than Rust (2020)
- zekrioca 5y agoTLDR; From article: > Spoiler: C++ is not faster or slower – that's not the point, actually. This article continues our good tradition of busting myths about the Rust language shared by some big-name Russian companies.
- habibur 5y agoFirst check speed/memory usage. Then the one which is easier to code in. And then third : easier to integrate with the OS and build library functions which will be consumed by other apps written in higher level languages. These are the three things that matter most.
- einpoklum 5y agoDifferent languages strengths "matter the most" in different usage scenarios. Sometimes an OS doesn't even exist. Sometimes an application is written fully in the same language. etc.
- zgs 5y agoAssembly is faster and safer than rust. Rust is a fad it will fad.
- frozenport 5y agoalso ++C is faster
- zarzavat 5y agoOnly C++ programmers will appreciate this joke.
- savolai 5y agoThank you for laughter.
- willbudd 5y agoYou jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where they simply occur as stand-alone expressions, despite their obvious semantic equivalence. Even stranger: people that insist on writing their (loops; like; ++this) in 2021 as if doing so is in any way superior or something.
- vbezhenar 5y agoOptimizing integer increment might be easy. Hard thing is optimizing overloaded increment operator. ++c is naturally faster, because it does not have to make a copy of its previous value. Especially if that operator implementation is inside another library. So it makes sense to use fast-by-default approach.
- willbudd 5y agoYeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.
- deleted 5y ago[deleted]
- jcelerier 5y agoWith complex iterator types that carry additional state themselves (for example think iterators to sparse data or generators), it definitely makes a difference
- Dylan16807 5y agoWhat measure of safety has assembly basically ever win?
- vbezhenar 5y agoThere's no undefined behaviour in assembly language.
- anyfoo 5y agoI invite you to search the ARM reference manual (the so called "ARM ARM") for the terms UNKNOWN and UNPREDICTABLE. There is also actually UNDEFINED, but in the context of ARM it means that a specific exception happens, so it's pretty much the most PREDICTABLE of the bunch.
- nereye 5y agoThe old VLSI Technology Inc (later Philips, now NXP) reference manuals for one of the first ARM processors (the one used in the Acorn Archimedes 305, 310) mentioned that the algorithm used for cache eviction was not something relatively predictable like LIFO or FIFO but essentially random. Which in theory means that if you were 'unlucky' then your program would run slower than for a luckier person etc.
- Dylan16807 5y agoHa. Though if you're seeing a persistent difference over time, thousands and millions of evictions, your luck is already so immaculately bad that you should expect the power to go out every time you try to run a program.
- tlamponi 5y agoAs Computer Engineer: oh well, do I have bad news for you ;-) Quite a few processors have some undefined behavior, some instructions flags are just not specified, and no not just "this is reserved and must be zero", that would be Ok. The result of the `bsf` or `bsr` instructions on the 0 value And please, don't look too much at the FPU either or it may do some random stuff and jump at you.
- tlamponi 5y agoYeah, the language that: - has been around stable for over 6 years and was already somewhat popular years before that - is the first real contender to C in the Linux kernel, with support from its BDFL and a lot of work going on, and well those devs know a bit more of pain points in complex systems that need to go fast. - is used in of the major Browsers while the most popular one is contemplating starting to use it - allows refactoring and cleaning up code so nicely, it's just marvellous if one actually worked on big code bases previously to rust, as either one had ten static checkers and three times the amount of CI pipelines as required bolted on, or just risk quite a bit every time something was touched. - deep and mature integration of tests and docs and doc-test (those are damn nice) - want me to continue? I got a few more points surely is a fad ;-) Look, you do not need to use Rust if you do not want too, but living in denial about that Rust has seen a good rate of adoption and that it also has its uses as valid Language to do stuff nowadays, is just not a good thing to do mentally nor socially.
- lkey 5y agoClickbait title responding to yet more clickbait. I'll save you the trouble: "Spoiler: C++ is not faster or slower – that's not the point, actually. This article continues our good tradition of busting myths about the Rust language shared by some big-name Russian companies." (Yandex)
- hdjjhhvvhga 5y agoClickbaity title but nevertheless I've found the content interesting.
- rackjack 5y agoA better title would be "Mythbusting the idea that C++ is faster than Rust" or something like that.
- uncomputation 5y agoRust really is such a special and welcomed language, I hope it’s able to pick up even more market share than it has already, particularly in game dev!
- shmerl 5y agoMisleading title. Correct one - Busting the claim that C++ is faster and safer than Rust.
- deleted 5y ago[deleted]
- adrian_b 5y agoThe article does not provide any valid argument against "Myth 1. Rust's arithmetic is no safer than C++'s". The information provided in the article shows beyond any reasonable doubt that both C++ and Rust are exactly equally safe regarding integer overflow. Rust checks for overflow in debug builds, but it does not check for overflow in release builds. The same happens in C++. All decent C++ compilers have options for overflow checking, but most developers do not use these options in release builds, for fear that it would affect the performance. Rust is a little better because it enforces the overflow checking option on debug builds, but C++ is better because the developer may choose to keep the option also in release builds. So this myth is not busted, it is confirmed.
- oconnor663 5y agoThe generate the same assembly in this particular context, but changes to surrounding code could change that. The fact that signed int overflow is UB in C++ is a major difference. > C++ is better because the developer may choose to keep the option also in release builds You can enable overflow checks in release mode if you like: https://doc.rust-lang.org/cargo/reference/profiles.html https://doc.rust-lang.org/cargo/reference/profiles.html
- adrian_b 5y agoThe fact that integer overflow is undefined in C++ is ugly, but this leaves the solution of this problem to the compiler. The final behavior is decided by the programmer, by using or not using "-fsanitize=signed-integer-overflow" or equivalent options for the compilation. So after the programmer makes a decision, the behavior in C++ is defined and it is either like in debug Rust or like in release Rust, depending on the programmer's decision. While I hate undefined behaviors in C/C++, I prefer to be able to make my own decisions on the behavior of integer overflow, instead of being forced by Rust to ignore overflows in release builds. Edit: Thanks for the Cargo link. If you can change the overflow checking option in the Cargo profile, then there remains absolutely no difference between C++ and Rust regarding integer overflow. The Rust RFC "Integer overflow #560" is totally misleading in this case.
- rationalfaith 5y agoSo many rust-fans triggered. It's comical. They've been trying to kill c++ since the 90s, get over yourselves.
- AnimaLibera 5y agoC++ is sooo much better than any other compiled language! For example, using std::cout to print the value 97 will produce different results depending on whether this value is of the type int8_t or int32_t (but in Rust, printing 97 always outputs "97" without depending on the type of 97 that can be i8, i32, whatever). This is because C++ uses C headers to typedef int into int32_t (or whatever is 32 bits on the implementation that is being used) and to typedef char into int8_t (so the value 97 of type int8_t is printed as "a"), at least that is the case with glibc. What a good language, in comparison Rust is so boring and uninteresting.
- AnimaLibera 5y agoBy "glibc" i meant the GNU C++ standard library implementation, not glibc
- deleted 5y ago[deleted]
- cordenr 5y agoC++ is the language I use most for my day job. I am definitely on the "love" side of the "Marmite" argument. What is scary is, I don't doubt that some people will read your comment and think it could be true!
- AnimaLibera 5y agoDon't get me wrong, C++ is interesting to work with ^^, but what I said is true (just go ahead and test it, `#include <cstdint>`, then initialize a variable of type `int8_t` and `std::cout` it, I just tried it on godbolt.org with the `x86-64 gcc 11.2` compiler and it printed the value as a character rather than as a number (unlike an `int32_t`)). I never miss an opportunity to mock C++ and its many layers of features that don't always interact well with each others. Maybe take it as a fun fact and not as an attack..
- cordenr 5y agoYou're right! That's the thing with C++ - you learn something new everyday. I had misread your original post. I thought the example was something like "std::cout << 97". This is unfortunate. I imagine it came about when "cstdint" was introduced. Fixing it would require a break in compatibility with any existing code that "expected" that all char types printed a character, rather than value.
- deleted 5y ago[deleted]
- einpoklum 5y agoSo, first of all, this was posted on HN last year: https://news.ycombinator.com/item?id=23134688 https://news.ycombinator.com/item?id=23134688 To the point though, while some of the points in the article are well-taken, especially how one can pick-and-choose scenarios where one language or the other has a noticeable implementation issue or design misfeature - the article is still problematic for at least two reasons: 1. Mixing up a comparison of the languages and of the results of specific compilations by a specific compiler. If C++ semantics allow doing something easier, but Rust semantics do not, e.g. because of avoiding undefined behavior, then regardless of whether a specific compiler makes use of this fact - it is still a benefit, speed-wise. Specifically, in Rust, if I take two non-negative numbers and multiple them using the square() function discussed in the article, then check the result for being negative - with C++, the check is redundant and can be dropped in favor of a true value during compilation; with Rust, it cannot. Now, will some version of LLVM do that? I don't know - but it could (and it should). 2. Misrepresenting how the langue affects the behavior of the compiler back-end. The article says: > Rust is based on LLVM, which is the same back end that Clang is based on. Therefore, Rust has inherited "for free" and shares with C++ most of the language-independent code transformations and optimizations. That's simply not true. That is, LLVM is _capable_ of most of the same transformations and optimizations; but the question of which of them it is _allowed_ to use depends on various kinds of semantic information specific to the programming language. This is apparent even in trivial examples. Here's one: https://godbolt.org/z/rMW3vsEvo https://godbolt.org/z/rMW3vsEvo where the same function is compiled in Rust: pub fn check(num: i32) -> bool { let y = if num < 0 { -num } else { num }; return y >= 0; } and in C++: auto check(int32_t num) { auto y = (num < 0) ? -num : num; return y >= 0; } The compilation results are: example::check: mov eax, edi neg eax cmovl eax, edi test eax, eax setns al ret and: check(int): # @check(int) mov al, 1 ret respectively. How come? Isn't it all LLVM under the hood? It's even the same LLVM, version, 12.0.1 for both languages... Now, I'm not sure why exactly this happens since I'm no Rust expert. But - LLVM is not _allowed_ to apply the same optimizations to the Rust function as to the C++ function, so the results are different.
- zRedShift 5y agoWell, for one, in the Rust version, check(i32::MIN) will return false if built with overflow checks disabled (the default for release builds). C++ will of course always return true.