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
Java is better than C++ for high speed trading systems
331–340 of 483 posts
Re: Java is better than C++ for high speed trading systems
#332Earlier 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?
Re: Java is better than C++ for high speed trading systems
#333Earlier 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?
Re: Java is better than C++ for high speed trading systems
#334Earlier 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
Re: Java is better than C++ for high speed trading systems
#335Earlier 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.
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
#336Earlier 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…
Re: Java is better than C++ for high speed trading systems
#337This 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.
Re: Java is better than C++ for high speed trading systems
#338Earlier 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?
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
#339Earlier 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?
(MISRA-C and other odd dialects excepted)
Re: Java is better than C++ for high speed trading systems
#340Earlier 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.
Consider that large chunks of Google, Twitter, Amazon, Alibaba etc run on Java.