On Thu, 2007-01-18 at 13:27 -0600, Brian Townley wrote:
All I have to do in my code to see the slowdown is to use a populated graph with johnson_all_pairs_shortest_path in some iterative loop in both one and multiple threads. A real kicker is that currently I can get around this problem by spawning multiple processes to deal with the data load (so I have an interim solution at least) and that gives me a performance improvement by 2x which I expect with dual core... However, I really want to know why this isn't working in a multi-threaded environment.
What could I be doing wrong? Is there some proprocessor #define that makes the boost graph library more thread independent? Is there something wrong with the way that I am declaring the graph? Any help is appreciated!
The graph library itself doesn't have any such defines; it's entirely sequential code with no thought given to multithreading. There are some places in Boost that are sensitive to multithreading, e.g., shared_ptr. It's also possible that your standard library implementation is doing some locking. Memory allocation routines are the most likely suspects, I think: a good multithreaded memory allocator can give a big performance boost. Cheers, Doug