线程如何节省时间? [英] How does threading save time?
问题描述
我正在学习 C# 中的线程.但是，我无法理解线程的哪些方面实际上在提高性能.
I am learning threading in C#. However, I can't understand that which aspects of threads are actually improving performance.
考虑一个只有一个核心处理器的场景.将您的任务拆分为多个线程使用相同的进程上下文(共享资源)并且它们同时运行.由于线程只是共享时间，为什么它们的运行时间(周转时间)少于单个线程进程?
Consider a scenario where there only a single core processor exists. Splitting your task into multiple threads uses the same process context (shared resource) and they run simultaneously. As the threads are just sharing time, how come their run time (turnaround time) is less than a single threaded process?
推荐答案
考虑一个只有一个核心处理器的场景.将您的任务拆分为多个线程使用相同的进程上下文(共享资源)并且它们同时运行.由于线程只是共享时间，为什么它们的运行时间(周转时间)少于单个线程进程?
Consider a scenario where there only a single core processor exists. Splitting your task into multiple threads uses the same process context (shared resource) and they run simultaneously. As the threads are just sharing time, how come their run time (turnaround time) is less than a single threaded process?
您对此处任何声称的加速持怀疑态度是完全正确的.
You are entirely correct to be skeptical of any claimed speedup here.
首先，正如 Servy 和其他人在他们的回答中指出的那样，如果作业不受处理器限制，那么显然这里可以有一些加速，因为 当处理器空闲等待磁盘或网络回来，它可能正在做另一个线程的工作.
First off, as Servy and others point out in their answers, if the jobs are not processor bound then clearly there can be some speedups here because while the processor is idle waiting for the disk or the network to come back, it could be doing the work of another thread.
但是让我们假设您有两个处理器绑定任务、一个处理器和两个线程或一个线程.在单线程场景中，它是这样的:
But let's suppose you have two processor-bound tasks, a single processor, and either two threads or one thread. In the one-thread scenario it goes like this:
- 完成作业 1 的 100% 工作.假设这需要 1000 毫秒.
- 完成作业 2 的 100% 工作.假设这需要 1000 毫秒.
总时间:两秒.完成的工作总数:两个.但重要的是:等待作业 1 的客户端仅在一秒钟内完成了工作.等待作业 2 的客户端必须等待两秒钟.
Total time: two seconds. Total jobs done: two. But here's the important bit: the client that was waiting for job 1 got their job done in only one second. The client that was waiting for job 2 had to wait two seconds.
现在如果我们有两个线程和一个 CPU，它会是这样的:
Now if we have two threads and one CPU it goes like this:
- 完成作业 1 的 10% 的工作，持续 100 毫秒.
- 完成作业 2 的 10% 的工作，持续 100 毫秒.
- 完成工作 1 的 10% 的工作
- 完成工作 2 的 10% 的工作...
同样，总时间为 2 秒，但这次 等待作业 1 的客户端在 1.9 秒内完成了作业，比单线程方案慢了近 100%！
Again, total time two seconds, but this time the client that was waiting for job 1 got their job done in 1.9 seconds, nearly 100% slower than the one-thread scenario!
所以这就是这里故事的寓意，您指出的完全正确.如果满足以下条件:
So that's the moral of the story here, that you are entirely correct to point out. If the following conditions are met:
- 作业受 CPU 限制
- 线程比 CPU 多
- 这项工作仅对其最终结果有用
然后添加更多线程只会减慢您的速度.
Task Parallel Library 等库就是为这种场景设计的；他们试图弄清楚何时添加更多线程会使事情变得更糟，并尝试仅调度与 CPU 一样多的线程来为它们服务.
Libraries such as the Task Parallel Library are designed for this scenario; they try to figure out when adding more threads will make things worse, and try to only schedule as many threads as there are CPUs to serve them.
现在，如果这些条件中的任何一个不满足，那么添加更多线程是个好主意.
Now, if any of those conditions are not met then adding more threads is a good idea.
如果作业不受 CPU 限制，则添加更多线程允许 CPU 在空闲时执行工作，等待网络或磁盘.
If the jobs are not CPU bound then adding more threads allows the CPU to do work when it would otherwise be idle, waiting for network or disk.
如果有空闲的 CPU，则添加更多线程允许调度这些 CPU.
If there are idle CPUs then adding more threads allows those CPUs to be scheduled.
如果部分计算的结果有用，那么添加更多线程会改善这种情况，因为客户端有更多机会使用部分计算的结果.例如，在我们的第二个场景中，两个作业的客户端每 200 毫秒都会获得部分结果，这是公平.
If partially-computed results are useful then adding more threads improves the situation because there are more opportunities for clients to consume partially-computed results. In our second scenario, for instance, the clients of both jobs are getting partial results every 200 milliseconds, which is fair.
这篇关于线程如何节省时间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
