C++ or Java, which is faster for high frequency trading?(vanillajava.blogspot.com)
vanillajava.blogspot.com
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
14 comments
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.
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.
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...
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++.
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++.
Re: 10 microsecond latencies. I wonder what a trading algorithm could possibly do in a few thousand clock cycles that is still profitable.
I wonder what in this blog post is more than pure and unjustified opinion.
I would be interested if you could expand on this speculation?
Flagged for this reason.
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. ;)
Only a fraction of this time is left to make a decision. ;)
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.
[deleted]
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