Live data from Hacker News

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

news.efinancialcareers.com

151–160 of 483 posts

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

#151
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.

I switched to C++ after years of doing web development in python, javascript and typescript, go and other high level languages associated with web dev. You're not wrong, the ego among C++ devs is astronomical. There's a huge amount of serious hate for python and this idea that being a C++ dev is superior. Get this we use Nix and C++ and the nix part of the code base is just as complex as the C++ code base. The nix st…

I'm primarily a Java programmer, but I had a go at learning Python a little while ago. I couldn't stand it - it just seemed so sloppy and poorly-defined. I don't consider myself as being superior to Python devs or having an astronomical ego, but Python-hate? Yeah.

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

#152
post #111
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.

I don't want to start a flame war, but what are some of the programming languages that attract the first variety of people?

Go is the only example I know of (very explicit syntax, almost no "magic")

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

#153
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".

I kind of cringe everytime i hear "you don't trust your programmers to get memory allocations right" but at the same time you trust them enough to not break havoc with the wallets of your customers and the frigging entire worldwide economy.

wreak havoc

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

#154

Earlier quoted context omitted.

But it’s idiotic to discuss ns-optimizations, when your infrastructure and vms add many times more that. Aws is slow. Not talking about the network.

ehh I didn't even mention AWS - all I did was using the word 'instance' which seems to have thrown you off.

What else can "instance" mean, other than an instance of a virtual server? Granted may not be on AWS, but still is virtual which is a latency killer.

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

#155

Earlier quoted context omitted.

Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…

What do you mean by ‘devirtualizer’ and why would you want that triggered? Sounds like something you wouldn’t want to trigger?

[deleted]

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

#156
post #34

Earlier quoted context omitted.

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 matric…

I’d second that. I’ve been doing a bit of algorithm/NN stuff in Nim this year since it simplifies the “deployment” phase and it’s been surprisingly handy despite the limited libraries as there’s a C library for everything. It has a few rough edges but manageable.

It has the spirit of Python 2 but written by a compiler geek (in the good sense). If I were to write an HFT it’d be tempting to use. The new default GC is reference counting but without using atomic ref counts.

P.S. thanks for the lenientops tip

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

#157

Earlier quoted context omitted.

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…

You can get all this by pinning to a core and DMA to hardware. Think of the OS like a library - if you don't call it and don't ask it to call you it stays out of the way. There's no need to throw away the OS.

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

#158

Earlier quoted context omitted.

Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…

What do you mean by ‘devirtualizer’ and why would you want that triggered? Sounds like something you wouldn’t want to trigger?

The devirtualizer (maybe this is the wrong JVM terminology, it’s basically what clang/GC call it) is part of the optimizer which sees that you have a virtual function call (like most in Java) where there is a unique caller, so you can replace the virtual call with a direct one and possibly inline it.

In the JVM I think this can only be done speculatively (you have to double check the type), but it still matters.

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

#159

Earlier quoted context omitted.

Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…

Why not just write it in C? And pre-allocate all the data structures, make them global, put them into a queue, and constantly reuse them. No more need to instantiate objects.

This is why C++ is used over Java for very fast stuff, or “just” fast stuff if you don’t want to bother fighting the JVM

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

#160

Earlier quoted context omitted.

I used to work at a market maker where they used FPGAs to beat HFTs. Of course it was a constant arms race, so I’m not sure what they would be using nowadays...

I would imagine they switched to ASICs which are more optimized than FPGAs (much smaller feature size, less general reconfigurable bloat, higher clocks, etc).

Only a few have, and even then only for a few fixed things. They have extreme versions of the inflexibility problems that fpgas have, and few exchanges have low enough jitter to justify ASICS over fpgas.

It might surprise people that relatively few hfts do latency arb (and the ones that do often have some other structural advantage), and at that the ones are more and more mixing in serious short-term alpha. In that context speed is simply becoming table stakes for playing the game, and not the one true race to win it all.

Post reply on HN