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.
Because they have no idea about C++11? Usually those who treat it this way obviously don't know C++.
Why is C++ still a very popular language in quantitative finance?
31–40 of 51 posts
Re: Why is C++ still a very popular language in quantitative finance?
#32For 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 bottlenec…
[deleted]
Re: Why is C++ still a very popular language in quantitative finance?
#33For 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 bottlenec…
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++.
Re: Why is C++ still a very popular language in quantitative finance?
#34It always amuses me the way people treat C++ like it's some kind of dark, corrupting magic that no right thinking person would use.
I find the cachet that C++ has when you interview for jobs at financial corporations to be equally depressing and hilarious.
When you go in to interview for a C++ position, the guy starts off by looking at you like you're some kind of brain damaged impostor who eats babies when nobody's watching and starts asking about how sizeof works on pointers to member functions or when "inline virtual" does and does not inline something. Essentially, incredibly dick-waving arcane compiler-specific stuff that no one should ever have to know because it makes for really horrible C++ code.
And vice versa when you interview for a Java/C#/Python/whatever position and some of the interviewers drop how they gave up on all that and then look on in admiration when a conversation about actor model drifts into using atomic pointer swapping to build worker queues.
None of it matters, the C++ masochist questions are more an indication of the kind of people you'll be coding with more than anything while the Java/C#/Python/whatever guys are still working on difficult algorithms.
Moral of the story: Since the hardest part of working in C++ is passing the ridiculous interview questions, might as well stick with it to still appear like a wizard. It's all just programming.
Re: Why is C++ still a very popular language in quantitative finance?
#35And 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.
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.
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;
Re: Why is C++ still a very popular language in quantitative finance?
#36I'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.
Re: Why is C++ still a very popular language in quantitative finance?
#37Earlier quoted context omitted.
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…
Aren't C++ smart pointers essentially reference counting? That's well known to be much slower than well implemented GC.
GC may be faster in terms of total amount of time spent managing memory but smart pointers are more predictable. Many domains in which C++ is used are more sensitive to the performance spikes that can arise in GC'd environments than they are to the more expensive but also more spread out cost of managing reference counted objects. Many video game technical directors would choose spending 1ms/30hz frame in memory bookkeeping rather than going 29 frames with no problems only to encounter a 15ms GC hiccup.
Re: Why is C++ still a very popular language in quantitative finance?
#38C++ is harder to reverse engineer than say java, no? I would think this plays a rather large part in it as well.
Re: Why is C++ still a very popular language in quantitative finance?
#39Earlier quoted context omitted.
SecDB/Slang outside of Goldman?
No SecDB/Slang outside of Goldman because it is completely proprietary, but the single platform vision within has no signs of abetting.
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.
Re: Why is C++ still a very popular language in quantitative finance?
#40I'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.
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.