

C++ or Java, which is faster for high frequency trading? - peter_lawrey
http://vanillajava.blogspot.com/2011/07/c-or-java-which-is-faster-for-high.html

======
eneveu
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_lawrey
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.

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

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

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

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

------
zeit_geist
It's armchair HFT arguments all over.

