# Why is C++ still a very popular language in quantitative finance? [closed]

I had to ask this question after reading the answers to What programming languages are most commonly used in quantitative finance? I understand that C++ programs can be optimized pretty well and are faster than anything else. But in this era, the performance of a program written in a language based on frameworks such as C# and Java can be pretty close to that of C++, while the maintenance cost of the program would be lower than the C++ one. But why is C++ still a very popular language in QF?

-

## closed as off topic by pyCthon, chrisaycockFeb 13 '13 at 18:54

Questions on Quantitative Finance Stack Exchange are expected to relate to quantitative finance within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

@Belmont I actually found one faq in this site that says C++ is the most popular one in QF. That led this question. But I don't mind moving this question to more appropriate site. Please do so if necessary. –  Tae-Sung Shin Aug 25 '11 at 4:03
@Taesung: Could you give the reference? Or perhaps you should change the question from "still the most popular" to "still very popular". –  vonjd Aug 25 '11 at 6:58
@vonjd Updated my answer with the reference. –  Tae-Sung Shin Aug 25 '11 at 13:55
I am very tempted to close this question, and indeed there are a couple votes already to close it. The question you cite already answers this question! C++ is popular because (1) the boss pays people to use it, and (2) data vendors have, at least historically, only provided proprietary APIs in C++. –  chrisaycock Aug 25 '11 at 15:45
@chrisaycock the previous question only answers this question tangentially. I agree it is borderline, but I believe this question can stand on its own, especially in light of the excellent answers given here which mention information not given in the previous question. –  Tal Fishman Aug 25 '11 at 16:39

The other posters have already noted that the prevalent use of C++ appears to be due to historical reasons and unwillingness to change. Those reasons aren't the ones that people should be applying. If you want real reasons to use C++, how about the following:

• Powerful infrastructure. Take a look at Intel Parallel Studio for an example.
• Performance compared to .Net or Java. When each array element access checks the bounds and throws exceptions, you know you're leaking CPU cycles there.
• Parallelization. The C++ ecosystem has vastly superior paralellization in both 'blind' mode (OpenMP vs TPL's Parallel) and explicit mode (Intel TBB vs TPL)
• Lots of SDKs, most notably CUDA, base their development on C/C++.
• Possibility of invoking low-level CPU instructions (e.g., work with SSE intrinsics).

On the other hand, C++ is

• Extremely noisy. What with all the headers, include directives, friend class declarations, and myriads of other redundant things.
• Has hard-to-use libraries (STL, Boost) with very cryptic, global-level mechanisms. Think bind_2nd :)
• Editor support is vastly inferior compared to IDEA/ReSharper. Navigation, refactoring, analysis - all are weaker or non-existent. This is going to be improved in the near future for both VS and standalone editing.
• Compiler errors are beyond cryptic. Clang attempts to fix it to some extent, but things are still cryptic, just not as abysmally bad as they were previously.

And by the way, for the typical user, the performance difference between C++ and, say, C# won't be as pronounced.

