Live data from Hacker News

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

news.efinancialcareers.com

331–340 of 483 posts

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

#331

Earlier quoted context omitted.

^^This^^ is why you shouldn't call software developers "engineers" (disclaimer, am software developer). "No-one ever explicitly specified that the bridge shouldn't fall down and kill everyone who was on it at the time", said no engineer, ever.

If software developers aren't engineers, why are we judging this person's engineering? I think this case is an argument that software developers are engineers, even when their employer fails to see it that way

Because this person is not doing engineering, this person is writing code.

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

#332
post #314

Earlier quoted context omitted.

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…

I've never seen that, how do you do it? Also, how do you deal with VM and scheduling?

Brief intro, should bootstrap your knowledge: https://codywu2010.wordpress.com/2015/09/27/isolcpus-numactl...

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

#333
post #277
post #92

Earlier quoted context omitted.

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.

Wait, are we still comparing C++ with Java here?

Yes? If you write zero or low allocation code in Java you pay a price for working against the language and you also lack several tools for writing fast code that C++ provides you with (as well as a bunch of useful abstractions), but your development experience will obviously be much better on a number of other dimensions.

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

#334

Earlier quoted context omitted.

Ah right yes conflict of terminology. In the JVM devirtualising means making a virtual object a full object again, so the opposite of what you want to be happening. I don't think the JVM really names the optimisation you're talking about, but it does do it, through either a global assumption based on the class hierarchy, or an inline cache with a local guard.

the jvm names the optimization exactly like he said

IIRC it calls it monomorphisation.

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

#335

Earlier 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.

There are open source 'pauseless' (really: ultra low pause) GCs for the JVM now. Azul made good money selling such a thing to the finance industry for a long time.

Typical pauses may be far less than a millisecond in these GCs because they do almost everything in parallel.

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

#336

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…

Is this the same in Europe? I doubt it and at least in Germany an engineer (even a software engineer) is someone who has studied a technical subject at university. It has nothing to do with liability here.

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

#337
post #10
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".

If programmers didn't suck, we would do everything in ASM. Since programmers are humans, we need abstractions like C or C++. Java, C#, Python, Go, Objecttive-C, and other garbage collected languages are there to make programming easier.

Using assembler would be likely slower, when intrinsics are available.

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

#338
post #314

Earlier quoted context omitted.

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…

I've never seen that, how do you do it? Also, how do you deal with VM and scheduling?

Isolating a core: isolcpus and taskset, or possibly cgroups, plus nohz and there's a patch set that offers even stronger isolation guarantees (keeping kernel threads off the core). Hardware mappings are done as a ring buffer in memory mapped to the device; a kernel module helps set up that mapping but once it's in place reads and writes to those virtual addresses go directly (well - via MMU and memory bus) to the hardware. The general term for this is user-space networking (although obviously you can do it with other hardware as well). Some addresses may be mapped to device registers that trigger hardware actions on read/write.

VM - the key is to get everything mapped in at the start and avoid page faults subsequently. madvise can help with this and obviously you need to avoid memory leaks that could result in sbrk - but in any case allocating at all in the trading thread is generally unnecessary (after startup) and frowned on. This does mean that the (lock-free) queue back to the shared core needs to recycle memory and both sides need to service it regularly or you need a strategy to deal with exhaustion. Scheduling isn't an issue - you have a single thread per core and (with isolcpus) the kernel scheduler knows to avoid placing other threads on it.

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

#339

Earlier quoted context omitted.

Currently developing a radio communications system using Java, with JNI calls for hardware integration, running on a quad-core 32-bit ARM processor. We have constraints of around 20ms for real-time audio packet processing. Recently some stop-the-world pauses introduced by the GC resulted in calls dropping. A few GC parameter tweaks brought our latency below 20ms and the application no longer drops calls. This is usin…

> real-time, safety-critical operations Doesn't Java itself say it shouldn't be used for anything like this?

Most software does. But, let's face it, it's not like C or C++ compilers should come with a manual saying "We strongly recommend using C for safety critical systems".

(MISRA-C and other odd dialects excepted)

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

#340
post #92

Earlier quoted context omitted.

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.

Most servers, definitely not.

Consider that large chunks of Google, Twitter, Amazon, Alibaba etc run on Java.

Post reply on HN