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

291–300 of 483 posts

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

#291

Post by AtlasBarfed »

"If you have an unlimited amount of time and resources, the best solution for speed will be coded in FPGA"

With all that real estate on CPUs, I really would like an FPGA. If Oracle wanted to make money on Java, it could offer a commercial java that compiles bytecode to FPGA. Apple with Rosetta2 could have done an FPGA.

Emulation of lots of systems that will be abandoned by their commercial companies has always relied on the mhz and node shrink "free ride", and that's over. FPGAs could handle a lot of legitimate emulation.

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

#292

Post by MaxBarraclough »

fsflyer wrote: post #281
MaxBarraclough wrote: post #245

Earlier quoted context omitted.

The 737 Max issues were not with the software.

There seems to be plenty of software issues found: The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down. The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed. While reviewing the software systems, a number of other software issues were found. The wiring bundle…

I phrased that poorly, I should have said The 737 Max issues that caused the crashes were not with the software implementation. They were at the level of requirements and high-level design, and were not specific to the discipline of software engineering. We're not talking about a missing break statement here.

> The MCAS software was modified to read from both angle of attack sensors and to be less aggressive in pushing the nose of the plane down.

That strikes me as a design issue in the domain of aeronautical engineering, rather than in software engineering. Software engineers aren't the ones with the domain expertise to determine the right aggression parameters.

> The software that controlled the indicator light that illuminated when the two angle of attack sensors disagreed was also fixed.

I thought the issue was that the sensor-disagree warning light was not included as standard, it was sold as an optional extra. [0]

> While reviewing the software systems, a number of other software issues were found.

Interesting, I wasn't aware of that. If I understand correctly these issues aren't thought to have a direct bearing on the crashes.

[0] https://www.nytimes.com/2019/05/05/business/boeing-737-max-w...

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

#293

Post by benjaminjackman »

zozbot234 wrote: post #77
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…

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?

Well, the first place may have predated you and a rewrite is out of the question.

A few other reasons:

The rest of the platform for review and analysis doesn’t have such stringent performance requirements and it would be nice to reuse code.

There also may be some good libraries that are jvm only that your program relies on.

Packing up a fat jar can be a lot easier, less complex and more reliable than building a binary.

Your dev team has a lot Java expertise.

Getting Java to not allocate is not as hard as it seems if you set out to do it from the start. And even if not it’s not impossible because the tooling is so good. You just have to know the right tricks and it can be easier to incrementally learn those tricks for a dev team than learn C++ and it’s ecosystem.

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

#294

Post by fishermanbill »

patrec wrote: post #92
taneq wrote: post #57

Earlier quoted context omitted.

The best part about using a garbage collected language for high performance software is it's exactly the same as a non-garbage-collected language.

Sure, as long as your non-garbage-collected language from ten years ago had memory safety (and general lack of UB footguns), first class IDE support, excellent introspection and profiling facilities and a large potential hiring pool of elite programmers and wide acceptance in the industries you were trying to sell into.

Why is it you think most major programs are built using C++? Most OS's, most drivers, most browsers, most games, most major applications, most compilers, most servers etc etc.

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

#295

Post by cute_boi »

chrisseaton wrote: post #141
ridaj wrote: post #85

Earlier quoted context omitted.

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.

1000x slow so its unacceptable .

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

#296

Post by DrBazza »

gpderetta wrote: post #266
DrBazza wrote: post #213

Earlier quoted context omitted.

A few things. Java had been heavily used in finance for longer than .NET, so there's experience, and lots of existing code. Java's GC is faster (even if it's not being used in the context of HFT). But probably the most important thing is that .NET on Linux is very new (banks are very conservative, small companies, not so much). .NET on Windows for HFT is a non-starter. In comparison to Linux, you have practically zer…

If it is what I'm thinking of, I think they were hiring C++ programmers a few years ago.

They are based at the top of Savile Row.

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

#297

Post by cute_boi »

steveklabnik wrote: post #200
zozbot234 wrote: post #72

Earlier quoted context omitted.

The thing about Rust is that so many features are considered unstable and require switching to the nightly toolchain. That's just not suitable for real-world production use - yes, stuff does get stabilized eventually, but it takes time to really nail down the best possible design. Still, it's way better than the huge mess that is C++.

Which features are still holding you on nightly?

probably asm.

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

#298

Post by jcranmer »

killtimeatwork wrote: post #238
jjav wrote: post #78

Earlier quoted context omitted.

> Are there any languages that target the JVM and are designed for higher speed? Yes: Java Performant Java looks mostly like C, just with no manual malloc() calls. Sure you could write Java in a J2EE way but.. that not a good choice.

In Java, every object stored on heap (and they can't be stored on stack) has a JVM-induced space overhead. Also, the allocator is free to spread the objects across the heap in a chaotic manner, which will make for less than optimal utilization of cache lines.

That's... not how JVMs work.

All modern VMs (not just limited to Java here!) apply two key optimizations. The first is escape analysis, which checks if references to objects will escape the current function boundary. If not, the objects will be stored on the stack instead of the heap. The second is generational GC, where memory allocation looks like this:

   void *new_ptr = heap_mem;
   heap_mem += alloc_size;
   if (heap_mem >= max_size)
     outlined_function_to_get_larger_blocks_of_memory();
It's actually likely to be a tighter allocator than C/C++'s malloc, since there's no mucking about with freelists.

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

#299

Post by ampdepolymerase »

Enginerrrd wrote: post #252
levosmetalo wrote: post #228

Earlier quoted context omitted.

"I need that bridge yesterday. If my army doesn't cross the river today, we are all dead. I don't care if the bridge collapse tomorrow, or if the rain wear it down, as long as I can use it today." If it's your job to do what is requested from you, then you do it. It's not like having brittle unmaintainable code is morally wrong. It's not engineers responsibility to judge use case of the customer paying for the bridge…

>It's not engineers responsibility to judge use case of the customer paying for the bridge. Actually yes, yes it is! I am a civil engineer and there's a standard of ethics and personal responsibility among engineers that is very, very high. When we graduate, most engineers participate in a ring ceremony. They get a funny, angled ring on their right pinky. It was originally made from the metal from a bridge that fell…

Found yer old union gatekeeper. Canadian engineer?
Post reply on HN