C++ or Java, which is faster for high frequency trading?

http://vanillajava.blogspot.com/2011/07/c-or-java-which-is-faster-for-high.html

by peter_lawrey • 15 years ago

7 12 15 years ago

vanillajava.blogspot.com

iskander• 15 years ago

Re: 10 microsecond latencies. I wonder what a trading algorithm could possibly do in a few thousand clock cycles that is still profitable.

kaeluka• 15 years ago

I wonder what in this blog post is more than pure and unjustified opinion.

mentat• 15 years ago

Flagged for this reason.

peter_lawrey4• 15 years ago

I would be interested if you could expand on this speculation?

Daniel_Newby• 15 years ago

Arbitrage. Buy something cheap on one exchange and sell it higher on a different exchange. The trader with the lowest latency gets a big chunk of the market just by being fast. You get even more if the algorithm has any ability at all to predict the future. The average profit per transaction will be small, but you get 10 million opportunities a day to repeat it.

peter_lawrey4• 15 years ago

Most of the 10 micro-seconds is spent receiving the UDP/TCP packet, decoding it, building an order request and sending it.

Only a fraction of this time is left to make a decision. ;)

eneveu• 15 years ago

If you are interested in using Java for high performance / low latency applications (such as financial applications), you might want to look into the Disruptor project, used by LMAX:

http://code.google.com/p/disruptor/

http://martinfowler.com/articles/lmax.html

http://www.infoq.com/presentations/LMAX

I discovered this project thanks to gaius who mentioned it here: http://news.ycombinator.com/item?id=2785195

peter_lawrey4• 15 years ago

LMAX is more high throughput than low latency. Most exchanges are about 10x slower than the trading systems which connect to them. This is because the exchange has handle all its clients, whereas the trading system can limit itself to less products and a few exchanges.

zeit_geist• 15 years ago

It's armchair HFT arguments all over.

sad• 15 years ago

Isn't GC pause good enough reason for anything of this kind? I'm perhaps not up to date in the latest JVM GC performance profiles, but if shaving even a few usec is important then I'd think avoiding it altogether is paramount.

dkersten• 15 years ago

If I were programming something like this in C++, I would preallocate as much memory as needed and reuse that in memory pools. I would do this for managing the memory (preventing memory leaks, making sure my program doesn't crash when memory runs out etc) and for performance (same sized items allocated from simple block pools, temporary "stacks" of objects which can be cleared by simply resetting the stack pointer etc). Following this logic, I don't see why I wouldn't do something similar in Java, so the garbage collector would only need to collect temporary objects as most would stay in memory and be reused. This should eliminate the bulk of unacceptible GC pauses.

Having said that, as far as I know (I haven't worked in Java in about a year and a half, so I don't know how this is now), garbage collection is pretty fast nowadays. It may also be possible to speed up if using something like Excelsior JET, though I've never used it, so may be wrong on that.

I'd personally be interested in looking at using a C++/LuaJIT hybrid for something like this though - the bulk of the code would be in Lua with common tasks that require very high performance and don't need to be too dynamic being done in C++.

peter_lawrey4• 15 years ago

I agree, avoiding GC is paramount. You can do this in Java by discarding less objects. http://vanillajava.blogspot.com/2011/06/how-to-avoid-garbage...

C++ or Java, which is faster for high frequency trading?

Related Stories