Surely Rust will be better than both of these.
Java is better than C++ for high speed trading systems
101–110 of 483 posts
Re: Java is better than C++ for high speed trading systems
#102Earlier quoted context omitted.
Which one of these firms made the most money?
The third one was definitely the least, it was losing money (and specifically to trader-invisible things that never got worked on). The whole of the trading strategy (and capital traded, return profiles, etc) between the first two was fairly different, so it’s hard to compare. I would say though that the first firm was significantly outperforming its peers in a way the second firm did not, although both were very suc…
It's generally pretty rare for a market maker to lose money over a whole year. Colour me surprised.
Re: Java is better than C++ for high speed trading systems
#103Re: Java is better than C++ for high speed trading systems
#104As an HFT programmer I like this article because it means less competition for me. I mean, you can write a very fast system in Java but by the time you accomplish that goal you’ll have spent as much or more time than if you had just used C++.
The question is how much of your remaining tick-to-trade is really in the software loop. Realistically at the bleeding edge more and more logic is going into FPGA (and maybe ASIC t some extent). Your software is primarily there to make sure that you've processed the previous tick and re-configured the FPGA rather than actually competing in tick to trade. Given that's the case the software doesn't need to be the fastest, it just needs to be fast enough.
Meanwhile if your logic isn't going into FPGA you may well just not be super competitive anyway and therefore the priority is time to market.
Re: Java is better than C++ for high speed trading systems
#105When 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.
Use the stack and not the heap. Pre-allocate arrays, avoid collections. Use LUTs. Avoid string processing, operate on bits and bytes as much as possible. Same applies to telecoms-development that has to be fast and predictable.
>Same applies to telecoms-development that has to be fast and predictable.
Funny enough, I've always thought of it more of writing Java like Erlang than C.
Re: Java is better than C++ for high speed trading systems
#106Earlier quoted context omitted.
.net core is old now as if this last month. Now it’s just .Net 5, which is faster still.
Did I miss the announcement? But AFAIK .NET 5 isn't production ready yet.
.NET 5 was released Nov 10th: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
Re: Java is better than C++ for high speed trading systems
#107Hearing them describe this "C-like Java", I'm surprised C# wasn't a better fit given that it has value-type "structs" that don't have to sit behind a reference on the heap. As far as I know, Java still doesn't have an equivalent feature. Maybe the JVM's GC is just so much faster that it's worth it?
And put your HFTS at the mercy of windows updates?
Joking aside, C# has only become a solid contender after the fairly recent performance improvements and better Linux support. I could be wrong but I doubt a lot of these systems are built on Windows.
Re: Java is better than C++ for high speed trading systems
#108I’ve seen this sentiment before and worked on both a “low latency Java” team and low latency C++ teams. I have some sympathy for the idea that the JVM is better since it means you won’t spend all your time chasing crash reports. The thing is, like another comment hinted at, is that this issue is generally more reflective of the environment you build in than the technology choice. Here’s a good talk on the reasons for…
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 relevant instructions that your CPU offers you. Or at the very least mess with the compiler to optimize it more to the specific make/model of the CPU/hardware that it will run on?
What are the considerations in those companies for or against this?
Re: Java is better than C++ for high speed trading systems
#109Earlier quoted context omitted.
Maybe, but that just raises the question...If you're coding your system under the constraint that you should not be having any GC-event, what's the point of picking a GC language in the first place?
As others said, no full GC events. Young generation GC is cheap, no need to avoid that. Productivity is the point. Even while paying attention to GC, it's much faster to write good code in Java than to worry about every malloc() in C. I love C, but if I need to churn out high performance code quickly, Java is the choice.
But here we're talking about C++: you don't write malloc, you use containers that encapsulate memory management - likely std::containers with pool allocators. And you put things on the stack. Code is as readable if not more than java - there isn't any "new," anywhere in sight
Re: Java is better than C++ for high speed trading systems
#110Earlier quoted context omitted.
I thought the actual approach taken these days is to disable GC for any JVM based trading systems and use arena based architectures or similar for application where you need super low latency, like a LOB mirror or execution engine, no?
I've heard of people doing that 10-15 years ago. I'm sure it still works, but hopefully the GC situation has also improved.
A pause is still a pause though. One system I know of had a solution. Throw in a huge amount of RAM on the server and delay garbage collection until end of day.