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

311–320 of 483 posts

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

#311

Post by SiebenHeaven »

SiebenHeaven wrote: post #194
Cthulhu_ wrote: post #178

Earlier quoted context omitted.

The article mentions crash logs. I can sorta relate, my company has their core application built in C (or C++? idk), and they will often have one FTE slave away for weeks analyzing a crash report / core dump, because apparently the code doesn't give nearly enough information to debug a production crash. whereas in Java you get an exception, a stack pointing neatly at where the issue was and an error that explains wha…

Fair enough, however I don't get how this ties up to "high speed trading systems". It can be said to be a general developer productivity advantage, not an advantage from technical perspective for this specific domain (which is what I thought the article was about and why I clicked the link)

On second thoughts, maybe I underestimate developer productivity?

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

#312

Post by DrBazza »

b20000 wrote: post #307
DrBazza wrote: post #187

The title of the article and the comments here are conflating several things. We had Peter Lawrey consult at one of my employers, and I've worked on both C++ and Java HFT systems. We used Chronicle as a high performance messaging system. The secret sauce is just memory mapped files, single threaded processes, and using Java objects as flyweights that just write to the end of the file, or are read from the end of the…

I was an intern in a startup years ago where they had a product that was a mix of java and C++. the company went bankrupt on that decision. there was only one engineer who understood the java/C/C++ interface at the time and that interface was responsible for all the bugs and performance problems.

Well this was the reverse of a startup - an established company that had a working system, historically in Java, and then added a mixture of C++ processes, and Java-C++ interop libraries to improve performance.

Picking two significant languages as a start up is a bold choice.

Measurement and QA is everything in terms of performance.

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

#313

Post by jandrewrogers »

aldanor wrote: post #256
95th wrote: post #230

Earlier quoted context omitted.

Well there is a middle ground - Rust

From what perspective exactly is Rust a middle ground Java and C++?

Rust improves on Java in that it doesn't have a GC, so no pauses, and the code gen is similar to C++ in terms of performance.

Rust is worse than C++ in that it struggles to express some idiomatic high-performance code architectures, such as using DMA for I/O, because they violate axioms of Rust's memory safety model, or in other cases because Rust currently lacks the language features. To make it work in Rust requires writing more code and disabling safety features.

Rust fixes many language design and performance issues with Java, while offering some similar types of safety, but (like Java) it is missing some elements of expressiveness of C++ that are important for high-performance architectures.

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

#314

Post by sakex »

scatters wrote: post #124
bboygravity wrote: post #108

Earlier quoted context omitted.

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 rele…

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

#315

Post by burnthrow »

Karellen wrote: post #193
angry_octet wrote: post #75

Earlier quoted context omitted.

The worst (messiest, laziest and most chaotic) engineer I know works at a brokerage, coding obscenely large and unreliable edifices (and in a number of languages, from C++ to Excel+VB)... He does what he is asked, and doesn't worry about telling them what they need. They never demand code that doesn't crash, they see that as a fact of life, and developers are an overhead. Basically someone else owns the risk, the bro…

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

Nice flamebait.

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

#316

Post by ska »

simonh wrote: post #110
dehrmann wrote: post #67

Earlier quoted context omitted.

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.

As I understand it (before my time), this was a practical solution found on original symbolics lisp machines; trigger the GC and go get lunch...

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

#317

Post by ku-man »

ampdepolymerase wrote: post #299
Enginerrrd wrote: post #252

Earlier quoted context omitted.

>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?

It's not about gatekeeping, it's about responsibility.

Would be you okay if the acupuncturists called themselves doctors?

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

#318

Post by DrBazza »

vips7L wrote: post #259
DrBazza wrote: post #183

Earlier quoted context omitted.

From job ads I saw a year ago, there's at least one company in London doing HFT Rust. Also, if memory serves, one of Lawrey's ex-colleagues has written his own version of Chronicle in D that's being used somewhere too.

D seems like it would be a great choice for HFT. You get the productivity of GC when you want it and then you can have @nogc for critical sections of your code base.

I think that's exactly what they did. The video is up on youtube from DConf 2017/8 IIRC.

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

#319

Post by burnthrow »

b0rsuk wrote: post #113
z92 wrote: post #5

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

Are you using meme language? If yes, be aware it makes your point harder to understand. I'm wondering if you've made a grammatical error, are not good at English, or something else.

Imagine comment on hacker news ngl

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

#320

Post by Supermancho »

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

When someone says "C++" instead of C, you're really looking at developer issues, not technology issues. This is a one-off article trying to make some other point which seems like management hand-wringing to make sense of project failure.

> Java developers are better than C++ developers for high speed trading systems

I would read this, especially if it was an actual study.

Post reply on HN