29
$\begingroup$

I am currently working in a firm that does algo trading. We do all of our stuff in Java. And we do make money out of it. We have debates all the time whether we would have made more money with native or VHDL on network cards.

We don't do super high-frequency though we do more complicated trades. Even though we need to be the first. After working there for quite a while it interests me more to know if Java is popular in this area. (And since no one would talk in that field I would like to raise this issue here.)

From my experience I have noticed that it has a lot to do with the reliability of the exchange or the broker. If it is not very reliable (as in many exchanges in the world) a delay of 2 milisec would be much more significant than the language you choose. But still, how many do choose managed code?

|improve this question
$\endgroup$
16
$\begingroup$

There are tons of languages used in this field. As for Java-based trading platforms, Marketcetera is popular with customers.

To justify switching languages, you'd need to show that there is a bottleneck preventing your team from collecting more P&L. Have you run a profiler and compared the results with tcpdump? You must show that your existing platform is the cause of the delay that loses opportunities before diving into C++.

(And if we are talking milliseconds, I assume you're co-located at the exchanges in question, if they allow it. If you aren't co-lo, then dealing with that would probably have more impact than changing languages.)

|improve this answer
$\endgroup$
  • $\begingroup$ well, we tried it a lot (to justify) . we tried excelsior (en.wikipedia.org/wiki/Excelsior_JET) to improve java aot (which in java causes it to start slowly and grow faster), we tried once vhdl (but we saw that when the market doesnt have constant delays it is not significant ). but still, if someone will write the same stuff that we write - just in native, I have a feeling that he will take all the deals from us. $\endgroup$ – Bick Apr 11 '11 at 9:43
13
$\begingroup$

Oracle hosted a Trading Applications Developer Workshop in New York on March 15th, 2011. The slides from each of the presentations are here. One of them covers java for Trading Applications, and it seemed to me that the biggest issue raised by the audience was garbage collection. The presentation talks about some configuration parameters that can limit garbage collection delays, but only down to the millisecond, while most of the audience was looking for microseconds.

|improve this answer
$\endgroup$
  • $\begingroup$ I suppose with GC you could do a final check to see if GC has occurred during this trade calculation cycle, and dump the trade if so. That should filter out the (few) occasions where GC would be problematic. Also, there are a few 'real time' JVMs around, see en.wikipedia.org/wiki/Real_time_Java . Just to play devil's advocate. $\endgroup$ – Phil H Jun 14 '12 at 15:50
  • $\begingroup$ FWIW these days, anyone doing trading on the JVM will eventually be investigating Azul's Zing JVM, which features absolutely pause-less GC $\endgroup$ – experquisite Aug 11 '14 at 22:47
11
$\begingroup$

In a typical HFT scenario (process incoming UDP quotes and send TCP order entry responses) well written Java can compete with C++ for pure speed. If you need more speed, look to improve the following:

  1. Your code (setup a good benchmark and then profile and tune)
  2. Your networking environment (low-latency switches, DMA NICs)
  3. Your architecture (are you doing multi-process or multi-computer hops?)

We have written a couple of small networking benchmarks in C++ and Java, and if you use the same techniques in both, you get the same performance.

|improve this answer
$\endgroup$
  • $\begingroup$ hi, can you expand your findings to us, I find it hard to see how Java can compete with c++ in terms of speed $\endgroup$ – Nikos Dec 18 '12 at 12:40
  • $\begingroup$ @Nikos: try writing a small networking benchmark in both C++ and Java, I suspect you'll be surprised how close the performance is. For example, you could write a UDP ping-pong test. $\endgroup$ – Ted Graham Dec 19 '12 at 15:39
  • $\begingroup$ cool thx! do you have any code samples for each to get me started? $\endgroup$ – Nikos Dec 20 '12 at 12:59
9
$\begingroup$

I have these posts favorited from stackoverflow. They might help you.

High Frequency Trading

What programming language(s) is algorithmic trading software written in?

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

Jane Street Capital, a high-frequency market making firm, uses OCaml. Here are videos from the head programmer where he explains why. I thought it was quite interesting.

|improve this answer
$\endgroup$
7
$\begingroup$

I know (by word of mouth from persons directly involved, so cannot back it up with a reference) that Goldman Sachs uses Java a lot in algo trading.

|improve this answer
$\endgroup$
  • 2
    $\begingroup$ There is a guy that states (in a comment below scottlocklin.wordpress.com/2011/03/24/…) that Goldman does its CEP using OCaml. But no reference, alas. $\endgroup$ – wburzyns Apr 11 '11 at 7:20
  • $\begingroup$ @wburzyns: haha, I love the Scott's comments. On another note, Goldman Sachs used Erlang (functional programming language) for some of its high-frequency stuff in 2009. This is what I got from the Sergey Aleynikov story. $\endgroup$ – Dmitrii I. Jun 16 '11 at 14:31
  • $\begingroup$ Barclays Capital does as well $\endgroup$ – warren Aug 31 '11 at 14:54
  • $\begingroup$ Jane Street uses Ocaml, infact they're famous for using it $\endgroup$ – monksy Sep 27 '11 at 4:50
  • $\begingroup$ @monksy Jane Street doesn't do HFT. $\endgroup$ – Theodore Jan 5 at 4:57
