Could someone point to C-like Java code real-world example? It would be awesome to see how the things are managed at a GC platform with most things on the heap.
Java is better than C++ for high speed trading systems
211–220 of 483 posts
Re: Java is better than C++ for high speed trading systems
#212Earlier quoted context omitted.
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…
The sarcastic/negative implication of your example is that software engineering today is where civil engineering was 100+ years ago.
made me chuckle.
Re: Java is better than C++ for high speed trading systems
#213Hearing 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 zero control over the OS; you need to turn off unnecessary processes, pin processes to cores, exclude processes from cores and so on.
Having said all that, I do know of at least one hedge fund in London that is mostly C#-based (though I have no idea whether their 'deep' trading code is C# though).
Re: Java is better than C++ for high speed trading systems
#214Earlier quoted context omitted.
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…
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 bug and death is as short as possible, and so the stakeholders have demanded solid engineering.
What are the consequences of GP's acquaintance writing poor code? Some trading firm becomes slightly less efficient at trading. Impossible to evaluate the net human loss from it (if it's a loss at all).
The civil engineering equivalent would be something like façade design or layout. If your building is ugly or confusing, it will annoy or waste the time of the people who live and work in it, but as long as it doesn't fall on their heads nobody is going to withdraw your certification.
Re: Java is better than C++ for high speed trading systems
#215Earlier quoted context omitted.
The sarcastic/negative implication of your example is that software engineering today is where civil engineering was 100+ years ago.
I don’t think that is too far off the mark. Given 8 more decades of progress we might even be able to produce reliable code. Webpages will be 100GB of JavaScript though
I think reliability is, after a certain point, inverse proportional to the amount of code involved. So I'd disagree that we'll have even larger webpages then - the same way that in modern construction, heavy and thick stone & brick pillars have been replaced with comparatively light and strong steel-reinforced concrete. Maybe the equivalent would be just enough strongly typed code running on top of just enough, well tested & secure WASM?
Re: Java is better than C++ for high speed trading systems
#216I’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).
Re: Java is better than C++ for high speed trading systems
#217Earlier 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.
You shouldn't compare bridge building to developing a trading apps (on causes death, the other merely financial loss) Compare bridge building to developing software for pace maker. Now compare number of failures in both cases. You get what you pay for, if you pay for developer you'll get a developer.
You can convert between financial loss and loss of human life using implied cost of averting a fatality [1], which is about $10 million.
Re: Java is better than C++ for high speed trading systems
#218Re: Java is better than C++ for high speed trading systems
#219As an HFT programmer I like this article because it means less competition for me. I mean, you can write a very fast system in Java but by the time you accomplish that goal you’ll have spent as much or more time than if you had just used C++.
Having done both I agree with you. I find it's harder to write non idiomatic code that pretends to be another language than to just spend the time learning that other language. But I get why people might feel it's worth a try, cpp probably looks more daunting than any other language to a novice. There's a lot of concepts to be mastered before you can write decent cpp, where in a lot of languages you can get started a…
I recall listening to a recent interview with
Chris Lattner who said the more languages you learn the faster it is to pick up others because of the overlaps.
Working in other languages, the idea of references and values didn't kick in to me, that is until I learned basic C++. I think it's because C++ engineers (well, the ones I would watch anyway) were sticklers for performance and so they'd describe the subtle differences in implementation. Even though I don't code C++ anymore, using it for a short time really helped to develop a better understanding of how code actually works.
Re: Java is better than C++ for high speed trading systems
#220Earlier 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.
You shouldn't compare bridge building to developing a trading apps (on causes death, the other merely financial loss) Compare bridge building to developing software for pace maker. Now compare number of failures in both cases. You get what you pay for, if you pay for developer you'll get a developer.
I remember reading about bad software in a radiotherapy machine inducing many deaths. And also about software in Toyota cars failing and also inducing deaths because the code was a huge mess. In the end, there is no such thing as a clear separation between "engineer" and "developers".