[boost] Re: [circular buffer review]

From: Tom Widmer (tom_usenet_at_[hidden])
Date: 2004-03-12 11:15:48

On Fri, 12 Mar 2004 21:06:16 +1100, "Thorsten Ottosen"
<nesotto_at_[hidden]> wrote:

>What is your evaluation of the potential usefulness of the library?
>----------------------------------------------------------------
>I'm in doubt. The library has efficiency as its hallmark. The  rationale
>says that it
>gives efficient FIFO queue. So I tried to compare it with std::deque, and
>here is my results
>of an /O2 build with vc71:
>
>$ ./cbuffer_vs_deque.exe
>
> circular_buffer<int>: 2.15 s
>
>
> deque<int>: 2.84 s
>
>
> circular_buffer<string>: 20.59 s
>
>
> deque<string>: 18.64 s
>
>The test program is attached; I might have made an error, but if I have not,
>then
>I don't see the claim as true. In that case I need to see some more evidence
>about why
>the speed advantages should be so good. It also make me wonder if there is
>any need for
>circular_buffer_space_optimized.

Your code does have at least two major errors:

mutex::scoped_lock lock( mutex );
is a function declaration (demonstrating the danger of C++ and "using
namespace boost"). You meant:
mutex::scoped_lock lock(queue_mutex);

Also, you have implemented a stack rather than a queue; the reader
should use front() and pop_front(). This didn't make much difference
to the benchmark.

You should also probably using condition variables rather than
thread::yield - thread::yield is rarely needed in properly written
multithreaded code (although I've been lucky enough to write most of
my threading code in a realtime operating system with deterministic
scheduling).

But in any case, your benchmark does prove a point - circular_buffer
seems a bit unnecessary if you have a properly implemented std::deque,
as found in Dinkumware's library for one. No ongoing memory allocation
has to happen in std::deque either! This is because it can use a
circular buffer for the map of blocks, and not throw away empty
blocks.

Tom