7
$\begingroup$

I have worked with C++, java and C# implementing a google like search engine for DOD in along with many other software that require high performance (using low level memory mapping and named pipes/tcp).

In my experience, you cannot match speed of C++ with the managed code. In managed code, every call to new, garbage collection, etc. requires multiple memory look ups to allocate, de-allocate memory. With each garbage collections there are multiple threads created for each generations of the memory locations (so if you got not so savvy developers...). in addition, when you are performing a lot of thread switches or loading data in memory(e.g. in memory streams or transfers over tcp/named pipes) you will lose speed because of managed codes need for serialization (may it be wcf, remoting, web services etc.) no matter what the data transfers in .net is serialized unless you write your own tcp/named pipe wrappers. its worse if you need to use COM as your managed code will need to wrap everything up in com callable wrappers.

Lastly and most importantly, don't forget that most of the .net libraries are wrappers around the old win32 api. .net framework pump still translates your calls down to the old win32 message pump in order to perform many of its operations (e.g. DllImport("User32",...)). So does the .Net socket library (wcf, remoting, etc.) also use the underlying tcp/ip and named pipe api (e.g. see the WCF's ability to allow you to configure eitehr named pipes and tcp connection. Namedpipes are like file handle and require very low level access hence you are given a simple wrapper).

so for speed C++; for ease of development C#/Java. C# can be optimized using various tactics but requires good developers that know how to "manage" objects and GC (e.g. implement interfaces to do your own GC, call win32 api directly as needed, suppress GC, don t use classes that serialize and deserialize at least try to avoid, build your own buffer classes and crc checks for ease, use lower level sockets and not use wcf wrappers (unless its your goal to create a webservice).

|improve this answer
$\endgroup$
  • $\begingroup$ IMO you sound a little too pessimistic regarding .NET. After all, it is just a matter of utilizing 'your' language the right way. A poor written C++ app will be magnitudes slower than a well written C# app and the other way around. By following the common guidelines for writing .NET applications you will get a reasonable speed for .NET already. For peak performance, higher knowledge is needed on both platforms though. $\endgroup$ – user492238 Feb 9 '12 at 10:24
3
$\begingroup$

I have experience of C# as a strategy client at the end of a VB .Net ticker plant. The latency fluctuations caused by the garbage collection could be in the order of seconds! And occurred every four or five minutes with a stream of a 1000-ish ticks a second.

I was the first engineer to test our trading system in this way, it was a shock to all concerned and explained a lot of the issues we had had.

A much simpler Java system did a lot better, but still injected 300 ms every 10 minutes or so.

A set of managed C++ feed adapters replaced the single very busy ticker plant. The strategy client remained in C#: it manually garbage-collected whenever it had some slack time.

|improve this answer
$\endgroup$
2
$\begingroup$

Another reason for C++ is control, or at least the illusion of it.

If you really care about what exactly is going to happen and when it is going to happen then C++ is the best option. If you are prepared to put in the effort you can know and control everything all the way down to the metal.

Of course the price for more control in C++ is that you often have to control things like clearing up memory that managed code environments do not require.

A big thing in algorithmic trading these days is instrumentation and predictability, not just raw speed. Often it is not good enough to be fastest on average if the variance is too high, or if critical events are handled too slowly when the market is doing something interesting.

|improve this answer
$\endgroup$
  • 2
    $\begingroup$ Hi Dominic, welcome to quant.stackexchange! $\endgroup$ – olaker♦ Aug 18 '13 at 16:43
  • 1
    $\begingroup$ Yes, welcome to the site! $\endgroup$ – chrisaycock Aug 18 '13 at 20:36
  • 3
    $\begingroup$ C++ is fast - there's no illusion of it. We just benched mark one of our Alpha scoring C++ vs Java, C++ version just ran a lot faster. $\endgroup$ – user7228 Feb 13 '14 at 16:04
1
$\begingroup$

It is very possible to produce code in Java that:

  1. Does not create any garbage so GC never kicks in.

  2. It is JIT-friendly so the critical parts will be compiled by the hotspot.

If you do that, you can get code as fast as C++. Some of the most successful HFT hedge funds out there use Java.

For example, we have developed a FIX engine (CoralFIX) that produces zero garbage. Our benchmarks show that it is much faster than other FIX engines developed in C++.

Disclaimer: I am one of the developers of CoralFIX

|improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.