clayborg added a comment. > Yes. But an implementation of std::async is either going to use a global > thread pool or it's not. If it does there's no problem, and if it doesn't, > it's going to create one thread for each call, and when the work in that > thread is done, the thread will exit. You wouldn't have a situation where > you call std::async 100 times, join on all 100 results, and the 100 threads > are still sitting around. After the work is done the threads would go away. > So by dividing the work into no more than `hardware_concurrency` chunks and > sending those chunks to separate calls invocations of `std::async`, you're > safe.
Performance will be worse if there is a thread created for each task as thread creation is very expensive and can often be slower than just doing things serially for small tasks. > Having a global thread pool is fine, but if that's what we want to do I think > it needs to be a much smaller value than `hardware_concurrency`. Because > having that many threads sitting around doing nothing all the time makes > debugging LLDB a real chore (not to mention being wasteful). I don't agree. They are parked doing nothing taking up no real resources, or they are doing something useful. When tasks come in, the parked threads are ready to go, no spin up time like when using std::async(). Debugging LLDB already has many threads and on MacOSX there are already some libdispatch threads around and they don't add much noise IMHO. We could actually back this new approach with libdispatch on MacOSX, but I would want to verify that the performance is as good or better than the current approach before doing so. The benefit of libdispatch is it will tear down worker threads if they haven't been used in a while. But we could do the same with our approach. If you want to optimize windows with std::async() I would say go for it. Maybe unit tests can run using multiple ways (std::async, TaskPool, libdispatch) and then recommend a default for your platform based on real performance tests. Demangling a bunch of names is one example that could be used for performance testing this. http://reviews.llvm.org/D13727 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
