Why does a derivative trading position always require C++ knowledge?

Question

I’ve never worked in a trading environment before and I was curious to see that few of the trading houses seem to use C#, but most of them do heavily rely on C++. Why is it?

1. Is it because C++ is better performance wise?
2. Is it because of legacy code bases?
3. Is it because of cross-platform issues?
4. What about dynamic languages (Ruby, Python)? Are they too slow for this kind of work in terms of performance?

Updated: If reliability and performance are important would "Erlang" be the "next big thing" in trading platforms?

Answer 1

Because of Speed. C++ is way faster than C# and Java. So although it's harder to develop, but the sheer programming executing speed you gain translates vastly into trading profits.

Latency orders are important here. Every microsecond counts, especially in High Frequency trading. I doubt whether the JIT or JVM can do that well in matching C++ performance.

Answer 2

Because that's what the systems are written in!

Sophisticated derivitives started being widely traded in the early to middle 1990s.

This was the same period that C++ was the next big thing. So the early trading systems and supporting analysis were naturally written in C++. Smalltalk, APL, SAS and even Lisp were also used, but C++ came to dominate.

The result is a large number of existing platforms, and domain libraries are written in C++ so it's just common sense to write the new stuff in C++ as well.

There is a similar situtation in retail banking where mainframe and COBOL were the hot technologies when the first systems were written, and most retail banks still use mainframe/COBOL extensively, even for new development.

Answer 3

Legacy issues aside, a lot of newer systems in this space are still being built with C++ for a few reasons, particularly performance concerns (the best optimizing compilers are still for C and C++, you can write inline asm easily, you can access SIMD instructions easily, etc) and the fact that people with quant or options experience typically have C++ experience from their last gig, so it becomes the default even in brand new from-scratch development projects.

Languages like Python, Ruby, R, etc are used a lot 'out on the fringes' (for administration tasks, automation, database manipulation, etc), but mostly the core systems of these shops are all C++.

Answer 4

I remember hearing a while back that writing real-time applications with garbage-collected languages was an issue; that might be part of it, as trading is pretty much real time.

Answer 5

I think you're not seeing a broad spectrum of these kinds of positions. C++, C# and Java are all common as are mixed environments. Sometimes even when C# or Java are used you'll find key parts done in C++. The key parts are:

1. Market communication: you need the lowest latency possible; and
2. Price calculation: most option pricing models use Black-Scholes (or some variant). You may need to reprice a lot of instruments many times a second. Speed is important for that.

Legacy code is another reason. But the need for C++ these days is only in small parts of the overall system.

Answer 6

See this question regarding techniques used for space hardening. Real-time trading software is treated just as critically.

It's not just about execution speed, and speedups obtained by compiler optimization, it's also about reliability.

I suspect that's going to change a bit in the coming years. Java has made great strides in its stability and footprint. However, it's very likely that you'll be working on existing code, which is likely written in C, C++ or both.

Answer 7

John Lakos (of Large-Scale C++ Software Design fame) used to work for Bear Sterns; I think his book was rather influential. It showed how C++ could be used to build large applications. The "large" part is quite important, languages like C or Perl simply don't scale well past 100 developers. In fact, it's no coincidence that C++ came from AT&T. They used C for a number of their own projects (naturally, it too was a Bell Labs language) and Bjarne noted C's limitations in the real world.

Answer 8

I don't think this is actually the case. It just depends on the specific field of derivatives trading. The high frequency trading people probably (think they) need the performance of C++, and legacy systems could also be an issue in places. However, firms with a more technical/fundamental and more long-term approach are more interested in ease of development, and this is reflected in the languages used. I think I've read somewhere about a firm that was erlang only. I know there are a lot of places that use mostly SAS. There is a lot of java usage all round... anything goes really.

Also, a lot of the people doing the programming at trading firms -though probably very smart people- are not necessarily good programmers. Something as complicated as C++ might very well just be out of their league.

The lack of C# jobs might be because it is rather new. If all you see are C++ shops then your search job-strategy is biased.

Answer 9

