Doug,<br><br>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. 
<br><br>I appreciate you taking the time to respond.<br><br>Thanks,<br>Brian<br><br><div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>The graph library itself doesn&#39;t have any such defines; it&#39;s entirely<br>sequential code with no thought given to multithreading.<br><br>There are some places in Boost that are sensitive to multithreading,<br>
e.g., shared_ptr. It&#39;s also possible that your standard library<br>implementation is doing some locking. Memory allocation routines are the<br>most likely suspects, I think: a good multithreaded memory allocator can<br>
give a big performance boost.<br><br>&nbsp;&nbsp;Cheers,<br>&nbsp;&nbsp;Doug<br><br>_______________________________________________<br>Boost-users mailing list<br><a href="mailto:Boost-users@lists.boost.org">Boost-users@lists.boost.org</a><br>
<a href="http://lists.boost.org/mailman/listinfo.cgi/boost-users">http://lists.boost.org/mailman/listinfo.cgi/boost-users</a><br></blockquote></div><br>