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.
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:
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.
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++.
14 comments
[ 2.9 ms ] story [ 47.9 ms ] threadOnly a fraction of this time is left to make a decision. ;)
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
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++.