PHASE meeting

 
 

Last night I attended the Philadelphia Area Scala Enthusiasts (PHASE) monthly meeting. The meeting was devoted to disruptors, which is a programming pattern used by LMAX for high-performance trading software. LMAX wrote their version in Java and open-sourced the pattern, and last night's talk was 80% introduction to the pattern and 20% looking into Jamie Allen's Scala implementation of disruptors.

I was amazed that there are people out there trying to get high performance from Java. They are writing with the computer architecture in mind and doing tricks like padding a variable with 7 longs on each side to ensure that it's the only variable on a cache line. That is, anytime the CPU pulls data from a cache, it gets a chunk of bits from memory (either from registers, one of the caches on the processor, the cache outside the processor, or from RAM). The chunk of bits the CPU retrieves is always the same size, and the idea behind the disruptor is that ensuring that the chunk will only ever contain one variable will prevent the contention for resources that might arise if two variables on the same cache line were needed by different CPU cores simultaneously.

This is just one of the ideas implemented by LMAX in their disruptors pattern. The whole things is very slick and looks like Java that you would never write in production, but they did it because it runs very fast on their architecture. This is code that's usually reserved for C or assembly, a low-level language where you can directly address memory. The fact that LMAX is mixing low-level memory manipulation with a high-level language like Java is mind blowing. I've always thought of Java as too slow for high performance computing, let alone to high-level for memory manipulation. But LMAX has shown me otherwise.

The Scala implementation is still a work in progress, so there wasn't much talk of it other than showing a couple lines of code and pointing to the Github repository. The ideas presented in the meeting were fascinating, and they were a good reminder that even though I don't need to care about 100-ns versus 10-ns access times, it's always good to write software that responds rapidly.

Comments [0]