[Graph] Multithreading slowdown on dual core Pentium D
I am experiencing a problem with multithreading using the boost graph
library on a dual core Pentium D platform. If I attempt to calculate average
path length of a graph, I get at least a 2x slowdown using multiple threads
when using johnson_all_pairs_shortest_path. Calculating betweenness is even
worse (~7x) when I use brandes_betweenness_centrality and
relative_betweenness_centrality.
In my test setup, I have no locks anywhere and no shared memory (the graphs
are loaded from a file for each iteration in the test). The graph has been
defined similar to the following (I can't get actual code on the list due to
restrictions from employer):
struct VertexProperties
{
string name;
string group;
vector<string> properties;
};
struct EdgeProperties
{
string name;
double weight;
};
typedef boost::property<...> GraphProperty //a group of enums mapped to
doubles and ints
typedef boost::adjacency_list
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
Doug, Thanks for the pointer regarding the memory allocation (it lead me to the solution). What I found is the problem had to do with the fact that I was building in debug mode. When built in release mode, I got the performance increase that I was expecting (2x), so apparently the debug runtime libraries for windows lock down the heap (which makes sense now) and that was causing the extreme slowdown in the dual core multithreaded app. I appreciate you taking the time to respond. Thanks, Brian
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
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Brian Townley
-
Douglas Gregor