> 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.)

As an example, usually there is a default C++ implementation because C++ makes things easier for the programmer so it makes sense if you're at the end of the food chain that requires perfomance (ie you're not using a memory managed language in the first place because that's easier still). So then you benchmark it thorougly. Get stuck into all the perf numbers and analysing those. You note why you think you can shave X off because the latency is due to i, j and k measures that look as though they could be improved so that's probably worth a go. Now you can (at least sometimes) in your lab, replace one part with (say in this example, C code) and see if your perf stat ratios improve the way you think they should. Yes it is difficult. Yes there are plenty of times where you see nothing because the slow from the code you changed is actually manifesting in cache misses elsewhere.

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.

Are you agreeing or disagreeing?

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.

I felt it a reasonable answer, if you think not I probably can't help you. I have no idea what you think I'm aggreeing or disagreeing with. Did you reply to the wrong comment?

Having spent 15 years in finance, I've never seen C used for perfomance critical code. It's always been C++. Some shops use Java or C# with GC effectively disabled, but those are rare. If you can preallocate all of the memory you need, this may be fine, but not all trading systems have that luxury.

I'm also sorry if your exeprience has been similarly hostile. This is not a comment about which languages get used in which shops.

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).

I have not encountered any hostility. But if you don't know how to get better performance from C++ than you can get from C and lots of extra work, you probably will not be hired, most places.

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.

This conversation is now bordering on unhelpful. C has uses, some of them are compelling. Every finance shop I've worked in uses the linux kernel and drivers extensively. These are (mostly? all?) written in C. As is git. Nobody laughs. C++ has uses. Some of them are compelling. For a given case where these uses dominate nobody laughs. Claiming C is as obsolete as CRT monitors or 10baseT without any supporting evidence? Yeah, no thanks. Someone could take that the wrong way. Actually isn't this what Alexandrescou says about C++ because he's all about D nowadays? What Eckel did when he became all about Java (or is he now all scala?). Last time I saw footage of Stanley Lippman speaking he was being brutally disparaging of C++ and invoking in his defence Richard Gabriel describing C as "a virus" to make him look less hostile in comparison to other language warriors and wars. [2]

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

Maybe in ncmncm's circle they laugh at C developers, but trying to extrapolate that across the finance industry is not credible.

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.

You do all those things with C++ (or, for fpga, asic, etc., without). There is exactly zero benefit to dropping to C first.

And, nobody suggested anybody actually laughs at C developers. We just don't see them.

> You do all those things with C++ (or, for fpga, asic, etc., without). There is exactly zero benefit to dropping to C first.

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."

We have a case in English, as in all languages in its cohort, for discussion of counterfactuals, signaled by "would". If there were anyone proposing C for performance-critical code, they would be laughed at. Happily, none are.

This conversation is no longer of any benefit, but for the sake of you and your co-workers... Saying that C is predictably inferior, more expensive, and less maintainable shows a blatant amount of incompetence on how either languages operate. C++ only offers abstractions to (debatably) more easily allow for an object oriented design for codebases. Semantically everything that you can do in C++, you can do in C.

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.

You say you cannot write a C++ program faster than your C program, and I believe you. I say I can, and you may believe me.

I didn't say there was hostility towards one tech stack or another, I was just stating my observations/experience. In my experience, once a firm has one or two tech stacks, they don't really want to deviate too far from what's entrenched because, well, they need to have the talent on hand to support everything. This becomes exponentially harder if every developer chooses their language/framework of choice. Generally, though, if there's a compelling reason to break from the core competencies of the firm, exceptions may be granted (this was how Python first got its foothold in my first firm - I could easily, e.g. generate, Python wrappers over my C++ APIs that allowed me to do everything my business users wanted while still maintaining compliance control and audits over data changes).

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.

I've also worked in finance and nobody I've known reaches for C++ for performance over C - only convenience/comfort. For performance, one examines the compiled output, analyze the instructions, try to prevent pipeline stalls, etc. And if the compiler is generating dissastisfactory code, use assembly for those parts.