I have worked in the trading area off and on for 20+ years. As time has gone on C++ has been used less and less. I would say the bulk of C++ has been lost to Java and latterly C#. C++ is still used for pricing and risk calculations, this is because this is where most of the processing goes. In high frequency trading they need to turn round pricing in as short a time as is possible. In lower frequency exotic trading pricing and calculating risk just takes a large amount of processing power. It can require 100's or indeed 1000's of machines (known as a Grid). Overnight risk runs can take hours even with those resources. So here speed is also an issue but in a different way. I think in time C++ will be pushed from these areas too, but this will be slow to change as there are huge historic code bases that must work reliably and process known results so changing anything is a high risk process.

Answer 10

The real reasons for using C++ over C# in trading houses aren't really touched in any of the other answers. Some are flat incorrect.

1. The first, most important reason is that C++ has been around a far longer time than C#. That's much like COBOL. There's many millions of lines of COBOL still used in banks and government that was written in the 70's and 80's because the cost of totally rewriting it in C, C++, Java, or C# doesn't make sense. So, many companies keep legacy code around nearly forever. Most of the answers here came from "techies" (like you and I) who are rarely the decision makers. Unfortunately, it's non-techies, managers who decide these kinds of things and often for totally non-technical reasons. Ever read Dilbert?

2. The second most important reason is the reliability of the Operating System. Traders need reliability even beyond speed. Windows Servers notoriously crash frequently, need regular rebooting, whereas the *nixes can run for many months without stopping. Many of these firms trade markets around the world so they dislike any unexpected downtime. Since the trading firms run all their systems on *nixes, they tend distrust Micro$. Yes, of course, you can use C# on Linux on Mono but that's not nearly as exciting for various reasons.

3. Performance? I'm the author of a C# trading application that performs faster than most trading apps written in C++ and I did it in C#. How? Unlike Java, C# has an "unsafe" mode so you can do C++ style code with pointers for performance.. Plus you can use C++ style structs which is the most important aspect of performance. For critical code, you manage your own memory in C# just like C++ by preallocating so you never need garbage collection when running real time. C# can, in fact, even run faster that C++. It's been tested and proven. How? Why? Read on. Plus, it's really nice programming in C# over C++ for all the non-critical path parts of the code. Why? It's because of all the tools that are available and easily created like Unit Testing and others due to the "reflection" ability of C#.

You can only definitively say whether one is better than the other if you actually compare the machine code generated by both for the same piece of code and do micro benchmarks as comparisons.

CONCLUSION

The reasons for C++ over C# are business reasons. Interestingly my company has trading fund and bank customers using C# for trading system development based our platform, TickZoom which is also in C#. So why are they using C#? Again that's a business, not a techinical decision. These particular managers of these trading funds and banks are new-comers to the high frequency automated trading world. So they don't have any legacy code. Therefore, with a clean slate they can make different choices.

So how do they arrive at C#?

As a business decision, good C++ developers are very, very expensive. Plus the manager read reports from business mags who show that time-to-market of C# apps is generally faster than comparable projects in C++. So some businesses will tend to look at C# since it can perform and there's a larger developer pool.

NOTE: Some people experiment (like I have) with taking certain pieces of code and writing them in C++ as libraries for C# to use to get faster performance where needed. However, those efforts have always been proven that somebody can tweak C# to go equally fast so it becomes easier to just do it all in native C#.

Just to qualify this answer, I have worked for 25 years as a real time and network programmer using C, C++, Java (mostly web stuff), and now C# approximately 5 years with a few years in other languages like Assembler, COBOL, BASIC, Pascal, etc. My experience has been in communication networks, phone networks, banking systems for high speed imaging, high frequency trading, and more.

Having coded in C++ and C# for equally long periods of time, it would be painful to return to C++ because I feel forced to deal with low level issues in the language which allows for speed but create complexity in parts of the app where speed is of no concern. <-- That's the majority of the app, actually.

Plus, there a no tools really nice as JUnit or NUnit of PyUnit in C++ for automated unit testing. I can't even imagine programming the old slow poke way of code and fix without automated unit testing, mock objects, and such which are necessary for "agile" development.

What I do admire about C++ is how much money the programmers make are are strong in the system and real time programming fields! That's for sure. But I do alright with my own company now doing high performance C#.

Sincerely, Wayne