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

271–280 of 483 posts

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

#271

Post by 2OEH8eoCRo0 »

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.

Sounds like defense software. Feature A is blatantly obvious but there is no "shall" requirement for it.

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

#272

Post by mistrial9 »

lordnacho wrote: post #210
jjav wrote: post #128

Earlier quoted context omitted.

Modern C++ is probably about as good, with sufficient team discipline. I don't have enough recent experience with C++ to have a strong opinion. IMO (possibly biased by how much I hated C++ in the 90s) it is easier to maintain clean code discipline in a large team with Java than it is with C++.

C++ after 11 is a very different beast. It's more pleasant to write compared with pre-11. Memory model, move semantics, smart pointers, lots of stuff standardized instead of left to the libraries. Definitely depends on your team of course.

smart pointer template blah, instead of pointer blah, in a very large code base.. hmm not so pleasant.. the debug level function definitions, adding templated parameters, are literally unreadable. I will agree that the mental model is tamer.

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

#273

Post by AtlasBarfed »

mistrial9 wrote: post #270

from another discipline, but similar rigor -- a FOSS community with both C++ and Java servers, serving high-requirements responses.. a sort of friendly "coopetition" contest around 2012.. many hands and eyes, certainly top-level engineering on both sides. The results were basically -- with the best teams, almost identical times; the obviously slowest entries were on the C++ side. Admitting bias now, I was surprised t…

How did they avoid GC penalty? Arena allocation and buffer reuse?

Java is pretty good, I've used it for over 20 years, but it wastes memory for basic use cases, and yet GC pause limits the utilization of huge memory cases.

Did anyone try Go? IMO Go tries to address the slowness of java startup and commands, but it punts GC/memory waste so the huge-memory systems are even worse.

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

#274

Post by derefr »

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.

I think it’s not that software engineers aren’t engineers; but more that they’re most equivalent to combat engineers — engineers operating under time-pressure and shipping-pressure, where the systems they build need to “work” (in the sense of a bridge getting people across a ravine) but may only need to work once; and where it may be perfectly fine/expected/required to need to “baby” the resulting engineered system along (i.e. letting a batch of people over the bridge, then closing it to traffic, examining the piles for faults, and shoring up the ones that are slipping; then reopening the bridge, in a cycle.)

It’s not that this type of engineering is “not engineering”; it’s that it’s engineering where the engineer themselves (and their ability to actively re-stabilize the system) is considered a load-bearing element in the design, such that the system will very likely fall apart once that element is removed.

Combat engineering is still engineering, in the sense that there are still tolerances to be achieved, and it’s still a disaster if the bridge falls over while it’s in active use for the mission it was built for. It’s just not considered a problem if it falls over later, once that mission is accomplished.

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

#275

Post by MauranKilom »

acqq wrote: post #192
blackrock wrote: post #133

Earlier quoted context omitted.

Why not just write it in C? And pre-allocate all the data structures, make them global, put them into a queue, and constantly reuse them. No more need to instantiate objects.

I write C++ for now almost 30 years, and always for the workloads where the cost of allocations was plainly visible, especially in the critical parts of the applications. So I have never stopped writing "non idiomatic" C++, at least from the point of view of typical language lawyers (and C++ attracted them a lot through the years). And I'm surely not the only one: there were different environments where it was recogn…

> I don't have to follow the rules of the "language lawyers."

I'm not exactly sure what specifically you are trying to imply here. When you proclaim to ignore language lawyers, it sounds like you are knowingly breaking the rules of the C++ standard. That takes a lot of faith in compilers doing what you meant to do, despite writing code that is incompatible with the standard those compilers implement...

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

#276

Post by humanrebar »

fizixer wrote: post #216
vgatherps wrote: post #25

I’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…

You missed one comparison: C infra (no C++). (well strictly speaking, additionally you could also have hand-written assembly infra).

You can write C style code in C++ and still get access to features that are still interesting in the problem domain. constexpr functions, typesafe enums, static assertions, and destructors come to mind. No need to even touch a template or inheritance if you don't want to.

The main benefits of C per se are ABI stability and availability of compilers.

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

#277

Post by taneq »

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.

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

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

#278

Post by gpderetta »

TomSwirly wrote: post #186

Ex-Wall Street guy here. High speed trading has no societal value and relies on a large number of bad-faith bids and offers - these people are parasites. Creating liquidity has some value - though not as much as bankers tell themselves. But HFT does not add liquidity. No one needs subsecond liquidity, but even more important, HFT traders vanish like a fart in a windstorm the moment liquidity is actually challenged. M…

most electronic market makers are doing HFT these days though.

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

#279

Post by bluGill »

trhway wrote: post #76
mypalmike wrote: post #51

Earlier quoted context omitted.

When I moved from C/C++ to Java on the 90s, I was amazed how casually things like hash tables would be used. A single function might create a couple hash tables, do some data juggling and sorting, and solve a problem in like 20 lines of readable, performant code. In my experience, C coders almost invariably employ less performant algorithms and data structures due to the incidental complexity involved in memory alloc…

absolutely. Few years ago i got back deep into C++ after 18 years of mostly Java, and i'm amazed, it is like travel back in time - we (a large C++ platform) are looping over vectors instead of using hashtables/maps, copying strings all the time (we have 4 major types of strings plus some minor ones), and don't get me started on multithreading and locking/synchronization - such an easy and natural thing in Java - even…

In many cases n is small enough that looping over a vector is faster than a hash lookup. The vector loop is very ry cache friendly, while the hash lookup typically involves a cache miss or two.

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

#280

Post by bluGill »

mhh__ wrote: post #34
carlmr wrote: post #27

Earlier quoted context omitted.

This is very true. I've seen colleagues port Python to C++ and wonder why it's slower. Of course Python is slow, but it will call into efficient C routines for a lot of things that aren't just available out of the box in C++. So what does the average programmer do? They implement their own, inefficient version of this in C++. Now you've saved the overhead of copying your data from the Python to the C-world and back,…

For that reason I generally motivate not using python to people on grounds of correctness rather than performance as per se. I can't be bothered to explain how compiler optimizations work so I usually just resort to "it's magic" when it comes to performance. Going from a statically typed language to using python to do number crunching genuinely makes me want to vomit. I don't understand how people convince themselves…

Python is great for small programs that barely need any tests because you can tell it is correct by reading the code or running it until you get the right answer. when I have to maintain a large python program I agree, it is too easy to miss some error condition that doesn't work at all (anymore)
Post reply on HN