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…
Java is better than C++ for high speed trading systems
151–160 of 483 posts
Re: Java is better than C++ for high speed trading systems
#152C++ 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?
Re: Java is better than C++ for high speed trading systems
#153This 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.
Re: Java is better than C++ for high speed trading systems
#154Earlier 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.
Re: Java is better than C++ for high speed trading systems
#155Earlier 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?
Re: Java is better than C++ for high speed trading systems
#156Earlier 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…
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
#157Earlier 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…
Re: Java is better than C++ for high speed trading systems
#158Earlier 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?
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
#159Earlier 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.
Re: Java is better than C++ for high speed trading systems
#160Earlier 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).
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.