Skip to content
All library documents

Choosing Managed or Native Code for Algorithmic Trading Latency

Article Quant Q&A · Author: Bick

Summary

The discussion compares managed languages such as Java and C# with native code such as C++ for algorithmic trading. It argues that the relevant choice depends on the system’s latency needs, workload, and sources of delay. Before switching languages, teams should profile the application and measure network performance to establish whether the current implementation is actually limiting trading opportunities. Exchange or broker reliability, network equipment, co-location, and architecture can have greater effects than language choice.

The responses describe tradeoffs rather than a universal winner. Managed runtimes can introduce latency variation through garbage collection, while careful memory management and JIT-friendly code may reduce those effects. Native code offers more control, but requires more manual resource management. The anecdotes and benchmark claims are not a controlled, general comparison, and the discussion spans different systems and performance targets. Average speed alone is insufficient when predictable response times during critical market events matter.

Key ideas

  • Profile the application and measure network delays before attributing missed opportunities to language choice.
  • Co-location, exchange reliability, networking, and system architecture can dominate language-level differences.
  • Garbage collection can create latency spikes in managed runtimes, though coding and runtime choices may limit them.
  • Native code offers greater control at the cost of more manual memory management.
  • Trading systems may need predictable tail latency as well as strong average throughput.

Tags

Full text
# How good is managed code for algo trading?


# How good is managed code for algo trading?












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?

## Answer by chrisaycock (score 17)

https://quant.stackexchange.com/a/960

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.)

## Answer by bobmcn (score 13)

https://quant.stackexchange.com/a/963

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.

## Answer by Ted Graham (score 11)

https://quant.stackexchange.com/a/1296

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:

- Your code (setup a good benchmark and then profile and tune)

- Your networking environment (low-latency switches, DMA NICs)

- 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.

## Answer by Lepto Kurtič (score 9)

https://quant.stackexchange.com/a/1304

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.

## Answer by user697697 (score 8)

https://quant.stackexchange.com/a/1372

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).

## Answer by quant_dev (score 7)

https://quant.stackexchange.com/a/961

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.

## Answer by Bonaparte (score 3)

https://quant.stackexchange.com/a/14337

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.

## Answer by Dominic Connor Quant Headhunt (score 2)

https://quant.stackexchange.com/a/8789

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.

## Answer by rdalmeida (score 1)

https://quant.stackexchange.com/a/15522

It is very possible to produce code in Java that:

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

- 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

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.