|
Boost Users : |
From: Brian Townley (thranil_at_[hidden])
Date: 2007-01-19 11:07:53
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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net