• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Why is C++ good for Quantitative Finance? Top 3 reasons

Joined
12/23/06
Messages
187
Points
28
This is what I saw in Willmott. Indeed, it is a very interesting and important question.

Dr. Duffy's answer is:
1. C++ is highly flexible an interoparable with everything on the planet.
2. Mature: supports multi-paradigm development.
3. It is an ISO standard (this means it will be around forever).

To me, the answers are quite abstract and general. It seems that this can also be the answer to "Why is C++ good? "

My top three are:
1. C++ provides encapsulation which makes program more stable and readable.
2. C++ promotes code reusability and is a good language for very big and complex projects which is needed to be worked by a team.
3. If you know C++, others will assume you are knowledgeable....

I think my understanding may be too mediocre and hope others can provide opinions on this issue. The other thing is I still dont see anything specific reason related to quantitative finance. Does anyone have a better understanding?
 
In my opinion, in addition to OO, C++ is fast enough to meet specific time requirement of some real-time financial applications. Or, we will turn to Java which is purely object oriented but is much slower~
 
In my opinion, in addition to OO, C++ is fast enough to meet specific time requirement of some real-time financial applications. Or, we will turn to Java which is purely object oriented but is much slower~
This is not totally true. If dead speed was a requirement, people would've been coding financial applications in assembly language... or in OCaml which is object oriented and functional which means, you can be more productive and expressive in this language than in C++. It just happens that C++ is king on the street because a lot of people know it and there is already a huge codebase established.
 
In my opinion C++ is good for quant finance by pure luck. C became popular because it was free and every single college ran on UNIX and it came with a free C compiler. The transition to C++ was then more or less straightforward.

Nowadays, there is a huge code base in place that is hard to replace hence, C++ is still the king.

BTW, the standard came really late in the games. C++ was already established by that time.

This question is similar to why FORTRAN is good for Physics... just luck like a lot of things.
 
In my opinion C++ is good for quant finance by pure luck. C became popular because it was free and every single college ran on UNIX and it came with a free C compiler. The transition to C++ was then more or less straightforward.

Nowadays, there is a huge code base in place that is hard to replace hence, C++ is still the king.

BTW, the standard came really late in the games. C++ was already established by that time.

