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