home
> blog
>> 748

translate to German (by SYSTRAN)

Weblog RDF feed, Atom feed

Sat Apr 21 19:24:24 2012 GMT: boost asio thread contention

Sat Apr 21 14:51:42 2012 GMT: Spurious EPOLLOUT events

Sun Apr 01 11:03:28 2012 GMT: Run, Christof, Run

Just couldn't stop running this morning and ended up doing 7 laps around Battersea Park - Google Maps reckons it's about 3.3 km per lap - which would mean around 23 km in total.

Thu Mar 29 20:43:00 2012 GMT: boost asio 1.46.1 vs. boost asio 1.49.0

I have now re-run my socket communication tests with Boost 1.49.0 which shows a huge improvement in the 16 socketpairs case where we actually have some real concurrency:

But the 1 socketpair case still shows some rather bad performance when using multiple worker threads:

Stay tuned...

Tue Mar 27 18:19:40 2012 GMT: Opera 11.62

Well, this release fixes a security issue I reported about 3 months ago...

Sun Mar 25 00:31:10 2012 GMT: Overhead and Scalability of I/O Strategies

Having briefly looked at epoll vs. kqueue on Linux and FreeBSD/NetBSD, I'll now focus a bit more on Linux and this time I am adding some real concurrency into the mix in the hope of seeing some speedup with multiple threads.

The basic test set-up is similar to what we had previously: sending 4-byte datagram packets between a socketpair - but this time we also want to introduce some concurrency and use 16 socketpairs in a second test. And as a test machine we are using a quad-core Intel i7-2600K @ 3.4 Ghz (with hyperthreading enabled - so we get 8 hardware threads).

So in a first test we compare the performance of a blocking send/recv loop, a hand-written epoll loop, boost asio (1.46) and my own async abstraction when changing the number of worker threads (NB: for the blocking send/recv we always use a fixed number of threads equal to the number of socketpairs).

As expected, a blocking send/recv is the fastest option. But what's really interesting to see is that while epoll/asyncsrv only show a moderate slowdown with more worker threads, boost asio shows a significant slowdown. Note that there is only one message in transit, so we wouldn't expect a speedup anyway.

Ok, so let's add some concurrency by increasing the number of socketpairs to 16 (and decreasing the number of iterations accordingly).

Now we can see that both the hand-written epoll loop and my async library scale reasonably well and provide a speed-up when the number of worker threads is increased. But boost asio again shows a significant slowdown.

Sat Mar 24 23:28:16 2012 GMT: Romeo and Juliet @ Royal Opera House

I have just been to a ballet performance of Romeo and Juliet at the Royal Opera House.

Wed Mar 21 22:08:09 2012 GMT: kevent on FreeBSD (Update)

Sun Mar 18 20:55:50 2012 GMT: Multi-threaded epoll/kqueue

Mon Mar 05 23:17:44 2012 GMT: The Dream / Song of the Earth @ Royal Opera House

Fri Mar 02 23:00:37 2012 GMT: DNSSEC fully enabled for cmeerw.net

Fri Mar 02 00:03:53 2012 GMT: Rusalka @ Royal Opera House