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

451–460 of 483 posts

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

#451

Post by mypalmike »

dan-robertson wrote: post #413
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…

I feel like often the opposite can be true as well. Obviously hashtables are better for large collections but often collections are very small (sizes typically follow a power law; most strings will be smaller than the pointer to their first character; most collections will only have a few elements) and arrays can win here due to less indirection and better locality. Compare this to many functional languages (or lisps…

Yeah I agree with this (apart from the lisp commentary, which I have no insight into).

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

#452

Post by pjmlp »

eru wrote: post #443
pjmlp wrote: post #441

Earlier quoted context omitted.

It might not be high frequency, but it certainly is real-time, unless you are implying that the agencies that give this kind of government certifications are all a bunch of fools.

Doesn't real time just mean that you can guarantee to react within certain time limits? In principle, those time limits could be hours or days..

Yes, but those limits are part of certification processes like those done by companies like https://www.highintegritysystems.com.

Usually playing with numbers in these kind of deployments isn't part of the package.

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

#453

Post by knuthsat »

iamcreasy wrote: post #432
knuthsat wrote: post #422

Earlier quoted context omitted.

Let's say you write an Iterable class so that you can use foreach on your data structure. It's quite possible iteration won't be completely inlined and the overhead of calling hasNext & next can become non-significant. An even worse case that made massive speedups is just inlining everything. I believe modern IDEs can automatically inline all invocations of a function. You'd be surprised how much performance you can…

But you still have to make the next and hasNext calls in a for loop. What guarantees that they would be inline in a for loop?

I inline them manually.

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

#454

Post by [deleted] »

matheusmoreira wrote: post #437
lmilcin wrote: post #363

Earlier quoted context omitted.

Common Lisp was doing all the "high level" stuff. No CL code was on the actual critical path but it still was responsible for some critical things that would be difficult otherwise. For example, I had piece of Common Lisp code optimize and compile decision trees to machine code. These were used, for example, to check whether the trade is allowed to go to market. This had to be very optimized as it was running in para…

> did not talk to operating system (Linux) after it started (no syscalls at all) and used full kernel bypass to talk to NIC That's really interesting... How does it work? How can a user space program talk to the NIC directly without using system calls? Shared memory?

[deleted]

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

#455

Post by lmilcin »

iphorde wrote: post #440
pjmlp wrote: post #416

Earlier quoted context omitted.

US Navy thinks otherwise, https://www.ptc.com/en/blogs/plm/ptc-perc-virtual-machine-te...

250ms is not real-time, nor high frequency.

Please, get informed on what real-time is before you comment (in general it is good idea to understand a concept before you place confident comments like yours).

https://en.wikipedia.org/wiki/Real-time_computing

Real-time has nothing to do with performance and everything to do with predictability and deadlines.

People are put off when they find out that real time versions of Java or Linux are actually slower than the regular ones. Until you think about it a little bit and if they were faster there would not be multiple versions.

Real-time versions of products are created because sometimes performance is achieved by means of stochastic processes or amortizing costs and you need to remove these optimizations to be able to support deadlines.

Real-time programming emphasizes ability to calculate how long an operation will take as more valuable than raw performance.

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

#456

Post by chrisseaton »

opportune wrote: post #361
chrisseaton wrote: post #139

Earlier quoted context omitted.

Why not just write it in assembly while you’re at it? The answer to both questions is that many people prefer writing in higher-level languages with more safety guarantees.

They mention not even using most of the Java features (exceptions, built in GC) that make it safe. So I think it's a pretty fair question, since they are essentially using a very stripped down version of the language that removes most of the compelling reasons to use it, and seemingly fighting the language runtime along the way.

The reason these people still use Java is that everything else can be nice high-level Java code.

So they use regular Java for the build system, deployment, testing, logging, loading configuration, debugging, etc etc. There's a small core written in this strange way... but everything else is easier. And things like your profiler and debugger still work on the core as well.

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

#457

Post by rramadass »

knuthsat wrote: post #182
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…

From my experience, JVM can't do much when there's a deep stack. I remember just refactoring all of foreach-loops/iterators into for-loops and got insane speedups. Functions with inefficient iterations would get optimized if called directly but deep in the call stack and nothing happens. These kinds of things are impossible with C++. It's possible to write efficient Java but you have to not use some of the language f…

>These kinds of things are impossible with C++

What? Anything you can do in C, you can do in C++ at the same performance level (pay only for what you use); just be aware of what you are doing and using.

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

#458

Post by bitcharmer »

bluGill wrote: post #283
bitcharmer wrote: post #83

Earlier quoted context omitted.

As an HFT developer myself I have to disagree. I worked for tier 1 banks that used both:java and cpp. The trend is moving towards quicker time to market and simpler implementations and replacing cpp with java. The cpp code bases I had to deal with were old, hard to maintain and easy to break. More often than not cpp was a pretty bad lock in as well. For example a big evil bank very well known here struggled for 3 yea…

How is replacing with Java better than replacing with C++? Legacy code is a problem, and bad programmers will write bad code in any language. If you need to start over does Java give you anything you can't get with modern C++?

From my personal experience I'd say java is much more forgiving than c/cpp and things like debugging or dependency management make it a tempting option in a time-constrained environment.

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

#459

Post by rramadass »

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…

Yep. I always say start with the "better C" part of C++ to get stronger type checking and then add in other features only as needed. All abstractions should be with minimal overhead with a strict pay only what you need policy.

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

#460

Post by rramadass »

scatters wrote: post #338
sakex wrote: post #314

Earlier quoted context omitted.

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

Thank you for that writeup. Can you please list some resources (links/articles/books etc.) for us to read up on the above?
Post reply on HN