-
"When each array element access checks the bounds and throws exceptions, you know you're leaking CPU cycles there." This is not true. JIT will remove plenty of array bound checks. Pure computational performance (ignoring memory allocation/deallocation) under .NET runtime (ignoring vectorization) is pretty close to the performance of raw C++. –  LeakyCode Aug 26 '11 at 20:21
I concur with Mehrdad wrt Java. I was easily able to engineer Java-based quantitative trading models that were just as fast as C++. I worked in both languages at different firms and can tell you that well-written Java can be as fast as C++. –  Dave Aug 29 '11 at 2:09
@Dave I suspect you've been comparing near-identical code, which doesn't reflect the fact that in C++ you can explicitly use SSE. I also suspect (haven't tested) that OpenMP beats Java parallelization (unless you handcraft it) just the same as it beats .Net's TPL. –  Dmitri Nesteruk Aug 29 '11 at 6:24
@user492238 almost all C++ code I've seen that used SSE (graphics and physics engines) use compiler intrinsics. When I played around with SSE, I also used intrinsics. –  Dan Feb 20 '12 at 20:49
@Dmitri Nesteruk "Compiler errors are beyond cryptic", clang largely fixes this. –  Dan Feb 20 '12 at 20:49

The main reason is traders/quants currently in business often learned C++ in their formation rather than C#, they naturally used this language when starting new projects.

It will gradually evolve, I guess you could have asked "what's the reason cobol is still the most popular language in Finance" 20 years ago.

Also most projects in production use C++ but I think now most new projects gradually evolve towards C#/Java.

-
Cobol analogy makes sense. I wondered if there is any hidden reason I missed. –  Tae-Sung Shin Aug 25 '11 at 4:00
This is a good point: I've been forced the write something in C# the past month because an API was only available in C#. They claimed C++ was supported, but gave no usage examples, and basically refused to answer C++ related questions. –  Darren Cook Feb 9 '12 at 1:59
Maybe, but modern C++ libraries such as Boost (and everything added to TR1/TR2 and C++11 derived/inspired by Boost) have made C++ much more of a palatable language to use. –  Sashmit Bhaduri Feb 19 '12 at 16:35

Garbage Collection. The amortized performance between C++ and more modern languages is similar, but when your heap gets large, a GC can still take 100ms or more! That's an eternity, and just isn't acceptable for anything with real-time requirements

-
Agree! Latency is a key factor in QF application. –  Dagang Aug 30 '11 at 10:06
Garbage collection is indeed a huge concern but keep in mind that you always have control over when garbage collection will happen. It's a balance between suffering from memory leaks and having to have a system that may need to be tuned. –  Mauricio Bustos Sep 7 '11 at 1:59
Honestly, 100ms is absurd for garbage collection. Something like this is more the relic of poorly profiled code. –  Michael WS Sep 14 '11 at 0:26
@Todd HFT is only a subset of QF. –  Gaius Feb 20 '12 at 19:50
You can have garbage collection in C++ too, so it can't be cited as an advantage of Java. Java often forces an unflexible paradigm on the user on the ground that "they know better", while C++ lets you free to adapt wisely. Unsurprisingly Java was repeatedly forced to backstep and readopt features of C++. Security of Java also turned out to be vastly exhaggerated. –  Quartz Feb 13 '13 at 9:55

I don't know if it the most popular but it is popular for sure - I think there are several reasons for that, which not only apply to QF:

• It is a mature language with many years of development behind it
• There are many people who are able to program it
• Many books, tutorials, websites, communities are available (network effect!)
• It is fast
• There are many libraries available (also math and quant-oriented) - and it is transparent what happens within these libraries (which is sometimes not the case with proprietary higher language toolboxes and systems)
• There are sophisticated free compilers which make it possible for academia and basically everybody to start exploring the language
• It is a hybrid with which you can - but need not - program in an object-oriented way
• The resulting code can run on its own but can also be connected to other programming systems

There are few languages out there that have all of these characteristics - but there will finally be a transisiton at least towards C# and Java (This is already happening).

-
To sum up your answer: "Risk aversion" ;) –  wburzyns Aug 25 '11 at 10:45
@wburzyns: There is this saying concerning computers: "Never change a running system" ;-) –  vonjd Aug 25 '11 at 12:43

People use C++ because it offers a balance between performance and convenience. It is true that you can get Java to be (almost) as fast as C++, but you need to put a lot of effort into it. On the other hand, an average-quality C++ code will be much faster than average-quality Java code. I know this from personal experience.

-
I wonder how to define "average-quality". Is this on a subjective scale, taking into account personal bias? –  user492238 Feb 10 '12 at 20:21
@user492238 average is described here as expected value EX where X is time of execution of the choosen program –  tinky_winky Mar 12 '13 at 10:56

Whichever treasury system the banks implements it will have pieces in C/C++ and/or Java. So C++ is just easier to interface.

Also, as little as the difference of performance is, it does matter if you need to plug that model in a Montecarlo simulation running hundreds of scenarios - for value at risk computation.

