Re: [boost] [Review] Lockfree review: two more days left

Subject: Re: [boost] [Review] Lockfree review: two more days left
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2011-07-26 09:59:19

Hi,

First, I intend to contribute a review, even though not a fully one (and
hopefully it will be ready on time ;). My knowledge on
the theoretical aspects is too limited to judge the actual implementation,
but there a few simple points that I would like to check about performance.

The rest of the e-mail is mainly addressed to Tim.

First, I have re read the doc and started to look at the implementation and
I found something that is apparently a contradiction:

- In the doc you say "Spinlocks do not directly interact with the operating
system either. However it is possible that the owning thread is preempted by
the operating system, which violates the lock-free property"

- In the code however (for fifo<T>), the code seems to be "spinning" all the
time using "for (;;)" loops.

Could you give me some precisions on why this is ok ?

Then, I started to wrote a test program to compare performance with Intel's
Thread Building Block library (3.0 update 7, the latest stable). I am far
from finished, but my first results are that boost::lockfree is slower on my
machine by about 40%.

I use the TBB concurrent_queue<T> class that is according to the doc
"non-blocking". I had a quick look at the implementation it seems to be
using a similar technique as fifo<T> (that is spinning, no system locks). Do
you know whether this is actually a lock free structure or not ?

My question is not demanding that you match Intel's perf ;) but rather if
you have any ideas on what could be done to improve the performance further
(Intel's using assembly for instance, no idea if it has a big impact,
another suspect may be a better atomic implementation).

I have attached the code FYI (please keep in mind that this is a quick
test). The interesting part is the "SimpleTest" functions.
I compiled on Ubuntu 11.04 / gcc 4.5 in C++0x mode.
I measured the time using the "time" command. I ran the sample on an AMD cpu
which cpuinfo are attached.

I'll perform some other tests and I'll keep you updated.

Thanks again for your efforts,

Julien