12 ms·
Assuming [this](https://github.com/fastflow/fastflow/blob/master/ff/buffer.hpp#L7-L8 https://github.com/fastflow/fastflow/blob/master/ff/buffer.h...) is the FFB
by carllerche 7y ago
Assuming [this](https://github.com/fastflow/fastflow/blob/master/ff/buffer.hpp#L7-L8 https://github.com/fastflow/fastflow/blob/master/ff/buffer.h...) is the FFBuffer in question, it looks like it is spsc (which would not support stealing). Also, it would need some kind of synchronization to ensure consistency between the consumer & producer.
- jmakov 7y agoYes, it's an implementation of the paper they're referencing - "An Efficient Unbounded Lock-Free Queue for Multi-core Systems". And they've build a framework around it (all queues implemented using this structure). Their benchmarks shows improvement (as shown in their paper). Might be interesting to use that in Rust. But what I miss is a benchmark for various approaches (in Rust, C++ etc.) with trying to use multi core effectively. What I found is that some of the papers use https://parsec.cs.princeton.edu/overview.htm https://parsec.cs.princeton.edu/overview.htm. Probably still better that what we have now - "X nanosec per push/pop".
- gpderetta 7y agoThe advantage of FF is that it is unbounded, but if you add the required mutual exclusion between pop and steal, it will be as expensive (if not more due to the extra complexity).