• 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 C++ and not Java??

Wallstyouth

Vice President
Joined
5/25/07
Messages
116
Points
28
I personally like Java a lot more than C++ is there a reason why there is such a heavy focus on C++ and not Java? With the slew of Classes and API for Java you would think Java would fit better in the Quant world.
 
I can mention couple of reasons. One is that most of the code that is running right now on Quant shops in Wall Street is C++ and not Java.

Another reason is that C++ is faster than Java. This is really true for applications that run native and applications that are CPU intensive (like applications that involved a lot of calculations). I know this comment can lead to a lot of "backlash" but this is true. Here is a proof The Computer Language Benchmarks Game
 
I can also mention the legacy of the code that banks use. Since C++ has been used for years before Java was created, it's really hard to change to Java. With several things that Alain mentioned above, it's very unlikely that will happen. If they ever change to another language, it probably be C# or .NET but it will takes decades. Legacy again.

That said, lot of work is done on Java. One of the students in our program currently works at Goldman and he is using Java at work.
 
Also, C++ is better for big projects, and also can talk natively to more things. This is changing of course, but getting Java to call libraries written in anything other than Java is tedious. In the quant domain, it's painful to get Java to talk to Excel, and that slows it's adoption a lot. The performance issue is twofold, yes Java is a lot slower, but also garbage collection means that efficient resource management can be very difficult. From a newbie quant perspective there is another factor, that C++ is harder than Java, so it's used to separate people who've done a little programming and those who know what's going on. Also someone who can do C++ can easily do Java, but not vice versa.
 
I'll add two more suggestions to what has already been said. For real-time applications
that need to process tick-by-tick data, Java's non-deterministic garbage collection
is a killer. For example, an algorithm missing a few ticks or a pricing model missing an
update to an underlying instrument or yield curve could result in significant losses.
Some shops have found ways to code around this and the result starts to look
a lot like C++ anyhow. There is some movement towards the Real-Time specification for Java
(https://rtsj.dev.java.net/) that (among many other things) puts some rules and/or limits
around when garbage collection can occur and the resources it can use in doing so.

Another aspect to consider are the very same hordes of libraries out there for Java.
Using such libraries has its own risks (who maintains the lib.? Will they
continue to do so? Will an update to that lib. break our application? How do we know
the performance characteristics of the lib. will endure? and so on).
So it would appear that banks would rather develop much of this code form scratch.
For example, one bank I am familiar with (who uses Java) coded all of the interfaces for
their app. from scratch rather than use Swing or any of the dozens of other interface
toolkits available.

Cheers,

Prof. H.
 
I'll add two more suggestions to what has already been said. For real-time applications
that need to process tick-by-tick data, Java's non-deterministic garbage collection
is a killer. For example, an algorithm missing a few ticks or a pricing model missing an
update to an underlying instrument or yield curve could result in significant losses.
Some shops have found ways to code around this and the result starts to look
a lot like C++ anyhow. There is some movement towards the Real-Time specification for Java
(https://rtsj.dev.java.net/) that (among many other things) puts some rules and/or limits
around when garbage collection can occur and the resources it can use in doing so.

Another aspect to consider are the very same hordes of libraries out there for Java.
Using such libraries has its own risks (who maintains the lib.? Will they
continue to do so? Will an update to that lib. break our application? How do we know
the performance characteristics of the lib. will endure? and so on).
So it would appear that banks would rather develop much of this code form scratch.
For example, one bank I am familiar with (who uses Java) coded all of the interfaces for
their app. from scratch rather than use Swing or any of the dozens of other interface
toolkits available.

Cheers,

Prof. H.

Real Time Java has been available from all the big vendors IBM, SUN, BEA for a while now so garbage collection on mission critical real-time apps is no longer a problem like it was years ago. Your comment about library maintenance, dependency and support can by applied to any language where a developer plans to use vendor or open source code. I was trying to emphasizing the fact that Java provides developers with much richer frameworks and classes in their core API from the start which helps you to get up and running very quickly compared to C++. The reuse of core API/classes tend provide better performance and cleaner code as more eyes have seen that piece of code. Anytime I write code in C++ I always get so annoyed how much work C++ forces me do :)

I fully respect C++ but Java has caught in many areas and I think if more people spoke up about Java and pushed for Java it can easily be accommodated :-)
 
I fully respect C++ but Java has caught in many areas and I think if more people spoke up about Java and pushed for Java it can easily be accommodated :-)
Also, if you just change the word Java by Linux in that sentence and you'll have another analogy ;)
There are pro/con for every piece of software and the adoption rate is not always what we can affluence.
 
