471–480 of 483 posts
Earlier quoted context omitted.
So Java is nearly as low-latency as C if you're willing to write your Java as if it were C?
No. Java is not low-latency by any stretch. Java advocates would like to think it is, until a Bank, like BoA spends $8 million on Java in 2014, just to have it fail compliance testing. Entire project was scrapped.
Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…
> So I still prefer working low latency in C as it is more natural, native solution for managing problem where you absolutely need to control memory layouts, preallocated object pools, NUMA, compilation of decision trees to machine code, prefetcher, etc. Out of curiosity, what was the rationale for writing the system in Java? Were the tradeoffs not obvious until too late, was the choice of language dictated by higher…
Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…
One interesting approach I heard about for doing garbage collection in finance is to get computers with a shitload of RAM and just turn off GC. At the end of the trading day you can reclaim memory by killing the process. Not sure how common that strategy is.
Earlier quoted context omitted.
One interesting approach I heard about for doing garbage collection in finance is to get computers with a shitload of RAM and just turn off GC. At the end of the trading day you can reclaim memory by killing the process. Not sure how common that strategy is.
If that's your memory management strategy, then what do you actually gain by using Java? May as well just use C and never free your memory. Lots of memory management issues go away if you never free memory.
Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…
Was a specialized real-time JVM used for this? I know real time isn't necessarily low latency, but it sounds like both are desired properties in this sort of situation.
This reads like what they actually mean is "I don't think we could rewrite this in C++". That is a common sentiment. So much work went into this! We don't understand how we got here in the first place. It's so big! Look at all this legacy code and technical debt! There is no way we or anybody else could rewrite this in Java let alone C++ in any useful time frame! We sunk decades of work into this monstrosity!! The te…
Hi-speed trading is a zero-sum game, like poker. Every single gain is somebody's loss. Either you rip the other guy's heart out and eat it, or he rips your heart out and eats yours. There is no other choice. Choosing Java over C++ is choosing to be that second guy. Sure, Java coders are cheaper and easier to hire, and they produce lots more code. But if lots of code is a liability, lots of Java code is a bigger liabi…
> Java is better than C++ for high speed trading systems When someone says "C++" instead of C, you're really looking at developer issues, not technology issues. This is a one-off article trying to make some other point which seems like management hand-wringing to make sense of project failure. > Java developers are better than C++ developers for high speed trading systems I would read this, especially if it was an ac…
However, if you are a bank, which not where every developer wants to work, you have a limited budget, limited time and you have a project which isn't technically exciting (but can make a lot of money for the bank) you might find the developers you have who understand the business are more productive in Java and the resulting trading system is faster than the one they might have written in C++.
When you have some teams developing in Java and some in C++ you get to see which teams are more productive for your organisation.
in other words: we invested a ton of money into building java infrastructure and to make it work well for this application and now we need to find ultra rare developers who will maintain it! those who do java don't bother with performance or low latency and those who do C++ don't bother with java. Problem! We need to convince everyone that java is better!
Everyone using C++ for high-frequency trading hopes you will believe this article and use Java, yourself. Each person who loses money on the market loses it to someone. They are ready to be that someone, for you.