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

221–230 of 483 posts

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

#221

Post by capableweb »

wankeler wrote: post #137
thangalin wrote: post #45

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

You’re coding safety critical systems and depending on severely non-deterministic tweaks to GC to get it to run right?! Where is this for? (Just so I can avoid it)

No need to know where this person is deploying this, if you want to avoid people doing stupid shit with safety critical systems you should just avoid going outside. Actually, avoid leaving the bed, as everything software in this day and age is basically just duct tape and cable ties put together in a rush to hit deadlines.

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

#222

Post by treespace89 »

The quote here is the main point. "But if you want to engage with 20+ exchanges, to go to market quickly, and implement continuous performance tuning, you'll choose Java."

The amount of changes you need to make due to customer preferences and regulations is continuous. If it's ok for your system to run in the 100 microsecond range then Java is a clear winner. If you are just focused on a single exchange, running in the same rack as the exchange then of course C or lower is what you will want.

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

#223

Post by ku-man »

zanellato19 wrote: post #195
Karellen wrote: post #193

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.

Given the same conditions (i.e. people don't die) the same outcome would present itself. We have a history of bridges falling down, so much so that Wikipedia has a list on that: https://en.wikipedia.org/wiki/List_of_bridge_failures A particular one that caught my eye: Cimarron River Rail Crossing Dover, Oklahoma Territory United States 18 September 1906 Wooden railroad trestle Washed out under pressure from debris du…

There are definitely several ancient and recent cases of bad design or execution in civil/mechanical/chemical engineering. The difference is that there is a very strict regulatory body that reviews and sanctions such malpractices (not to mention the exams you need to write to become a member of such bodies).

Unfortunately, when it comes to software development we have people who modify wordpress templates and call themselves engineers...

I cringe whenever I read about the new 'engineering disciplines' such as 'react engineer' or 'dev-ops engineer' or 'gis engineer'.

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

#224

Post by chrisseaton »

toolslive wrote: post #171
chrisseaton wrote: post #140

Earlier quoted context omitted.

I don’t know what you think the practical benefit of running with no OS is?

- raw, unshared access to devices. - no more interrupts. You can get really close to this via virtualization though. Run a guest machine without operating system on the hypervisor. It doesn't even have to be low level code to get most of the benefits (for example MirageOS)

> raw, unshared access to devices

Get to OS to set up DMA for you.

> no more interrupts

If the OS has no need to interrupt you, it will never interrupt you. The OS doesn't context switch from a usefully running application on its own core unless you ask it to.

Don't need virtualisation.

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

#225

Post by MaxBarraclough »

piaste wrote: post #214
cobbzilla wrote: post #198

Earlier quoted context omitted.

The sarcastic/negative implication of your example is that software engineering today is where civil engineering was 100+ years ago.

Yes, but not because software engineers are worse human beings than civil engineers, which is all too often the undertone of these discussions. Rather, because software engineering hasn't killed enough people to advance; or when it has, it wasn't obviously the culprit. In which fields of software engineering do we find actual solid procedures and standards? Avionics. Medical hardware. Fields where the link between bu…

> not because software engineers are worse human beings than civil engineers, which is all too often the undertone of these discussions

I think the undertone is usually that the software developer at fault had no idea what they were doing, and had no place working on critical systems, rather than that they had ill intent.

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

#226

Post by chrisseaton »

mcqueenjordan wrote: post #189
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.

This is a bit of a false equivalency -- there aren't many perf benefits in rewriting a C program in asm. The cost you pay for that rewrite is also much greater. Yes, of course $HIGH_LEVEL_LANG is preferable for many many use cases. In this context, we're discussing "high speed trading systems", for which native implementations are going to be the favorite.

> for which native implementations are going to be the favorite

...but the point of the article is they aren't always the favourite.

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

#227

Post by [deleted] »

wolf550e wrote: post #173
chrisseaton wrote: post #138

Earlier quoted context omitted.

What do you mean by ‘devirtualizer’ and why would you want that triggered? Sounds like something you wouldn’t want to trigger?

See Aleksey Shipilёv on JVM method dispatch: https://shipilev.net/blog/2015/black-magic-method-dispatch/

[deleted]

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

#228

Post by levosmetalo »

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

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

#229

Post by chrisseaton »

masklinn wrote: post #177
chrisseaton wrote: post #162

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

What do you mean by “virtual object”, an object which has been broken up on the stack instead of a “real” object living as a single entity on the heap?

> What do you mean by “virtual object”, an object which has been broken up on the stack instead of a “real” object living as a single entity on the heap?

Yes... but let's not say 'broken up on the stack' - the object's fields become dataflow edges. The object doesn't exist reifed on the stack - fields may exist on the stack, or in registers, or not at all.

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

#230

Post by 95th »

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…

Well there is a middle ground - Rust
Post reply on HN