This question is similar to why FORTRAN is good for Physics... just luck like a lot of things.
Of course, legacy code is a definite reason. However, does that mean without the legacy code problem, we will embrace the more recent languages (Java, C#, etc.) to implement the models? I have not yet form my own answer to this question. Can alain share some ideas on that?

I got the impression that most "new" features in the languages like Java are aiming at more effectively designing and implementing big systems. But for problems with a relatively small size, those solutions may not be very time and space economical. So I think that C++ is still a good compromise between the speed and implementation efficiency taking the problem size on trading desk into consideration.
 
But for problems with a relatively small size, those solutions may not be very time and space economical. So I think that C++ is still a good compromise between the speed and implementation efficiency taking the problem size on trading desk into consideration.

I agree, in our company, we have a c++ generator that generates financial models as C++ source codes. The coding might not have the latest OO elements, but it is compact, fast and easy to debug. In the quant finance world, the work is sometimes (not always of course) reduced to the creation and tweaking of main financial model algorithm.
 
I agree, in our company, we have a c++ generator that generates financial models as C++ source codes. The coding might not have the latest OO elements, but it is compact, fast and easy to debug. In the quant finance world, the work is sometimes (not always of course) reduced to the creation and tweaking of main financial model algorithm.

As I mentioned before you are using a legacy system that it's already established and free of bugs. Then, that system is used to generate C++ code (maybe because that was what the originals developers knew very well or for whatever other reason). Those systems are hard to remove from the pipeline. I'm sure the generated code is proven and almost free of bugs so the tweaks are minimal. Why would anybody change that system to another language? The old saying "If ain't broken, don't fix it".

The only time a new language could be introduce is when new development comes to a shop. However, if the people in that shop already know C++ (and probably they are very good at it), they will rather use that language than any new one, perpetuating C++.

I can give you a clear example of a transition. My group have a risk engine calculator that takes care of calculates risk parameters based on our groups in-house factor models. That engine was written in C++. When my boss came to the company (he is mostly a Java person), he re-wrote the whole engine in Java without penalty in performance. This is one of those rare cases that a new language gets established but for that to happen, someone needs to shake the world.
 
Of course, legacy code is a definite reason. However, does that mean without the legacy code problem, we will embrace the more recent languages (Java, C#, etc.) to implement the models? I have not yet form my own answer to this question. Can alain share some ideas on that?
IMHO, anybody that programs tend to use whatever language he/she knows + the tools at their disposal to write code. For example, the old quants in my group do all the coding in R and Perl, no C++, no Java, no C#... and their code works (it is a nightmare to maintain but it works). People embrace new languages only when they have the time and the desire to do it. Think about this, if I have problem to solve at my job, I would use whatever language I know very well instead of new one. If I'm in a C++ shop, I'm probably good at C++ so I would use C++. If I happen to know Java as well, why should use Java (maybe for job security :) ) to solve the problem if people around me know C++ very well?

I got the impression that most "new" features in the languages like Java are aiming at more effectively designing and implementing big systems. But for problems with a relatively small size, those solutions may not be very time and space economical. So I think that C++ is still a good compromise between the speed and implementation efficiency taking the problem size on trading desk into consideration.

Actually C++ was also aimed at building big systems.

Java didn't introduce anything new to world (most of its features were already present in one shape or form). Java just simplify somehow the development and make things a little more forgiven in mainstream programming. C++ doesn't forgive you. If you make a mistake, you will pay for it sooner or later (probably later). Also, Java have massive libraries for everything you can imagine.
 
Actually, we are talking about two sides of the same coin. I guess what you mean is the path-dependence leads to the widely use of C++ in quant finance and we are trying to figure out why this specific path is successful in the quant application. Obviously, no one will take efforts using assembly language to implement a system/model in finance (may in EE or something else?) or waste lots of computing resources on the unnecessary features. C/C++ is flexible and efficient in solving the target problems (time and efficiency), so when the first "quant" built the first model, he/she may probabily prefer C instead of pascal, basic, assembly language (of course) or any other language which is also taught in CS department.
 
Actually C++ was also aimed at building big systems.

Of course. As far as I can remember, most parts of UNIX are wrote in C. :)

Java didn't introduce anything new to world (most of its features were already present in one shape or form). Java just simplify somehow the development and make things a little more forgiven in mainstream programming. C++ doesn't forgive you. If you make a mistake, you will pay for it sooner or later (probably later). Also, Java have massive libraries for everything you can imagine.

That is why I added the " ".;)

However, most of these features are optional in C++ (Need extra efforts to realize) but are forced in Java. They may be frequently or seldomly used but they do cost time~
 
I got the impression that most "new" features in the languages like Java are aiming at more effectively designing and implementing big systems. But for problems with a relatively small size, those solutions may not be very time and space economical. So I think that C++ is still a good compromise between the speed and implementation efficiency taking the problem size on trading desk into consideration.

I think the additional features are not the main advantages of Java. The main advantage of Java is that it provides a virtual machine that is intended to run code on different platforms.

Back to C++, the most powerful feature of C++, in my opinion, is that it is the reflection of real world and human logic. It is not simply optimization or speed. It is at a higher level which different design patterns can be applied to. When you are applying these patterns, it makes communication easy, efficient. When we are working on large project, this feature is very important and makes project bug-free. Simply speaking, we can apply bridge pattern and decoration pattern to our option pricing engines.

I would agree that C++ is widely used partly due to the huge legacy code because reusability is the goal of the OOP and maybe C++ is first adopted by quant shop. When we already have solid infrastructure, switching is very expensive.

But one thing I feel interested in is that whether the new quant shops are using C++ ?or they are already switching to Java or C#?
 
