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

Question

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?

Answer 1

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++. (But you can use CUDA from .Net, too.)
• Possibility of invoking low-level CPU instructions (e.g., work with SSE).

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.
• Compiler errors are beyond cryptic.

And by the way, for the typical user, the performance difference between C++ and, say, C# won't be as pronounced (F# is another matter, though).

Answer 2

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.

Answer 3

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

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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 !

Answer 9

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.

Answer 10

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.

Answer 11

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

Answer 12

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.