-
However I have read that with language like Scala and JIT compilation the performance of Java VM can be very competitive compare to C++. Perhaps that will catch up. –  Daniel Da Cunha Aug 28 '11 at 17:24

Not all will agree that "the maintenance cost of the program [is] lower than the C++ one." For just one thing, when we use C# or similar, we have to wrestle with the C# "framework," which aims, but often fails, to deliver a "richer," "more powerful" development environment. But "richer, more powerful" is in the eye of the language designer or design committee and often translates, on the mat, to "a briar patch of needless complexities, obstructions, irregularities, dead ends, unexpected stupidities, counterintuitive rules, and lazy, dumbass assumptions."

C and C++ (and, yes, assembler) present no such hurdles, which considerably eases programming and maintenance.

-
very interesting view. Even if somehow... well: subjective ;) You obviously spend much more time on C/C++ then you did on C#. And this is no critism. But it could explain your bias towards C. I remember every language at the beginning seemed to be build out of "counterintuitive rules".. ;) –  user492238 Feb 9 '12 at 10:01
You don't find C++ to be full of "needless complexities, obstructions, irregularities, dead ends, unexpected stupidities, counterintuitive rules, and lazy, dumbass assumptions." ? Maybe you're thinking of C and extrapolating. –  John Tyree Feb 14 '13 at 15:23

The optimization possibilities offered by C++ templates can make code potentially very fast; faster than C, and faster than Java could ever hope to be. (A C programmer will typically use a function pointer and a compiler cannot inline that; a C++ functor can and will be inlined.)

I know C# has templates that look like C++'s but I cannot personally comment on speed benefits. C# is too closely tied in with Windows. And Windows is not a good platform to build financial systems on (IMHO, but also that of the LSE and others ;-) And don't get me started on DLL Hell when you try to mix APIs from two companies...

