
Why is C++ still a very popular language in quantitative finance? - princeverma
http://quant.stackexchange.com/questions/1764/why-is-c-still-a-very-popular-language-in-quantitative-finance
======
jandrewrogers
For applications bottlenecked by memory performance, like most analytical
databases, C++ will often be faster than a language like Java by an integer
factor. When people assert Java is about as fast as C++ they are talking about
CPU-bound tight loops and similar. It is difficult to make languages like Java
approach the memory efficiency of C++, hence why C++ is significantly more
performant for applications bottlenecked on the memory subsystem.

These days, more performance-sensitive codes are bottlenecked by memory
performance than by CPU performance. The throughput of CPUs has grown faster
than our ability to keep those CPUs fed from memory. In the supercomputing
world this started to become evident years ago; memory benchmarks like STREAM
became more closely correlated with real-world performance than CPU benchmarks
like LINPACK for a great many algorithms. The resurgence of C++ is partly
driven by this reality since it makes memory optimization relatively
straightforward.

~~~
mrich
This cannot be emphasized enough. High-performance algorithms are constrained
by memory latency/bandwidth and the CPU caches. Java, with its large per-
object space overhead is not well suited for this. You need special case
libraries to get the same performance, and in many cases you can just as well
use modern C++.

------
krakensden
It always amuses me the way people treat C++ like it's some kind of dark,
corrupting magic that no right thinking person would use.

~~~
ajross
To be fair, C++ is a mess. It is, however, a very capable mess with extremely
broad adoption and compatibility on pretty much every platform anywhere.

Yes, learning C++ is a pain. And it will bite even its expert handlers pretty
badly occasionally. But the kind of maintenance overhead suggested by the
stackexchange question really isn't there. For non-trivial code (as in the
example here) the maintenance and correctness burden of the problem itself is
going to be far higher than that of the programming environment.

So yes: just say no to C++ for web server middleware, system maintenance
scripting, probably most GUI work, etc... But for the truly hard stuff, I
honestly don't see much advantage to anything else in particular. And as
pointed out earlier, C++ can be deployed as a straightfoward program or shared
library on everything with zero dependencies, and that's a HUGE advantage vs.
languages with elaborate runtimes.

~~~
Someone
_"To be fair, C++ is a mess. It is, however, a very capable mess with
extremely broad adoption and compatibility on pretty much every platform
anywhere."_

C++, IMO, is not alone in that: XML, Unicode, multi-threaded programming using
condition variables and mutexes, integer modulo arithmetic, date/time
libraries, IEEE floating point, etc.

The good thing of all of them is that they solve complex real-world problems.
The 'bad' thing is that they are more complex than other technologies that
solve the same problem, partly.

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

If you include memory usage in your performance comparison (which is very
important for parallel programming), C++ is leagues ahead.

~~~
fauigerzigerk
I totally agree, and I have complained about Java's lack of structured value
types many times before because they are the main reason for Java's crazy
memory usage.

However, the gap has narrowed significantly with the introduction of pointer
compression in Java. It only works up to 32GB though, so this is going to be a
temporary boost for Java I guess.

~~~
azth
Could you point me to any references about pointer comparisons in Java? How is
it different than

Object a = new Object(); Object b = new Object(); boolean bool = a == b;

~~~
fauigerzigerk
I said "pointer compression" not "pointer comparison".

------
bradleyjg
There are a bunch of really expensive, really useful, 3rd party libraries for
financial modeling that are written in C++.

A great many languages have support for calling external code, but debugging
the interaction tends to be more trouble than it is worth.

------
aleyan
It appears to be mostly inertia. People learned C++ and a few relevant
specialized libraries, so they keep on them.

Outside of a few relatively narrow topics like high frequency trading, trading
algorithms for direct market access and solving optimizations, the speed of
C++ is not needed. As a result I am observing more code development occurring
in higher level languages such as Python, R, Matlab and SecDb/Slang. Extremely
time or latency sensitive tasks are offloaded from these scripting languages
onto broker algorithms or other third party libraries.

~~~
gaius
SecDB/Slang outside of Goldman?

~~~
aleyan
No SecDB/Slang outside of Goldman because it is completely proprietary, but
the single platform vision within has no signs of abetting.

~~~
elemeno
When I was at GS it depended highly on which teams you were on. In FICC, where
I was, SecDB/Slang ran everything, but there where definitely signs that it
was falling out of favour elsewhere and more Java and C# projects were
emerging.

If I were to speculate, I'd say that although GS has a large technology
investment in SecDB/Slang, it's still a language that was invented a long long
time ago by technology standards (I don't know exactly when it emerged, but
I'd say it's safely a good two decades or more old), and it just doesn't have
the performance or features that new languages have with current generation
compiler and JIT techniques.

------
codex
These kinds of judgements-wrapped-in questions always come off as a bit
sophomoric. It's like an artist asking, "why do some painters still use oil
instead of colored pencil? Pencils are erasable, and so much easier to work
with. No nasty fumes!". Or an architect-in-training asking, "Why use concrete
and steel to build skyscrapers? They have so many constraints, and are so
ugly, and hard to work with." I appreciate an iconoclastic spirit, but not one
based on ignorance.

------
chrisaycock
I'm a moderator on the Quant Finance Stack Exchange. This link has been posted
to HN before:

<http://news.ycombinator.com/item?id=2934042>

And I'll say what said then: The accepted answer on the SE comes from someone
who doesn't even work in quantitative finance. In fact, most of the answers on
there are totally speculative and should be taken with the proverbial grain
they deserve.

~~~
elemeno
A reasonable grain I'd say :)

While I'm not a quant in anything other than job title (I'm a Quant/Dev
really), my experience in the financial world suggests that there are two main
reasons why C++ is used so often -