The reuse of core API/classes tend provide better performance and cleaner code as more eyes have seen that piece of code.

Well, the same thing could be said about C++ (although, regarding performance, C++ is still better). I program in Java everyday and I like it a lot but, like any programming language, it has its own quirks to deal with.

There are some interesting essays written by Paul Graham about programming in general and some other topics. Check them here:

Essays

Here is what he has to say about Java,

Java's Cover
 
Well, the same thing could be said about C++ (although, regarding performance, C++ is still better). I program in Java everyday and I like it a lot but, like any programming language, it has its own quirks to deal with.

There are some interesting essays written by Paul Graham about programming in general and some other topics. Check them here:

Essays

Here is what he has to say about Java,

Java's Cover

It's quite dated (2001), but I find it interesting he says:

"10. The wrong people like it. The programmers I admire most are not, on the whole, captivated by Java. Who does like Java? Suits, who don't know one language from another, but know that they keep hearing about Java in the press; programmers at big companies, who are amazed to find that there is something even better than C++; and plug-and-chug undergrads, who are ready to like anything that might get them a job (will this be on the test?). These people's opinions change with every wind."

It doesn't seem his opinion of C++ is very high either, which I expect you knew. In fact, lest some here think I took his opinion out of context, Paul Graham is pretty known for his vocal trash talking of Java AND C++ (he loves Lisp).
 
Another aspect to consider are the very same hordes of libraries out there for Java.
Using such libraries has its own risks (who maintains the lib.? Will they
continue to do so? Will an update to that lib. break our application? How do we know
the performance characteristics of the lib. will endure? and so on).

This is a bit ridiculous. You are countering a claim as to the very rich and robust set of libraries out there for Java by mentioning there are a ton of crappy ones?

There is nothing comparable to Maven in C++ land. Nothing comparable to Spring. Hibernate. Log4j (and it's low-latency successor log4j 2). The list goes on. The fact that there are crappy alternatives doesn't change that C++ developers don't have anything nearly as good and have to rely on something crappier. (Yes I'm aware there are ports for at least Maven and log4j to C++, but they are pale imitations...)
 
Forget all those languages, use Fortran

Code:
! A fortran95 program for BS option
! By djd
!
program main
  implicit none
  integer anyKey

  real*8 S,K,T,r,v
  real*8 BlackScholes
  real*8 price

  S = 60.0
  K = 65.0
  T = 0.25
  r = 0.08
  v = 0.3

  price  = BlackScholes(S,K,T,r,v)
  write(*,*) price

  anyKey = system("pause")

end

!
real*8 Function BlackScholes(S, X, T, r, v)
      ! Put
        real*8 S,X,T,r,v

        real*8 d1, d2
        d1 = (Log(S / X) + (r + v**2. / 2.) * T) / (v * Sqrt(T))
        d2 = d1 - v * Sqrt(T)

        BlackScholes = X * Exp(-r * T) * cdf(-d2) - S * cdf(-d1)

        Return

        End

!
  real*8 Function pdf(x)

            real*8 x,A
            A = 1.0/Sqrt(2.0*3.1415)

            pdf = A * Exp(-0.5*x*x)

            return
   end

!

real*8 Function cdf(x)

            real*8 DPI,x,L,k,a1,a2,a3,tmp,pdf

            a1 = 0.4361836
            a2 = -0.1201676
            a3 = 0.9372980
            DPI = 3.1415926535897932

            L = Abs(x)
            k = 1. / (1. + 0.33267*x)

            tmp = a1*k+ a2 * k**2. + a3 * k**3.

            cdf =  1.0 - pdf(x)*tmp
            if(x.lt.0.) then

                cdf = pdf(x)*tmp

            end if

            return

        end
 
http://jonathankinlay.com/index.php/2015/02/comparison-programming-languages/

an interesting take on the apparent non necessity of using C++ at every steps of algorithm computation.
Article argues for a combination of high and low level languages which would optimize the cost of maintaining code.
basically use fast low level languages like C++ for computation intensive tasks, and use high level languages for the rest.

what do you guise think?
 
If that's the answer, then what's the question?

Question: Is C++ really faster than Java?

The main argument for C++ against Java is that C++ can deliver the lowest latencies. However that does not seem to be true if you use Java as a syntax language, in other words, if you ditch the JDK. The JDK is slow, not the Java platform/language.
 
Back
Top