[Feb'13 UPDATE: Ironically I've done a lot more C# in the year since writing that. (And that is an indication of its growing support, even going so far as some companies offering a C# API instead of a C++ API.) C#/Mono works well (but the people offering C# APIs are foolishly not testing on Mono and letting needless Windows dependencies in; foolish because it limits their potential audience). Finally, C# templates are instantiated at run-time, so it is not possible to do those the C++ compile-time optimizations.]

I do agree with others that the tide may be turning against C++, but C++11 may give it a new lease of life. The speed and power is still all there, but the auto keyword and the built-in lambdas (to name but two) can make the code look much cleaner (meaning easier to maintain and harder to introduce bugs).

Finally, as a reason to use C++ in finance, there is Rcpp and RInside !

-
templates != speed increase. Sometimes templating can result in increased inlining, which can sometimes increase performance. There are also template metaprogramming techniques that can increase performance. C++ speed advantages mostly comes from the excellent compiler optimizing, and the fact that there is no GC or interpreter. –  windfinder May 4 '12 at 19:20

Its because the people still "think", it must be faster and hence favor C++. Real arguments are sparse. Some of the most ideological arguments:

1. 'Bound checks on every array element access.' But in relevant loops they can be removed in C# and are automatically removed in Java (Hot Spot VM) and CLR often.
2. 'GC is slow.' Yes it is slower on collecting garbage. But allocations are much faster then in C++! And VM language developer are made to implement pooling strategies to circumvent allocations nearly completely. This, at the end, is even faster than the frequent new/delete in C.
3. 'SSE instructions only in C++.' Partly true for .NET. But instead of optimizing the very end of uniprocessor performance, one should rather optimize the memory usage, which is a real challenge for our common large datasets and by far the biggest reason for slow execution nowadays.
4. 'Superior parallelizm.' How that? OpenMP & Co use the same system resources and synchronization constructs which are available to, lets say, .NET as well. It is - as always - up to the user to utilize them in an efficient way. Especially if it comes to thread level parallelism higher level languages provide more comfort to be written.

At the end, every system is heterogenious. The choice of a language for a specific task should not be biased by the personal experience too much, but rather reflect the abilities of the language to get the work done fast and reliable. I would not use C++ for user interfaces anymore. C# is better at that - and equally good for many tasks which were assigned to C++ uniquely in the past.

-
2: see my comment above on GC: you can do GC in C++ if you want, while you can't easily avoid it in Java. C++ lets you free to chose according to the situation, while Java forces a suboptimal allweather compromise (also in other cases, such as unsigned). \\ 3: red herring: again memory usage is surely critical, but that's true in all languages, and the ability to additionally optimize calculations is a clear plus. Impeding FP performance optimization does not improve memory usage in any way, so why should that be good? –  Quartz Feb 13 '13 at 10:07
Ah, I forgot, some SSE instructions even specifically target memory performance optimization! –  Quartz Feb 13 '13 at 10:15

C is tought at courses at universities everywhere. And people invested many time and efford to get into it. Now we want to collect the fruits and not reinvest into any new platform/language. But the IT world is changing so fast as does the computer architecture. "Next Generation" developers are used to handle C# and Java even more than C++. And they are getting tired of changing platforms - if everything they need is already there. I have switched to Visual Basic 6 years ago and didn't regred so far.

-

I do agree with the argument on historic reasons, speed and GC with regarding the original question.

To add my 2 cents to the rest of the discussion, I believe that Scala/Akka combination will gain a strong foothold in QF. Of course Languages like Erlang did exist long before Scala/Akka, but did not get much footing due to its esoteric nature and cryptic syntax (at least for people familiar with C/C++ like languages) and not many used it. Scala syntax is also cryptic but there is a growing user base and IB and funds have started using it.

Also another language to watch-out is F#.

-

I will focus on some of the many reasons why we prefer C++ to Java, while I dont have much experience with C#. First of all various answers here have brought up valid points on why C++11 is way more practical than other languages, once the learning phase for advanced features is mastered, especially for large numerical projects, so I need not repeat things like why having control over GC is a significant advantage.

Java is mostly geared towards an OO paradigm, while C++ additionally offers functional programming and a very powerful template metaprogramming framework (Java generics are not really comparable, neither do C#'s templates do significantly better afaik).

For numerics various Java issues can be a burden, such as the absence of unsigned integers (although this has been corrected at last) or slow performance of trigonometric functions. Let alone access to SSE/AVX, and the lack of control over bounds checking. And operator overloading in Java is also not really supported: can you really write any numerical code without that? And every Java object occupies at least 8 bytes, which has become a significant overhead with memory access becoming slower (especially in machine learning, but I bet in HFT too). Missing adressing also renders many data structures unnecessarily heavy, and some are even impossible to implement in Java. The virual machine sometimes pollutes the code cache too, then there's class loading and other overheads...

Also the absence of function pointers is an issue, and the "alternative" Java idioms have their drawbacks.

Furthermore afaik multithreading in Java is not so practical, and is shifted down to multiprocessing (please correct me here). Interfacing to other languages through JNI is a real pain (or atleast so was at the time when I had to).

As far as I know there's no advanced library comparable to Eigen in Java or C#, for example; new HPC projects are still dominated by C++, and these are only some of the reasons.

Java and C# for sure are more convenient for other tasks and have a much softer learning curve, but so do even VBA or plain old Excel.

Also check this related comment.

-
Do you actually use Eigen as a quant? –  chrisaycock Feb 13 '13 at 18:30
Not in the current project since they're still stuck with legacy code, but I've used it with full satisfaction in the past (and plan to do it again whenever possible). I also know some people deep in the HPC linear algebra R&D world, and their way more competent appreciation is significant. Unfortunately quants cannot always carry out a throughout comparison before adopting a lib (and many dont even have the numerical background to do so), so historical reasons dominate technical considerations, but my impression is nevertheless of slow but steady adoption growth. –  Quartz Feb 15 '13 at 9:29

## protected by chrisaycockAug 29 '11 at 19:32

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.