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

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.

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

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

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

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.

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