50
$\begingroup$

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?

$\endgroup$
13
  • 2
    $\begingroup$ @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. $\endgroup$ Aug 25, 2011 at 4:03
  • 1
    $\begingroup$ @Taesung: Could you give the reference? Or perhaps you should change the question from "still the most popular" to "still very popular". $\endgroup$
    – vonjd
    Aug 25, 2011 at 6:58
  • 1
    $\begingroup$ @vonjd Updated my answer with the reference. $\endgroup$ Aug 25, 2011 at 13:55
  • 2
    $\begingroup$ 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++. $\endgroup$ Aug 25, 2011 at 15:45
  • 3
    $\begingroup$ @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. $\endgroup$ Aug 25, 2011 at 16:39

12 Answers 12

50
$\begingroup$

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 (see my course on HPC). 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.

$\endgroup$
14
  • 4
    $\begingroup$ "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++. $\endgroup$
    – mmx
    Aug 26, 2011 at 20:21
  • 4
    $\begingroup$ 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++. $\endgroup$
    – Dave
    Aug 29, 2011 at 2:09
  • 2
    $\begingroup$ @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. $\endgroup$ Aug 29, 2011 at 6:24
  • 1
    $\begingroup$ @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. $\endgroup$
    – user2078
    Feb 20, 2012 at 20:49
  • 1
    $\begingroup$ @Dmitri Nesteruk "Compiler errors are beyond cryptic", clang largely fixes this. $\endgroup$
    – user2078
    Feb 20, 2012 at 20:49
23
$\begingroup$

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.

$\endgroup$
3
  • $\begingroup$ Cobol analogy makes sense. I wondered if there is any hidden reason I missed. $\endgroup$ Aug 25, 2011 at 4:00
  • $\begingroup$ 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. $\endgroup$ Feb 9, 2012 at 1:59
  • $\begingroup$ 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. $\endgroup$ Feb 19, 2012 at 16:35
22
$\begingroup$

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

$\endgroup$
7
  • 2
    $\begingroup$ Agree! Latency is a key factor in QF application. $\endgroup$
    – Dagang
    Aug 30, 2011 at 10:06
  • $\begingroup$ 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. $\endgroup$ Sep 7, 2011 at 1:59
  • 3
    $\begingroup$ Honestly, 100ms is absurd for garbage collection. Something like this is more the relic of poorly profiled code. $\endgroup$
    – Michael WS
    Sep 14, 2011 at 0:26
  • 1
    $\begingroup$ @Todd HFT is only a subset of QF. $\endgroup$
    – Gaius
    Feb 20, 2012 at 19:50
  • 1
    $\begingroup$ 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. $\endgroup$
    – Quartz
    Feb 13, 2013 at 9:55
18
$\begingroup$

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

$\endgroup$
2
  • 4
    $\begingroup$ To sum up your answer: "Risk aversion" ;) $\endgroup$
    – wburzyns
    Aug 25, 2011 at 10:45
  • $\begingroup$ @wburzyns: There is this saying concerning computers: "Never change a running system" ;-) $\endgroup$
    – vonjd
    Aug 25, 2011 at 12:43
12
$\begingroup$

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.

$\endgroup$
3
  • $\begingroup$ I wonder how to define "average-quality". Is this on a subjective scale, taking into account personal bias? $\endgroup$
    – user492238
    Feb 10, 2012 at 20:21
  • 6
    $\begingroup$ @user492238 Subjective, like all the discussion about this question. $\endgroup$
    – quant_dev
    Feb 11, 2012 at 17:37
  • $\begingroup$ @user492238 average is described here as expected value EX where X is time of execution of the choosen program $\endgroup$
    – 4pie0
    Mar 12, 2013 at 10:56
9
$\begingroup$

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.

$\endgroup$
1
  • 1
    $\begingroup$ 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. $\endgroup$ Aug 28, 2011 at 17:24
8
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ 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".. ;) $\endgroup$
    – user492238
    Feb 9, 2012 at 10:01
  • $\begingroup$ 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. $\endgroup$
    – John Tyree
    Feb 14, 2013 at 15:23
8
$\begingroup$

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 !

$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – windfinder
    May 4, 2012 at 19:20
4
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ 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? $\endgroup$
    – Quartz
    Feb 13, 2013 at 10:07
  • $\begingroup$ Ah, I forgot, some SSE instructions even specifically target memory performance optimization! $\endgroup$
    – Quartz
    Feb 13, 2013 at 10:15
3
$\begingroup$

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.

$\endgroup$
2
  • $\begingroup$ Do you actually use Eigen as a quant? $\endgroup$ Feb 13, 2013 at 18:30
  • $\begingroup$ 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. $\endgroup$
    – Quartz
    Feb 15, 2013 at 9:29
2
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

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

$\endgroup$

Not the answer you're looking for? Browse other questions tagged or ask your own question.