I think the additional features are not the main advantages of Java. The main advantage of Java is that it provides a virtual machine that is intended to run code on different platforms.
This is not true. Virtual Machines have existed for ages. UCSD Pascal was one of the most famous ones. It happens that the marketing machine of Sun hyped the Java VM as if it was the best thing since slice bread. You are probably too young to know UCSD Pascal. Also, if you don't come from the CS world (or haven't study the history of Programming languages), you probably don't know about this.

Back to C++, the most powerful feature of C++, in my opinion, is that it is the reflection of real world and human logic. It is not simply optimization or speed. It is at a higher level which different design patterns can be applied to. When you are applying these patterns, it makes communication easy, efficient. When we are working on large project, this feature is very important and makes project bug-free. Simply speaking, we can apply bridge pattern and decoration pattern to our option pricing engines.

Actually C++ is just a layer above C and so far far from the real world that is not even close. C++ is not really high level if you compare it to other languages out there. Remember, the idea of design patterns came from SmallTalk (also, almost any cool feature that you can think of in C++, came from SmallTalk).

The real issue is that C was widespread. Every student in college learned C and UNIX. Hence, the jump to C++ was easier (luck working at its finest).

But one thing I feel interested in is that whether the new quant shops are using C++ ?or they are already switching to Java or C#?
As I said before, not only it's hard to switch but, if you are a C++ shop, any new development would be probably done in C++ as well. There is no real gain to switch to another language, unless we are talking about a brand new group, building everything from zero.
 
One more point, if Apple computers all of the sudden take over the quant world, you can guarantee that all the models are going to be written in Objective-C. Why? Because most of the Mac software is written in Objective-C.

I like C++. I think it is a wonderful languages but chance and luck have a lot to do with why it is so widely used in the industry.
 
Back to C++, the most powerful feature of C++, in my opinion, is that it is the reflection of real world and human logic. It is not simply optimization or speed. It is at a higher level which different design patterns can be applied to. When you are applying these patterns, it makes communication easy, efficient. When we are working on large project, this feature is very important and makes project bug-free. Simply speaking, we can apply bridge pattern and decoration pattern to our option pricing engines.

It seems that reflection of real world and human logic and design patterns are common things of all OO languages, not limited to C++. Actually, they are underlying thoughts of OOA and OOD which revolutionize the software engineering.;)
 
