Earlier quoted context omitted.
US Navy thinks otherwise, https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...
250ms is not real-time, nor high frequency.
Java is better than C++ for high speed trading systems
441–450 of 483 posts
Re: Java is better than C++ for high speed trading systems
#442Earlier 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.
That is exactly what I did. It was much less elegant and performant, though, than my initial solution with Common Lisp and C which basically allocated buffers in memory and mapped them with huge pages so that memory access don't ever require switch to kernel for mapping. We also had custom Intel CPUs that are auctioned individually. And cutthrough switches that stream the IP packet immediately when they receive the I…
That's just latency to your NIC, right? 1 meter ~ 3 ns ~ 9 CPU cycles at 3 GHz, less than the integer pipeline depth last I checked.
Re: Java is better than C++ for high speed trading systems
#443Earlier quoted context omitted.
250ms is not real-time, nor high frequency.
It might not be high frequency, but it certainly is real-time, unless you are implying that the agencies that give this kind of government certifications are all a bunch of fools.
Re: Java is better than C++ for high speed trading systems
#444Earlier quoted context omitted.
Common Lisp was doing all the "high level" stuff. No CL code was on the actual critical path but it still was responsible for some critical things that would be difficult otherwise. For example, I had piece of Common Lisp code optimize and compile decision trees to machine code. These were used, for example, to check whether the trade is allowed to go to market. This had to be very optimized as it was running in para…
> did not talk to operating system (Linux) after it started (no syscalls at all) and used full kernel bypass to talk to NIC That's really interesting... How does it work? How can a user space program talk to the NIC directly without using system calls? Shared memory?
Re: Java is better than C++ for high speed trading systems
#445Earlier quoted context omitted.
You shouldn't compare bridge building to developing a trading apps (on causes death, the other merely financial loss) Compare bridge building to developing software for pace maker. Now compare number of failures in both cases. You get what you pay for, if you pay for developer you'll get a developer.
You can convert between financial loss and loss of human life using implied cost of averting a fatality [1], which is about $10 million. [1] https://en.wikipedia.org/wiki/Value_of_life
Re: Java is better than C++ for high speed trading systems
#446Earlier quoted context omitted.
> 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…
Probably the usual suspect, it’s easier to find engineers that know Java than C/C++.
Re: Java is better than C++ for high speed trading systems
#447Earlier quoted context omitted.
US Navy thinks otherwise, https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...
250ms is not real-time, nor high frequency.
Real time doesn't (necessarily) mean fast, it means the latency is bounded.
Re: Java is better than C++ for high speed trading systems
#448Let 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 Java is nearly as low-latency as C if you're willing to write your Java as if it were C?
Re: Java is better than C++ for high speed trading systems
#449Earlier quoted context omitted.
Currently developing a radio communications system using Java, with JNI calls for hardware integration, running on a quad-core 32-bit ARM processor. We have constraints of around 20ms for real-time audio packet processing. Recently some stop-the-world pauses introduced by the GC resulted in calls dropping. A few GC parameter tweaks brought our latency below 20ms and the application no longer drops calls. This is usin…
> real-time, safety-critical operations Doesn't Java itself say it shouldn't be used for anything like this?
Re: Java is better than C++ for high speed trading systems
#450Earlier quoted context omitted.
Common Lisp was doing all the "high level" stuff. No CL code was on the actual critical path but it still was responsible for some critical things that would be difficult otherwise. For example, I had piece of Common Lisp code optimize and compile decision trees to machine code. These were used, for example, to check whether the trade is allowed to go to market. This had to be very optimized as it was running in para…
> did not talk to operating system (Linux) after it started (no syscalls at all) and used full kernel bypass to talk to NIC That's really interesting... How does it work? How can a user space program talk to the NIC directly without using system calls? Shared memory?