Gesendet: Donnerstag, 02. April 2020 um 18:43 Uhr Von: "Jan Hafer via Boost" <boost@lists.boost.org> Thanks for the fast reply.

...

...

Is this behavior expected or documented anywhere? What kind of speedup is to be expected against the std::queue implementation? If there is none, then what is the purpose of circular buffer?

You could read the relevant docs. I strongly doubt that this boost container is slower than anything in the STL when compared like for like.

True, could reproduce.

...

I do also have broken code on a multithreaded application that worked

...

fine before. I do pass the circular buffer as reference via functions from file scope, which in combination with the threads (initially starting elsewhere) somehow broke the code.

Do you do regular benchmarks against other implementations? I dont see linked graphs on your homepage.

I would like to see the benchmark results against std-implementations linked on the main page. If possible, also as simple comparison per thread count.

Could you give a full example /repro of what exactly you are measuring? Saying "container X is faster than Y" is not very helpful without showing what operations you are measuring and what the workload is. You e.g. could create a small github repository, or a gist, or put the your benchmark here: http://quick-bench.com/ Best Mike

On 02.04.20 20:59, Mathias Gaunard wrote:

On Thu, 2 Apr 2020 at 17:43, Jan Hafer via Boost <boost@lists.boost.org> wrote:

...

Yes, I do use 1 buffer/queue per thread.

So you're saying that circular_buffer is slower on a given thread when other threads are accessing their own circular_buffer in parallel? That sounds unlikely to be circular buffer's fault.

Yes and I dont know quite the reason for it. My Threads know their id to access a file-global data structure containing their queue/circular buffer. They start another after in a thread-safe way and exit on emptying the queue/circular buffer.

The first thing to check is that the memory placement of your circular buffer does not result in false sharing with other threads. More generally you could be stalling due to any inter-connection, such as crossing NUMA domains or talking to hardware. Otherwise you could be saturating the execution ports of your core and thus not get the expected speed-up from hyper-threading, but in any case you'd be the best throughput overall.

I know how to obtain the source code of boost, but the compiler vendors sadly provide no direct internet-searchable links to the std source code. Thanks for your advice. I may dig further with perf to obtain cache-miss statistics. My goal was just to inform you of this characteristics, since this is not documented.

On 3/04/2020 08:41, Jan Hafer wrote:

On 02.04.20 20:59, Mathias Gaunard wrote:

...

So you're saying that circular_buffer is slower on a given thread when other threads are accessing their own circular_buffer in parallel? That sounds unlikely to be circular buffer's fault.

Yes and I dont know quite the reason for it. My Threads know their id to access a file-global data structure containing their queue/circular buffer. They start another after in a thread-safe way and exit on emptying the queue/circular buffer.

That sounds like you're allocating a single array of circular_buffers and then accessing them from different threads. That's basically the worst possible thing to do; as Mathias was saying, that will end up sharing cache lines between different cores and your performance will tank. At minimum, you should embed the circular_buffer into another struct that has sizeof() >= std::hardware_destructive_interference_size, and make an array of that. But better still, embed the circular_buffer into your processing classes and don't have arrays of them at all. (If you're pre-C++17 and don't have std::hardware_destructive_interference_size, then using 64 works for most modern platforms.) Ideally, the circular_buffer implementation itself should also separate all internal producer-thread members and consumer-thread members by std::hardware_destructive_interference_size and try very hard to not cross over. (Here the main thing that matters is write accesses.) If you want to try using a more modern circular buffer that gets this correct, have a look at Boost.Lockfree's spsc_queue. https://www.boost.org/doc/libs/1_72_0/doc/html/boost/lockfree/spsc_queue.htm... (While you're there, there's also an MPMC queue as well. Note that a lockfree queue will tend to be slower than std::queue in uncontended benchmarks, but the avoidance of locks can be superior in highly contended or other specialised scenarios.)

On Fri, 3 Apr 2020 at 02:35, Paul A Bristow via Boost <boost@lists.boost.org> wrote:

I am following this discussion thread with no particular interest, but I can imagine that there are others who will find the discussion, theorizing and advice rather valuable. Can anyone add a link to it to the circular buffer documentation?

I assume it's this cb: https://www.boost.org/doc/libs/1_72_0/doc/html/circular_buffer.html degski -- @systemdeg "We value your privacy, click here!" Sod off! - degski "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey