91–100 of 483 posts
Earlier quoted context omitted.
>A few GC parameter tweaks brought our latency below 20ms and the application no longer drops calls. Tick to trade latency for a modern software HFT stack needs to be under 10 _microseconds_, which is over three orders of magnitude more stringent.
10ms is target at which percentile for HFT? From what I could tell in my limited experience, GC impact is worse at the tail of latency distribution
Earlier quoted context omitted.
Why did your system dynamically allocate memory in the first place? High speed messaging sounds like an area where it should be doable to figure out at startup what resources you need to meet your latency and throughput requirements and then allocate them once and basically never gc anything. Was there some fundamental difficulty with that, or was it more that by the time your realized that GC would kill you, all you…
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.
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?
.NET was slower than the JVM before .NET Core but nowadays it's faster.
I used to work on a high-speed messaging system built in Java, and garbage collection was a killer. No matter how much we tweaked the code and the GC parameters, and this eventually got escalated pretty high up in Sun itself, we'd get these occasional multi- minute pauses where the whole thing would just freeze up, buffers would fill and stuff would start dropping on the floor. This was over 10 years ago, so things m…
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…
Another relevant aspect is what happens when one hits GC pauses again. Will there be any tweaks left? Will they conflict with the previous ones? Using such high-level levers to fix performance problems in a specific component is great when it works, but when it doesn't you're out of options.
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…
Which one of these firms made the most money?
The whole of the trading strategy (and capital traded, return profiles, etc) between the first two was fairly different, so it’s hard to compare.
I would say though that the first firm was significantly outperforming its peers in a way the second firm did not, although both were very successful.
The technology wasn’t the whole story in either case, but the first firm had significantly more and better opportunities as a result of just having a better stack all around
Earlier quoted context omitted.
You should not have any full GC (pause) events, ever, in properly written production Java code. Source: I worked on several extremely high performance Java systems at Sun and also worked optimizing various Java servers at subsequent jobs based on my Sun experience. At one company (after Sun) I took on a backend service which was doing GC pauses every 3-5 minutes, the code was a dumpster fire mess. After cleaning thin…
Maybe, but that just raises the question...If you're coding your system under the constraint that you should not be having any GC-event, what's the point of picking a GC language in the first place?
Productivity is the point. Even while paying attention to GC, it's much faster to write good code in Java than to worry about every malloc() in C. I love C, but if I need to churn out high performance code quickly, Java is the choice.
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…
Which one of these firms made the most money?
Earlier quoted context omitted.
Largest instance sounds like aws. There’s your nr 1 performance bottleneck
well, you choose the node infrastructure by whatever network latency you need to have guaranteed - obviously public clouds have their limits there.
Aws is slow. Not talking about the network.
Earlier quoted context omitted.
well, you choose the node infrastructure by whatever network latency you need to have guaranteed - obviously public clouds have their limits there.
But it’s idiotic to discuss ns-optimizations, when your infrastructure and vms add many times more that. Aws is slow. Not talking about the network.