That depends on how you write your C++ programs. Virtual functions, runtime type information, STL, RAII ownership can all be performance hits in C++ when compared to C.
Rust has optimization issues of its own apparently.
C isn't a low bar. It is the benchmark.
C isn't the benchmark, assembly is.
C forces you to write code closer to what assembly looks like than Rust or C++. That's good if you can write good assembly, and bad if you cannot. That's particularly bad for writing robust code that doesn't have security vulnerabilities, because the C programmer is required to manually write all checks correctly, while C++ and Rust have abstractions that automatically write the checks for you.
You don't have to use them in those languages if you don't want to.
As I mentioned in the other thread, I think this article is comparing GCC vs LLVM, so the info in the post is kind of moot. But if the authors really believe that Rust bound checks are the culprit of the performance difference, they can just remove them. Takes one line of code, and would show if they are right or wrong.
For example, if a function takes a `std::string` as an argument (by value), any string you pass in will be copied into a new allocation, which will then have to be deallocated. That's fine if the function really needs its own allocation – but it might not. In that case you can avoid the copy by changing the argument type to `const std::string &` or `std::string_view` (the latter being new in C++17)... but the difference is subtle enough that even an experienced programmer might not notice the extraneous copy.
Don't believe me? Consider that in 2014, "std::string was responsible for almost half of all allocations in the Chrome browser process"! [1]
(Rust does a better job here by requiring more explicitness if you want to make expensive copies.)
Oh, there's also an issue where the presence of a destructor pessimizes the calling convention for passing and returning objects of that type by value, but only slightly, and the issue will be addressed in the future. [2]
[1] https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...
[2] https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-10...
Consider a std::map<std::string, Blah> for example, if you have a char* and you want to index in to the map you are going to also end up with an intermediate string construction b/c STL associative containers don't have heterogenous lookup. Note that this was fixed in std::map::find in C++14 [0], but still is there for operator[].
Given a modern compiler and library, a by-value string temporary can be passed down a chain of calls with no allocations beyond the first, and returned, likewise.
Passing a reference means the optimizer cannot optimize accesses, because it doesn't know what other pointers might be aliasing it. string_view has the same problem.
Quotes about Chromium and Firefox are likewise obsolete. Old code, old coding standards. Neither uses RAII, so they pay a 20-30% runtime penalty. With a modern library, short strings do no allocation. (IIRC Firefox uses 16-bit characters, so they get less.)
That said, if the runtime performance of code trafficking in string objects matters, you are Doing It Wrong.
For calls (as opposed to returns): If you use std::move, yes. Otherwise, no. But using std::move is similar to changing the type in that it requires noticing the problem first.
> Passing a reference means the optimizer cannot optimize accesses, because it doesn't know what other pointers might be aliasing it. string_view has the same problem.
For `const std::string &`, the optimizer has to assume that the string pointer and length could change, which is indeed a problem as it has to keep reloading them if you call, e.g., `c_str()` or `size()` multiple times (with other things in between). For both `const std::string &` and `std::string_view`, the optimizer has to assume that the string data could change, but not the pointer or length, which is much less of a problem because you don't usually repeatedly load the same piece of string data in a loop. Therefore, `std::string_view` is a decent choice.
Passing `std::string` by value does indeed have the advantage that the compiler indeed could theoretically assume the string data is not aliased. But I just checked and none of Clang, GCC, MSVC, or ICC actually do so:
But moving can pessimize string-passing and -returning. Just write the code in the clearest way possible, and optimize hot paths where it turns out to matter, according to measurements. People have been demonstrated to be very poor at picking which those are, a priori.
Yeah, because neither of those teams had any idea what they were doing, obviously. Even with C++ 11 at their disposal. But somehow, interestingly enough, you do.
Neither uses RAII, so they pay a 20-30% runtime penalty
Who knows where you pulled that number from.
I guess then, according to you at least, there are no performance penalties to be paid for any C++ language features. Please, continue to impart your knowledge and unreferenced benchmark tests on us all.
Well that's the point: C does not have to do it.
RAII protects you from, e.g., leaking memory. But C can just leak memory, and there isn't really anything substantially wrong with that (you can't get UB from leaking memory).
Checking error values, releasing all resources, doing bound checks, and all the other things that both C++ and Rust do by default are more expensive than doing nothing. Sure, they are zero-cost, in the sense that if you were to write C code that does those, the C code wouldn't be faster. But as mentioned, C code is not required to do these.
With C, you have to manually write the code for doing those things. With C++ and Rust, you have to write the code to opt-out of doing those things (with Rust, removing a bound check is a one liner).
It's a matter of language defaults. I know what the better default for me is.
It is bad form to code memory leaks, so normally one doesn't. Instead, one normally allocates in such a way that the automatically-generated destructor frees the memory.
But neither case requires writing more code to "opt in" or to "opt out". It is the same in Rust.
This takes great care which takes time and leads to slow development. I think of C++ as worth it when this level of care is necessary to create a well-performing system.
I would agree that most toy examples don't do a good job of explaining how to use RAII in a careful high performing way
Similarly, virtual function calls on modern CPUs are essentially free if the branch predictor can predict correctly, the usual case.
FUD from the '90s is way past its sell-by date.
This has not been my experience and I'm greatly relieved that I haven't been subjected to such a hostile and destructive working environment in finance as yourself.
The correct response is always: "Show the benchmark numbers and make your case that the trade off is worth it." Then there is discussion on how compelling a case has been made.
Where do you work that allows you to implement everything twice, once in C and once in C++, for a proper comparison to be made?
(I realize that's not quite what you said, but if we're going with 'benchmark', then presumably those places have already done the benchmarks and decided that C++ is generally superior performance-wise.)
Micro benchmarks sadly have a way of showing nothing much at that end of things. Showing it's no worse/better doesn't even mean it's no worse if the additional/reduced pressure on caches doesn't result in much in the way of additional/reduced cache spills. So you end up doing mirco optimisations that each, taken alone don't do much. But when you get them all together you cross a threshold that has a considerable improvement. I believe SQLite did something like this although probably in a more restrained fashion as they have other goals than being the lowest latency solution against similarly motivated competitors.
Then of course at some point you get a reputation for success so you show the problem and the numbers identifying it and just say "I want to invest X of my time trying Y which I believe has a reasonable chance of helping" And you are told to focus on that and please let them know if you have any more good news. ;-) Sometimes your ideas are genuinely a wash and not worth merging but it is noted that it was worth trying and you're thanked for your efforts.
As somebody else noted in this thread the game has moved beyond much of this kind of thing in some, possibly many instances.
If you're disagreeing, frankly, almost everything you said sounds like a bunch of platitudes... and I don't understand what you disagree with.
If you're agreeing, frankly, almost everything you said sounds like a bunch of platitudes... and I have no idea what your central point is.
Whatever your technology choice you would expect to have to make a case, using evidence, and have that case properly listened to (or why did they hire you?). For performance critical technology you would expect that evidence to include benchmark numbers.
Any other approach to considering technology suggestions, involving "laughing out of the room", in the absence of evidence is completely unprofessional, very silly, utterly rude, purile, immature and wholly unacceptable. (And just quietly on that basis alone, I'd be pretty confident my solutions are faster than any put together by a team that ignores evidence and belittles talent. Again I say this is not about one technology vs another, this about "Laughing out of the room." Having said that I've sometimes used C and it has worked really quite well in those particular cases. I can say the same of C++ fwiw).
It's not about hostility, it's about competence. Some places just demand competence more than others.
The laughter would not be about measurable performance; you might well be able to get C code to go as fast. The laughter would be over your apparent fear of the C++ compiler, and the suggestion to spend their money on a predictably inferior, more expensive, less maintainable solution.
You might as well suggest installing fluorescent lights in the office, or 10baseT network hubs, or CRT monitors. Those would get a jolly laugh, too, completely without hostility, but you still might not be invited back.
It just isn't a meaningful conversation without a specific case, with specific requirements and where a specific solution is advanced with appropriate evidence. If in your experience there has never been a case for C, in your own work in the very broad finance domain, over C++. Great. Your experience differs from mine. I've had circumstance where I've made the case, then implemented and released it and watched the p&l go quite well as a result. I do know how to program in C++ where that is appropriate and indeed I do. No really. Also Java, and Python, and (gasp, even) Perl, and... Like any and every experienced programmer, right?
Claiming someone is "scared of the c++" compiler in the absence of evidence for that is probably not your best comment here. It's actually imho the very worst thing about c++ as a language. That is the casual derogatory, frequently unsubstantiated, statements the pervade the surrounding culture. Linus had something to say about it back in the day [1] so it's not like the C++ folk have an exclusive license on that kind of attitude... His tone there doesn't make me laugh.
Two Cases you might like to consider. (1) Optimising the very last cycle matters, how hard you have to work to shake it out, not so much. Maybe you haven't had that, um, pleasure. (2) You have a reason to want to parse and transform the source. (Given (1) above the reason for doing so might be obvious but I probably shouldn't say too much more about it, also you might laugh! ;-)
[1] http://harmful.cat-v.org/software/c++/linus [2] https://www.youtube.com/watch?v=SLLOSAm-OS0
Performance at the sharp end comes from preallocating memory, reducing syscalls, removing PIC (drop the GOT), static linking (enable LTO), using LTO, using simd where possible, hand rolling important functions in assembly, cpusets, reducing network hops, attempting to get the program to fit in L1 cache, putting the code into the switch, moving to fpga, moving to asic.
There's loads more optimizations but almost none of them have anything to do with C++ over C.
And, nobody suggested anybody actually laughs at C developers. We just don't see them.
That's my point. The performance tuning is generally not between C++ or C hence why you cannot extrapolate your experiences to the rest of the finance industry.
>And, nobody suggested anybody actually laughs at C developers.
You said, "In the finance world, you would be laughed out of the room for proposing C for a performance-critical task."
Then in discussing the nature of the laughter you said "The laughter would not be about measurable performance; you might well be able to get C code to go as fast. The laughter would be over your apparent fear of the C++ compiler, and the suggestion to spend their money on a predictably inferior, more expensive, less maintainable solution."
There are plenty of features in C++ that are beneficial, particularly the handful of mechanisms that allow you to move away from #defines, but to compare performance between C and C++ simply shows ignorance.
Typically, you can usually tell the age of the trading firm by the tech stack. Older companies are usually on C++ and have millions upon millions of existing legacy code that works, so there's little impetus to rewrite in the latest shiny. Younger firms are more likely to have embraced Java and younger yet, C#. This doesn't always hold true, though, it's just a generalization of my experience.
In my 15 years in finance, I spent 9 years at my first firm, and when I joined it was purely C++, with some perl to move data around between vendors and systems. There had been some Java, but we had a bad interaction with Sun Microsystems (at the time) and our CEO came down hard and kicked Java to the curb (and we migrated off of Sun/Solaris onto Intel x86 & Linx & C++). Towards the last several years I was at that shop, C#/WPF had been embraced for all new UI work, and even some rewrites of existing MFC apps were in progress. Python had also largely replaced Perl for all new scripting/data munging and had also been embraced by the quants. All of the servers still ran on Linux and were in C++ when I left ~6 years ago. There was even talk of migrating from Sybase on Linux to MS SQL Server. That didn't happen in my time, but from former colleagues I've kept in touch with, they've pushed forward on that. I don't know if they're using SQL Server on Windows or on Linux, now that that's an option.
My current shop is the oldest shop I've ever worked for (founded in the 70s) and is entirely a Windows/C# shop. They brought me on this year to help with their build out of Python at the firm (mostly for our quants). I'm actually really enjoying this position, because they're new to Python, but I've got +15 years experience with it, there's a lot of greenfield development and next to no existing legacy code, so I largely get to drive style and architecture.
C no longer has them. Not since a standard that’s 20 years old (C99). restrict qualifier handles that.
Unfortunately C++ committee has not included restrict in C++, but it is available in all major compilers as an extension.
So much so that rustc regularly has to disable their noalias annotations because its pervasive noaliasing exercises rarely used LLVM paths and leads to miscompilation. Outputting noalias is currently disabled again in IR generation[0][1].
Note from downthread comments in [1] that it's completely possible to create valid C code which miscompiles on both GCC and LLVM (though GCC has been fixed since), it's just unlikely that a regular C dev would write the mix of unrolled loops, inlined functions and restrict annotations which triggers the issue.
And my understanding's it's since been fixed in GCC.
I don't doubt for a second there will be new miscompilations discovered after that one's fixed though.
Can you point us to a concrete benchmark to illustrate this?
Lower-hanging bigger fish?
Rust isn't mature yet. Give it ten years. It will either exceed C performance, or fade away. It's still too early to say which.
There's a `restrict` keyword in C99.
> const really means const, where in C the compiler has to assume any pointer-to-const might be use to write through
Lookup what `const int *const ptr` does in C.
What the parent is saying is essentially right. C++'s compile time polymorphism and lamdas can allow faster than C given the right subset of language chosen. For instance std::sort regularly outperforms qsort(3).
Yes, if by that you mean "idiomatic C++ as C++ programmers write it".
It's the inexperienced "C/C++" (no such thing, BTW) that are 'choosing subsets', and doing it wrong 90% of the time.
That's blatantly not true. Strousup himself contributed to the joint strike fighter C++ coding standard which has things like "Allocation/deallocation from/to the free store (heap) shall not occur after initialization." which means that the STL is off the table for example.
Beyond that, there's pieces like RTTI/dynamic_cast that should be avoided for a lot of reasons, perf being one of them.
So, no, the STL is very much on the table, as in any competently constructed work product.
Why should Rust beat C? First, it does not suffer from the pointer aliasing faults C has. Second, const really means const, where in C the compiler has to assume any pointer-to-const might be use to write through. Because alias analysis is ironclad, copies can be elided even if some function borrows a reference to the copy.
At a larger scale, improved abstraction tools mean more powerful libraries may be written and used, that would be unavailable to the C coder.
It is routine for C++ programs to be substantially faster than a C program that attempts the same job, even though C++ suffers from the same aliasing flaws C has. In the finance world, you would be laughed out of the room for proposing C for a performance-critical task.
This is why articles about other languages comparing them to some fraction of C performance are amusing. C is a low bar. If you can't beat C, you are Doing It Wrong. In Rust's case, that would be "still doing it wrong"; we may assume fixing this is on the schedule, after various "getting it right" and "compiling faster" goals are met.