On Tue, 27 May 2014 20:48:12 GMT, Atila Neves wrote:

You may remember that last year I wrote an MQTT broker using vibe.d in response to a challenge from a work colleague about his implementation in Go, and that ended up being a fight between implementations in D, Go, C, C++, Java and Erlang. The D/vibe.d combo won the throughput benchmark by a mile but was middle-of-the-road in latency. That always got to me and I never did know why.

Last week at DConf I learned about the perf tool. It seemed pretty cool but I had to use it on something and I ended up looking at the Java and D implementations in terms of latency. Since the Java version had the best score in that benchmark, it was unsurprising to me that perf revealed that the CPU was idle a lot more for the D version than it was for Java.

I dug deeper and, according to perf, the most time was being spent on pthread_mutex_lock, shortly followed by __pthread_mutex_unlock_usercnt. The call graph points to, in the former case, to calls to FreeListAlloc.elementSize, which in turn is called by AutoFreeListAllocator.free.

The Java version, in contrast, had sys_epoll_ctl at the top and a lower percentage for the top stop.

I think I just found the reason for the performance discrepancy, at least on Linux. Then again I only measured the original benchmarks in Linux.

Atila

Eeek. That's definitely another reason why I'd always favor the explicit way to lock, like implemented by vibe.core.concurrency:

some_shared_obj.lock().doSomething();

or

auto l = some_shared_obj.lock();
l.doSomething();
l.doSomethingElse();

That way, at least you see when you lock and don't implicitly lock on every single operation, but can aggregate multiple acesses.

Okay, for now I've removed all locks from the allocator hierarchy and instead employed a single lock for all of them (8f8c9f9). The further plan is to make the allocators thread-local as far as possible and as it makes sense at some point.

Maybe it's time for another performance tuning session for 0.7.21. That could generate some nice D/vibe.d publicity, if it comes out really fast.