c++ Jobqueue：工作线程的数量有经验法则吗？
我刚刚在 C++ 中实现了第一个简单的多线程作业队列，我认为（并读到）为每个硬件线程使用一个工作线程（在我的例子中为 4 个）是一个好主意。基本上，我的应用程序现在只是从互联网加载大量图像（同时），并且我注意到，如果将工作线程数量增加到 8 甚至 16 而不是 4，我会获得巨大的速度提升
。在这样的作业队列中使用多少个线程的一般规则？我的猜测是，如果我每帧创建新作业，并且工作线程每帧都有恒定的工作负载，而如果我想一次处理很多东西（比如加载 50 张图像左右），那么 4 会是一个很大的数字。更多的线程可以大大提高速度。尽管如此，在不同情况下是否有正确的数字的经验法则？
谢谢
I just implemented a very first simple multithreaded jobqueue in c++ and I thought (and read) that it's a good idea to use one worker thread for each hardware thread (in my case that would be 4). Basically my app just loads alot of images (at the same time) from the internet right now, and I notice that I get a huge speed up if I increase the number of worker threads to 8 or even 16 instead of 4.
Is there a general rule of how many threads to use in such a jobqueue? My guess would be that 4 would be a greate number if I was creating new jobs each frame, and the worker threads had a constant workload each frame, while if I want to process alot of stuff at once (like loading 50 images or so) more threads than that can give a great speed up. Still, is there a rule of thumb for the right number in different scenarios?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
理想的工作线程数等于系统中 CPU 核心的数量。然而，实际上这并不是最理想的，因为有时任务可能会阻塞网络、磁盘 I/O 等，从而导致利用率不足。这听起来就像这里正在发生的事情。
很多时候，线程池会“超出计划”来弥补这一点。有时，内置的内核支持会在线程阻塞时通知您，因此您知道启动另一个线程（Win32 中的完成端口）并且仍然达到最佳的活动工作线程数。
The ideal number of worker threads is equal to the number of CPU cores in the system. However, in reality this is suboptimal because sometimes tasks can block on the network, disk I/O, etc.. resulting in underutilization. That sounds like what is happening here.
Often times thread pools will "over schedule" to compensate for this. Sometimes there is built in kernel support for notifying you when threads block, so you know to spin up another one (completion ports in Win32) and still hit the optimal number of active worker threads.
Microsoft 选择提供线程池实现（可从操作系统获得，同样可在 .net 中获得），线程数量从处理器数量的 1.5 倍开始。这个想法是，阻塞的线程（磁盘 I/O 等）可以换出另一个未阻塞的线程。线程池也是可配置的，以便您可以要求最小数量的线程（如果您决定需要 2x、3x 或更多线程）。
我怀疑所有这些都适用于您的情况。
Microsoft chose to provide a threadpool implementation (available from the OS, and likewise available in .net) with the number of threads starting at 1.5 times the number of processors. The idea is that a thread that blocks (for disk i/o, etc) can swap out for another thread that is not blocked. The threadpool is also configurable so that you can demand a minimum number of threads, should you decide that having 2x, 3x, or more threads are necessary.
I suspect all of this applies to your situation.
不久前，我正在寻找这个问题的答案，我发现了一篇 msdn 文章，其中指出最好每个核心使用最多 16 个线程。不幸的是我找不到这篇文章了，但对于加载图像来说，每个核心 16 个线程是有意义的。
Some while ago I was looking for the answer of that question and I came across an msdn article which stated that it is best to use max 16 thread per core. Unfortunately I can't find the article anymore, but for loading images, 16 threads per core make sense.