131–140 of 483 posts
Earlier quoted context omitted.
I've heard of people doing that 10-15 years ago. I'm sure it still works, but hopefully the GC situation has also improved.
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.
Earlier quoted context omitted.
Did I miss the announcement? But AFAIK .NET 5 isn't production ready yet.
.NET 5 was released Nov 10th: https://devblogs.microsoft.com/dotnet/announcing-net-5-0/
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?
Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…
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…
Totally agree, although I think strong typing is also important, not just static typing. C/C++ has a weak type system because of the automatic conversions it allows.
The problem with this discussion however is that the people that push for dynamic languages usually do it because it's "so fast" to do something in Python, and they won't test their software anyway.
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…
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…
Programmers used to say that the GC and its fuc*#=+ STW was a pure mess, but under the hood, they didn't realize (accept ?) in fact the code WAS the mess.
Don't (always) blame the tool !
C++ is a fantastic language but it somehow attracts people with big ego. The smartest people I know would always try to simplify things, but many C++ developers (especially in financial industry) have this preference for complexity I can't explain. And C++ is the worst language to get clever with.
I don't want to start a flame war, but what are some of the programming languages that attract the first variety of people?
From my experience: (apologies if this looks like a flame; purely personal experience, with no offense intended).
- Python attracts all kinds of people.
- Java attracts people who prefer rigid structure, specified down to minute detail (which non Java people will often consider unneeded bureaucracy)
- C++ attracts people who like brain teaser challenges with lots of details and steps. The compiler is both their colleague and adversary in reaching the optimal speed goal (their "frenemy")
- C attracts people with more experience who just wants "the simple thing that works" without giving up the low-level control that they would have to give up using e.g. Python or Java.
- K/J/APL attract people who like brain teaser with short elegant solutions, even (and perhaps especially) if reaching and understanding that solution takes nontrivial effort -- which is basically also people who like math for math's sake.
- COBOL attracts people who like job security, good income, don't care much about job satisfaction or recent advances made in the last 30-40 years, and want everyone to get off their lawn :)
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…
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?
Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…
Earlier quoted context omitted.
Yeah, basically everything has to be that way. At the super fast speeds you start running into things like: * why won’t the devirtualizer trigger? * these object headers are sure wasting a lot of cache * there’s a lot of forced pointer indirection And you just end up spending vast amounts of time and effort trying to shave off those few microseconds you’re wasting in the JVM. Once you add in all the effort trying to…
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.
The answer to both questions is that many people prefer writing in higher-level languages with more safety guarantees.
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…
Am I understanding correctly that those firms really really care about latency & have unlimited money & chose C++/JAVA with a standard off-the-shelve compiler + an OS and/or JVM?? If you'd really really care about latency and have the resources, wouldn't it be more effective to just go bare metal? Bare metal as in: no OS (talk to the hardware registers directly from code), possibly a custom compiler, use all the rele…