Live data from Hacker News

Java is better than C++ for high speed trading systems

news.efinancialcareers.com

441–450 of 483 posts

Re: Java is better than C++ for high speed trading systems

#441
post #416

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.

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

#442

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.

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…

> would be delayed by less than a meter

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

#443
post #441

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

Doesn't real time just mean that you can guarantee to react within certain time limits? In principle, those time limits could be hours or days..

Re: Java is better than C++ for high speed trading systems

#444

Earlier 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?

Some Googling suggests https://blog.cloudflare.com/kernel-bypass/

Re: Java is better than C++ for high speed trading systems

#445
post #217
post #208

Earlier 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

That is not a bidirectional transform. A financial loss in an investment fund just means that other traders made more profit.

Re: Java is better than C++ for high speed trading systems

#446
post #393

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

And it’s a foolish assessment. Finding Java programmers who can navigate all the hoops of low latency Java is more difficult than finding a C programmer who can do the same with C.

Re: Java is better than C++ for high speed trading systems

#447
post #416

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.

250ms could easily be real time in the context of a given system.

Real time doesn't (necessarily) mean fast, it means the latency is bounded.

Re: Java is better than C++ for high speed trading systems

#448
post #384

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 Java is nearly as low-latency as C if you're willing to write your Java as if it were C?

Real programmers can write FORTRAN in any language.

Re: Java is better than C++ for high speed trading systems

#449

Earlier 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?

TRWTF is that Java Specification Request 1 (yes, THE very first one) targeted real-time: https://www.jcp.org/en/jsr/detail?id=1

Re: Java is better than C++ for high speed trading systems

#450

Earlier 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?

A lot of NIC manufactures provide either some hooks into something like DPDK or simple LD_PRELOADable libraries that offload the network syscalls (socket, poll, recv, etc.) into a library that talks to the NIC directly using mmap'd IO I presume.
Post reply on HN