1) Legacy Code. When you've already got a C++ pricing platform and teams of
C++ devs, you're not going to suddenly rewrite it in another language.

2) Libraries. Almost every bank/hedge fund/trading house has well tested
numerical libraries that are in C++ already. These libraries have been very
well tested already and pretty much every aspect of their performance and
limitations is a known quantity. Given that, rewriting them in another
language is risky. When you're trading size you don't want to run the risk
that you'll hit bugs or new edge cases in your models.

For what it's worth, and take this with a grain of salt as well since HF isn't
really my area, I've also seen more than a few HF models that aren't in C++.
I've seen C# be used, along with Python and MLs. The time periods are so short
that a small increase in language speed doesn't really let you do a whole lot
more, and the models are changed so quickly that development time to bring a
new model to production starts to become the limiting factor instead.

~~~
chrisaycock
Here's the question that should be featured on HN:

<http://quant.stackexchange.com/q/306/35>

Essentially, C++ is popular because of existing code, particularly proprietary
third-party libraries. And you are correct; even HFT shops will use languages
other than C++, which is why anyone who's actually worked in this industry
will know that the answer to the question of popularity is _not_ performance.

And that's why I _hate_ that SE question so much. It was asked by someone
outside the industry and is mostly answered by people outside the industry.

------
jbarham
Having a PhD in physics doesn't necessarily mean you've been exposed to the
current state of the art in software development practices.

In my experience C++ is the default language in finance because of legacy
reasons and because they don't know any better. This was only a couple of
years ago and I saw some horrendously poorly written C++ code--virtually no
comments, early 90's style ("let me tell you about the STL"), no comments for
hundreds of lines--that was being used in production to value mortgage bonds
worth tens of billions of dollars. The group I was in had switched to using
Python with Numpy, and was much more productive for it.

------
alexchamberlain
The article states that C++ is no better for the average user. How many people
in QF are average?

------
16s
C++ is popular in other sectors as well. I use it daily and love it. I can
build Python modules with it (Boost Python) so Python coders can easily use my
C++ code. I can build Windows DLLs too so the Windows C# guys can use the C++
code as well and they never have to write a line of C++ (nor do the Python
guys). C++ is awesome for systems and embedded work. Boost is awesome too and
very easy to use IMO. I've no idea why so many people keep trying to find
fault with it.

I think many people are intimidated by C++ and never really dig in and learn
it well. If you do, you'll be a much better programmer because of it.

------
phaedon
I'm pretty sure this exact Stack Exchange post was linked on HN before.

------
veyron
Template metaprogramming still solves certain problems better than other
solutions. If it is not used obsessively, then there are better languages

~~~
zurn
What kinds of problems? I can't easily think of problems where C++ templates
are more powerful than metaprogramming facilities of high level languages like
lisp...

~~~
veyron
I didn't use the word 'powerful' because powerful generally refers to
expressivity. I'm most interested in performance.

C++ template metaprogramming gives you most of the expressivity of generic
programming without paying a large runtime penalty (because the resolution
still occurs at compile time, the compiler can take advantage of this). This
is in contrast to other languages, where run-time generic programming leads to
performance penalties.

Now, as the stereotypical example of how C++ template metaprogramming can
actually beat standard C programming, compare the performance of C qsort with
C++ std::sort.

~~~
mietek
Not all expressive generic programming techniques have run time costs. The
parent poster mentioned Lisp, in which macros are also usually expanded at
compile time. Furthermore, Template Haskell offers type-safe compile time
metaprogramming.

------
gte910h
Many Quants are not really interested in new languages. I know at least one
bank that's C++ and Perl, because that's what they know.

~~~
gte910h
That was a quote from a quant who works at a major bank in Atlanta. Odd thing
to downvote.

They're hiring btw, can't find enough C++ programmers who want to be paid 6
figures.

------
kazing
C++11 is a very modern language. It seems to be moving faster than Java these
days.

~~~
gaius
Exactly, many critiques of C++ are well and truly obsolete. What are the
practical advantages of Java's GC over C++'s smart pointers? Actually not
much, so why carry that overhead.

Plus the elephant in the corner of the room is that actually, write-once-run-
anywhere in the real world turns out to be, write on Linux on x64, run on
Linux on x64. In the Java world, they like to run one VM (JVM) inside another
(on Xen or whatever). Again why schlep all that around? The world is turning
back to native code, for good reason.

~~~
zurn
Aren't C++ smart pointers essentially reference counting? That's well known to
be much slower than well implemented GC.

~~~
beagle3
[citation needed]

Depending on how many cores you use, what processor you use, and other use
cases (e.g. copy-on-write, which is free with RC and super expensive with GC),
one of them can be significantly faster than the other. But for a non-specific
use case, it has been my experience that they are roughly equivalent.

The place where GC consistently excels is the "no random pauses" - most GCs
will occasionally need to stop the world, even when they can mostly do
incremental collections. Note that this does not mean they are slower - it is
just that the overhead tends to be concentrated in bursts instead of uniformly
spread out as in RC.

The place where RC consistently excels is reference loops, and less dependence
on implementation robustness.

~~~
chancho
You have a strange definition of "excel".

~~~
beagle3
Thanks! I managed to get the two lines confused, not sure how, and it is too
late to edit; just posted a correction:

The place where _RC_ consistently excels is the "no random pauses" - most GCs
will occasionally need to stop the world, even when they can mostly do
incremental collections. Note that this does not mean they are slower - it is
just that the overhead tends to be concentrated in bursts instead of uniformly
spread out as in RC.

The place where _GC_ consistently excels is reference loops, and less
dependence on implementation robustness.

------
ImprovedSilence
C++ is harder to reverse engineer than say java, no? I would think this plays
a rather large part in it as well.

