Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.efinancialcareers.com

Post reply on HN
Print view View original

141–150 of 483 posts

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

#141

Post by chrisseaton »

ridaj wrote: post #85
logicchains wrote: post #56

Earlier quoted context omitted.

>A few GC parameter tweaks brought our latency below 20ms and the application no longer drops calls. Tick to trade latency for a modern software HFT stack needs to be under 10 _microseconds_, which is over three orders of magnitude more stringent.

10ms is target at which percentile for HFT? From what I could tell in my limited experience, GC impact is worse at the tail of latency distribution

> 10ms is target at which percentile for HFT?

They already just said they need 10 microseconds. 10 milliseconds is far far too slow.

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

#142

Post by tester34 »

hawk_ wrote: post #116
littlecranky67 wrote: post #106

Earlier quoted context omitted.

.NET 5 was released Nov 10th: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/

Released doesn't mean it's production ready :-)

They do test it on their software

bing.com/version

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

#143

Post by beagle3 »

mhh__ wrote: post #34
carlmr wrote: post #27

Earlier quoted context omitted.

This is very true. I've seen colleagues port Python to C++ and wonder why it's slower. Of course Python is slow, but it will call into efficient C routines for a lot of things that aren't just available out of the box in C++. So what does the average programmer do? They implement their own, inefficient version of this in C++. Now you've saved the overhead of copying your data from the Python to the C-world and back,…

For that reason I generally motivate not using python to people on grounds of correctness rather than performance as per se. I can't be bothered to explain how compiler optimizations work so I usually just resort to "it's magic" when it comes to performance. Going from a statically typed language to using python to do number crunching genuinely makes me want to vomit. I don't understand how people convince themselves…

Take a look at Nim if you haven't already -

It has a Pythonesque syntax, but strong static typing with extensive user control of semantics you seem to care about; e.g. floats and ints do not convert automatically unless you explicitly "import lenientops"[0] ; You can define 'operational transform' optimizations (such as: c b converts to multiply_accumulate(c,a,b) - which is a big performance difference for e.g matrices) that will be applied by the compiler so that your code shows what you mean (c=c+ab), and yet the compiler gets to compile the efficient version (using the relevant BLAS routine)

It's young, but has the best FFI for C,C++,Objective-C or JS you'll find anywhere on one hand, and already a good deal of native implementations, including e.g. a pure Nim BLAS that is comparable to within 5-10% with the best out there (including those with carefully hand optimized ASM kernels).

[0] https://nim-lang.org/docs/lenientops.html

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

#144

Post by tester34 »

H8crilA wrote: post #3

This is not "why Java is better for fast things". It is not. This is "why Java is better", and the answer is "it usually is better because your programmers often suck".

Aren't HFT programmers highest paid?

If they do suck, then almost everybody in the whole industry sucks

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

#145

Post by beagle3 »

z92 wrote: post #5

When you write Java in a C like syntax : "Chronicle's system is built in what Lawrey describes as "C-like Java" and it's this that he encourages people to code low latency systems in." I guess very limited number of constructors, and most of all the methods are static. And they still struggle to find programmers that can code that way.

> When you write Java in a C like syntax

And C is faster still when you write it with Fortran like (column order, and "restrict" mostly) semantics.

An old mentor said to me 30 years ago that "A good programmer writes FORTRAN no matter what language they are using" (he was referring to speed of execution in the context of "good"). It seemed super funny at the time, but there's a lot of truth in that.

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

#146

Post by RhysU »

blub wrote: post #74
jjav wrote: post #66

Earlier quoted context omitted.

You should not have any full GC (pause) events, ever, in properly written production Java code. Source: I worked on several extremely high performance Java systems at Sun and also worked optimizing various Java servers at subsequent jobs based on my Sun experience. At one company (after Sun) I took on a backend service which was doing GC pauses every 3-5 minutes, the code was a dumpster fire mess. After cleaning thin…

Extremely high performance properly written Java code has been mentioned so many times in Java performance discussions that it has acquired an almost legendary status, right there with the sufficiently smart compiler.

I have observed the former, written by exceptional coworkers, but never the latter.

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

#148

Post by jdrek1 »

asddubs wrote: post #86
bra-ket wrote: post #61

C++ is a fantastic language but it somehow attracts people with big ego. The smartest people I know would always try to simplify things, but many C++ developers (especially in financial industry) have this preference for complexity I can't explain. And C++ is the worst language to get clever with.

it's not hard to see why C++ would attract people who revel in complexity, there's like 7 ways to initialize a variable, and they're all slightly different in certain contexts

http://mikelui.io/img/c++_init_forest.gif

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

#149

Post by bboygravity »

chrisseaton wrote: post #140
bboygravity wrote: post #108

Earlier quoted context omitted.

Am I understanding correctly that those firms really really care about latency & have unlimited money & chose C++/JAVA with a standard off-the-shelve compiler + an OS and/or JVM?? If you'd really really care about latency and have the resources, wouldn't it be more effective to just go bare metal? Bare metal as in: no OS (talk to the hardware registers directly from code), possibly a custom compiler, use all the rele…

I don’t know what you think the practical benefit of running with no OS is?

More processing capacity for your application (no need to share with OS), no more interruptions by the OS that are unpredictable in duration, no more interruptions by the OS that are unpredictable in terms of timing and priority and above all, since this seems to be the main goal of the software we're talking about: lower overall latency. Standard C++/JAVA (as far as I know) talks to hardware through a software layer (the OS's system calls). This takes time. Time you can save by cutting out the middle man.

There are apparently ways to do this with an OS running in parallel as well though when you have multiple cores available apparently (see another comment to this thread).

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

#150

Post by bboygravity »

scatters wrote: post #124
bboygravity wrote: post #108

Earlier quoted context omitted.

Am I understanding correctly that those firms really really care about latency & have unlimited money & chose C++/JAVA with a standard off-the-shelve compiler + an OS and/or JVM?? If you'd really really care about latency and have the resources, wouldn't it be more effective to just go bare metal? Bare metal as in: no OS (talk to the hardware registers directly from code), possibly a custom compiler, use all the rele…

I don't know about java, but when using c++ you can use the OS to start the program, set up the hardware mappings and then move it to an isolated core where you talk to the hardware directly without ever issuing a system call. Compilers already offer flags to optimize for specific processor generations (and use the newly available instructions); you aren't going to be able to do better than that with a custom compile…

Oh, that's cool. However, you'd still be sharing at least 1 core (and all peripheral hardware and memory access in the system) with the OS. A core, other hardware and memory that you could otherwise access directly from your application without having to wait for the OS to finish its business?

I'm not sure whether it's worth it to go through this trouble (writing for bare metal vs just using an off-the-shelve OS) in a real life trading-app scenario. Hence my wonder :)

Post reply on HN