On Fri, 12 Mar 2004 21:06:16 +1100, "Thorsten Ottosen" <nesotto@cs.auc.dk> 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