pool allocator performance with multiple threads
Does anyone know if the fast_pool_allocator is supposed to work in a multithreaded environment? I know that it is "thread-safe," but I'm getting some really discouraging test results from it. Namely, using fast_pool_allocator is consistently performing about 10 times SLOWER for me than new/delete whenever multiple threads are involved. I've tested and come up with the same results on three different platforms: Mac, Linux and Windows (MSVC). I get the impression that I just need to roll my own allocator if I'm using more than one thread, but I'm hoping that this is not the case. If it helps, I can put together and post some source code that demonstrates these results. Thanks, -Mike
Does anyone know if the fast_pool_allocator is supposed to work in a multithreaded environment? I know that it is "thread-safe," but I'm getting some really discouraging test results from it. Namely, using fast_pool_allocator is consistently performing about 10 times SLOWER for me than new/delete whenever multiple threads are involved. I've tested and come up with the same results on three different platforms: Mac, Linux and Windows (MSVC).
from my understanding, the pool implementations of boost use a global lock, so it doesn't scale very well in multithreaded environments ... the memory allocators on most systems avoid locking by using thread- specific caches ... or, like the streamflow library, use lock-free algorithms ... best, tim -- tim@klingt.org http://tim.klingt.org Which is more musical, a truck passing by a factory or a truck passing by a music school? John Cage
participants (2)
-
Michael Dickey
-
Tim Blechmann