How good is managed code for algo trading?

External question — Quantitative Finance Stack Exchange Author: Bick Original post: https://quant.stackexchange.com/questions/959 License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I am currently working in a firm that does algo trading. We do all of our stuff in Java. And we do make money out of it. We have debates all the time whether we would have made more money with native or VHDL on network cards. We don't do super high-frequency though we do more complicated trades. Even though we need to be the first. After working there for quite a while it interests me more to know if Java is popular in this area. (And since no one would talk in that field I would like to raise this issue here.) From my experience I have noticed that it has a lot to do with the reliability of the exchange or the broker. If it is not very reliable (as in many exchanges in the world) a delay of 2 milisec would be much more significant than the language you choose. But still, how many do choose managed code?

External answer — Quantitative Finance Stack Exchange Author: Dominic Connor Quant Headhunt Original post: https://quant.stackexchange.com/a/8789 License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Another reason for C++ is control, or at least the illusion of it. If you really care about what exactly is going to happen and when it is going to happen then C++ is the best option. If you are prepared to put in the effort you can know and control everything all the way down to the metal. Of course the price for more control in C++ is that you often have to control things like clearing up memory that managed code environments do not require. A big thing in algorithmic trading these days is instrumentation and predictability, not just raw speed. Often it is not good enough to be fastest on average if the variance is too high, or if critical events are handled too slowly when the market is doing something interesting.

External answer — Quantitative Finance Stack Exchange Author: Bonaparte Original post: https://quant.stackexchange.com/a/14337 License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/ Adaptation: HTML converted to plain text; contact email addresses removed. I have experience of C# as a strategy client at the end of a VB .Net ticker plant. The latency fluctuations caused by the garbage collection could be in the order of seconds! And occurred every four or five minutes with a stream of a 1000-ish ticks a second. I was the first engineer to test our trading system in this way, it was a shock to all concerned and explained a lot of the issues we had had. A much simpler Java system did a lot better, but still injected 300 ms every 10 minutes or so. A set of managed C++ feed adapters replaced the single very busy ticker plant. The strategy client remained in C#: it manually garbage-collected whenever it had some slack time.

External answer — Quantitative Finance Stack Exchange Author: rdalmeida Original post: https://quant.stackexchange.com/a/15522 License: CC BY-SA 3.0 — https://creativecommons.org/licenses/by-sa/3.0/ Adaptation: HTML converted to plain text; contact email addresses removed. It is very possible to produce code in Java that: Does not create any garbage so GC never kicks in. It is JIT-friendly so the critical parts will be compiled by the hotspot. If you do that, you can get code as fast as C++. Some of the most successful HFT hedge funds out there use Java. For example, we have developed a FIX engine ( CoralFIX ) that produces zero garbage. Our benchmarks show that it is much faster than other FIX engines developed in C++. Disclaimer: I am one of the developers of CoralFIX