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

391–400 of 483 posts

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

#391

Post by jacques_chester »

DrBazza wrote: post #213
brundolf wrote: post #38

Hearing them describe this "C-like Java", I'm surprised C# wasn't a better fit given that it has value-type "structs" that don't have to sit behind a reference on the heap. As far as I know, Java still doesn't have an equivalent feature. Maybe the JVM's GC is just so much faster that it's worth it?

A few things. Java had been heavily used in finance for longer than .NET, so there's experience, and lots of existing code. Java's GC is faster (even if it's not being used in the context of HFT). But probably the most important thing is that .NET on Linux is very new (banks are very conservative, small companies, not so much). .NET on Windows for HFT is a non-starter. In comparison to Linux, you have practically zer…

> But probably the most important thing is that .NET on Linux is very new (banks are very conservative, small companies, not so much).

They are. However I'd say, based on what I saw at Pivotal, that .NET Core is sweeping all before it. It's faster, less crufty and so on. But the real win is that (1) most of it is familiar to folks with previous .NET experience, but (2) your ops teams can get out of running two very different platforms in Windows and Linux.

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

#393

Post by saghm »

lmilcin wrote: post #357

Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…

> So I still prefer working low latency in C as it is more natural, native solution for managing problem where you absolutely need to control memory layouts, preallocated object pools, NUMA, compilation of decision trees to machine code, prefetcher, etc.

Out of curiosity, what was the rationale for writing the system in Java? Were the tradeoffs not obvious until too late, was the choice of language dictated by higher-ups, etc.?

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

#394

Post by lostcolony »

'The problem with C++ is its fallibility, says Lawrey: "If you're not a really good C++ developer, you can shoot yourself in the foot and bring an entire project down."'

'The only problem with low latency Java is that most experience(sic) Java programmers struggle with the new paradigm.'

So...badly written C++ isn't reliable, and well written, idiomatic Java isn't performant...so the solution proposed is, rather than make sure you write your code well in C++, to instead write your code well AND non-idiomatically in Java? Seems an...interesting take.

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

#395

Post by kortex »

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…

It made more sense before the time of IDEs and code completion. I used to greatly prefer python to c++ or java when I actually had to type full names and look up interfaces like a pleb.

Now I can't stand untyped python. Have to actually look at documentation to see what methods a class has, who has time for that?

Writing golang with tabnine is otherworldly. It's so regular, not just the syntax, but the variable naming conventions, and course structure even, that it feels like loosely nudging the autocomplete in the direction of the goal.

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

#396

Post by dan-robertson »

opportune wrote: post #364
arthurcolle wrote: post #60

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?

What is an arena based architecture? A quick google didn't show any results. My assumption is that you mean pre-allocating all the memory you want to use at once, but I'm not sure and I'm curious.

Basically yeah. You allocate out of pools or arenas. In a language like C this usually means using a block of memory for objects that can all be freed together, so instead of calling malloc and free for each little object in your critical path (eg from request to response on some server, or a frame in a videogame), you somehow determine a maximum size, allocate that (and write enough bytes to have the OS actually give you the memory), and then allocations are just bumping a pointer into this block. At the end of the request, free the block (or return it to a pool to be used later).

Sometimes an arena may instead refer to a region of memory for allocations that are all the same size/type. Because everything is the same size, the data structures for tracking allocations may be simpler.

In a language like Java, you basically preallocate an array of objects of the same type with a bunch of fields set to zero, and then have some data structure to give you a fast interface a bit like malloc. Because you don’t do any extra allocation, the GC can be safely turned off.

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

#397

Post by stingraycharles »

saghm wrote: post #393
lmilcin wrote: post #357

Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…

> So I still prefer working low latency in C as it is more natural, native solution for managing problem where you absolutely need to control memory layouts, preallocated object pools, NUMA, compilation of decision trees to machine code, prefetcher, etc. Out of curiosity, what was the rationale for writing the system in Java? Were the tradeoffs not obvious until too late, was the choice of language dictated by higher…

Probably the usual suspect, it’s easier to find engineers that know Java than C/C++.

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

#398

Post by lmilcin »

saghm wrote: post #393
lmilcin wrote: post #357

Let me put my perspective on this. As it happens, I have developed one algorithmic, low latency trading system in Common Lisp / ANSI C, and then was asked to rewrite it in Java which I did. It actually traded on Warsaw Stock Exchange and was certified by WSE and was connected directly to it (no intervening software). Yes, it is possible to do really low latency in Java. My experience is my optimized Java code is abou…

> So I still prefer working low latency in C as it is more natural, native solution for managing problem where you absolutely need to control memory layouts, preallocated object pools, NUMA, compilation of decision trees to machine code, prefetcher, etc. Out of curiosity, what was the rationale for writing the system in Java? Were the tradeoffs not obvious until too late, was the choice of language dictated by higher…

The rationale was there were no developers available with skills to work on a complex Common Lisp application.

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

#399

Post by xabush »

lostcolony wrote: post #394

'The problem with C++ is its fallibility, says Lawrey: "If you're not a really good C++ developer, you can shoot yourself in the foot and bring an entire project down."' 'The only problem with low latency Java is that most experience(sic) Java programmers struggle with the new paradigm.' So...badly written C++ isn't reliable, and well written, idiomatic Java isn't performant...so the solution proposed is, rather than…

Or use Rust as it fits this particular use case where you need a language that’s low-level and safe.

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

#400

Post by simonh »

maccard wrote: post #209
simonh wrote: post #110

Earlier quoted context omitted.

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.

But a pause that can happen when you want it is acceptable. A 3 second stall might be totally acceptable as long as it happens outside of a trade, and you can guarantee that.

If you can predict 3 seconds in advance if you’re going to need to trade or not, you’d make millions very quickly. In trading terms, that’s basically having a time machine.
Post reply on HN