It is certainly true that OO came from Smalltalk, though patterns came from many places.
Recently I interviewed a CS grad who claimed that the great innovator Apple had invented GUIs, had never heard of Smalltalk, and had done O/S internals in Java :(

C++ is not an OO or pattern language. It is designed as multi-paradigm, so you can write code that looks remarkably like Fortran (complete with gotos), or sophisticated patterns and in C++0x you get lambda function and other cool stuff.

Unix/C students was certainly a factor, I know since I was one of them, but there were other factors. Pascal is and was a shit language, Basic at that time was a toy, and every cycle of performance counted.
That left the game as Fortran vs C, but the lack of a professional grade compiler at any sane price killed that idea. Microsoft were early pushes of the C changed, indeed I worked on the first Intel Unix back in the 80s as a joint project with Microsoft. Yes, really.

As a quant headhunter not only do I observe that Java is not taking market share away from C++, it is going down as a % of quant job specs, losing out not only to C++, but C# as well.
Indeed I strung together three data points which showed F# overtaking Java in quant work in 2009. I don't believe that for a second of course, but telling an employer you know Java is as likely to help your application as expertise in welding. Some even hold it against you.
But...
I don't believe C# or Java will unseat C++, not because they are better or worse but because they are too similar to offer the quantum leap in utility that justifies the hassle of changing.
C and later C++ took out Fortran and Cobol even though the lagnauges are very different.
VB took over the user interface market from HLLAPI, REXX, Vax Basic et al, again with a radical change in laguage style.
Java, HTML, and C# are taking a lot of GUI work from VB, but again the change in language is more radical.

Thus the successor to C++ is not a sibling language, but either a heavily mutated descendant further along the lines of C++0x, or more probably a leap in some other direction like Ocaml or F#. F# is interesting because it has the backing of MS.
 
C++ and Java showing marks of age

IMHO, and without willing to start another incarnation of a flame war, both C++ and Java are adequate for QF. As a Java developer, I have to mention that it's not true the myth that "Java is slow" in spite it's true that "in general, Java is slower than C++ most of the time".

As well stated in this discussion, if performance is your only and most important criteria, you should switch back to assembly, if you had already a chance to use it. And... if you had this chance... you must agree that it's a very counter productive way to produce software.

In fact, everything orbitates around performance... but mostly performance of people and not only and purely performance of applications.

Doing this change of paradigm in this discussion, I dare say that both C++ and Java are showing their marks of age. I'd like to mention C# and Scala as initiatives intended to give new breadth to C++ and Java, respectively. As a Java developer, I'm naturally biased to invest more time on Scala than anything else because it runs on top of a JVM and adds functional programming to the Java world, among several advantages.

Returning to the always present discussion about "JVM or not JVM, that's the question.", I think it pays off to know how JVM has evolved these years and know something about current improvements from other sources. A very interesting implementation is here: Azul Systems - Your Business-Critical Java™ 5X Faster. 50X Simpler

Just putting some more wood to burn in this discussion...

If you guys have a chance, please have at JQuantLib.
It's an open source project on QF intending to port QuantLib from C++ to Java.

Thanks

Richard Gomes
JQuantLib
 
I just want to make this observation about why C++ is good for quant programming.
I say it is the "4th" best.

Fastest: binary - op codes loaded into the cpu 10000011 01001100 - ( cpu specific )
Next: assembler - makes writing binary easier and produces fast compact code. ( cpu specific )
Next: C - compiles into very good assembler before being turning into bin opcodes. ( portable )
Next: C++ - compiles into C which compiles into assembler the into bin opcodes. ( portable )

For quant programming we need speed. Assembler is the best.
 
Though assembly programming, ada, Fortran are faster compared to C/C++, the main reason for using C++ is :
1. Its high level language so easy to understand and reuse the code.
2. Complex to complex programming in large projects can be easily maintained.
3. Assembly programmers will need to study the processor architecture for truly exploiting the benefit of assembly programming and multithreading , which consequently would consume huge time.
4. Lot of processors are coming, one cant spend time in learning processor architecture and then start writing the assembly for algo.
5. Difficult to pass input parameters to assembly program.
6. Compliers from big vendors are doing the job of making C++ fast, ofcourse there are certain places where C++ compiler cant apply its own optimization.
 
Muting wrote:

Dr. Duffy's answer is:
1. C++ is highly flexible an interoparable with everything on the planet.
2. Mature: supports multi-paradigm development.
3. It is an ISO standard (this means it will be around forever).

To me, the answers are quite abstract and general. It seems that this can also be the answer to "Why is C++ good? "


I would make these statements more precise as follows:

1. C++ allows developers to access the hardware by using dedicated libraries. For example, using the boost libraries means that the C++ code works on Windows and linux (the OS differences are taken care of by the boost team). Many technical and scientific libraries are in C++ (and not Java or C#).

2. For numerics, OO approach is not the most suitable paradigm. In my experience modular and template programming in more appropriate. Inheritance is just so-so.
And then for multithreading it's mostly C++ and objects are not very important as such.

3. Being a standard, no one company is the owner of C++. In this sense we shall not see OS-specific features creeping into the language. It will not be possible to pull the plug on C++ and force developers to adopt a new language.

C++ is a standard in domains like quant development, medical, telecom, science, engineering. So, knowing C++ is useful to put it mildly.

C++ is important, and it is good.

---------- Post added at 07:35 AM ---------- Previous post was at 07:27 AM ----------

Vinay wrote

2. Complex to complex programming in large projects can be easily maintained.

This is not a foregone conclusion with C++. Badly-designed C++ applications are notoriously difficult to maintain. The reasons are:

1. Too much use of deep inheritance
2. Too little up-front design (analogy: if you build a house, do you hire an architect or do you buy 30,000 bricks and 10,000 slates?)
3. For large projects, analysing your problems with small-grained objects leads to tight coupling. The preferred way is data and task decomposition which btw is the way to go in parallel programming.
 
Back
Top