是一个带有 c/c++ 线程的程序应该比串行运行得更快？
我正在学习c/c++中线程的概念。我正在尝试这些例子 Pthreads 概述中引用的两个向量的点积。
我运行了代码的串行版本和线程版本，发现认为 串行版本比线程版本更快。我认为应该是 对面的。
我在单个 CPU 上运行。
I am learning the concept of threads in c/c++. I was trying the examples for
the dot product of two vectors cited in Pthreads Overview.
I ran both the serial and the thread version of the code and I found that the
serial version was faster than the thread version. I thought it should be the
opposite.
I am running on a single CPU.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
链接到的代码有一些您需要记住的问题：
a = (double*) malloc (NUMTHRDS*VECLEN*sizeof(double));--NUMTHRDS设置为 4和代码中的 VECLEN 100）。因此，并行程序正在执行四倍的工作量，但有四个线程，因此天真的假设是串行和并行程序将具有相同的运行时间。The code that link to has a few issues that you need to keep in mind:
a = (double*) malloc (NUMTHRDS*VECLEN*sizeof(double));--NUMTHRDSis set to four andVECLEN100 in the code). Therefore, the parallel program is doing four times the amount of work, but with four threads, so the naive assumption is that the serial and parallel programs will have the same run time.如果只有一个处理器，那么这并不奇怪。
线程代码仍然需要执行与串行代码相同的工作量，并且它还具有上下文切换的额外负担，从而减慢了速度。
如果可以并行化并且有多个核心来共享工作，则多线程代码将显示出加速。
If there's only have a single processor, then it's not much of a surprise.
The threaded code still has to execute the same amount of work as the serial code, and it has the additional burden of context switching to slow it down.
Multi-threaded code will show a speed up if parallelization is possible and there are multiple cores to share the work.
一般来说，线程程序没有理由比串行程序运行得更快，反之亦然。
在单个 CPU（或核心）上，您会产生从一个线程切换到另一个线程的开销。
即使在多 CPU（核心）系统上，也存在协调线程的开销。
如果问题是令人尴尬的并行，那么在多个线程上使用多个线程应该相对更容易更快地解决它核，但仍然可以通过性能较差的方式来解决。
对于 GUI 应用程序，让一个线程响应用户操作，同时另一个线程进行计算，可以提高系统的响应速度。
另请参阅阿姆达尔定律：
In general, there is no reason a threaded program should run faster than a serial program, or vice versa.
On a single CPU (or core), you'd have the overhead of switching from one thread to another.
Even on a multiple CPU (core) system, there is the overhead of coordinating threads.
If a problem is embarrassingly parallel, it should be relatively easier to solve it faster with multiple threads on multiple cores, but it is still possible to solve it in a way that performs poorly.
With GUI applications, having one thread respond to user actions while another thread carries on computations makes the system more responsive.
See also Amdahl's Law:
这将取决于您的设计。我没有看你的代码，但并行编程在加速程序方面占有一席之地。
在某些情况下，使用线程只是为了保持应用程序的响应能力（这很好）。在其他情况下，您将使用它来提高性能，但您需要在良好的CPU中很好地规划并行处理。
克劳迪奥·M·苏扎·儒尼奥尔
It will depend on your design. I did not take a look on your code, but parallel programming has its place on accelerating programs.
In some cases, threads are used just to keep the application responsive (it is good). In others, you will use to boost performance, but you need to make parallel processing well planned in a good cpu.
Claudio M. Souza Junior
在很多情况下，线程并不能提高性能。
如果您的任务受内存限制，添加线程通常不会有帮助。您要做的就是增加对总线时间和缓存槽的争用。当您的线程将彼此的数据推出缓存时，会增加缓存未命中的机会，这会减慢速度 - 如果您有更多线程争夺总线，情况更是如此。
如果它受 CPU 限制，性能增益将很大程度上取决于您拥有的内核数量。一旦线程数量超过可用核心数量，您将不会获得任何收益。
如果您的任务处理相同的数据，您将需要它们之间的同步。这种同步意味着序列化代码的某些部分，如果任务太密切相关，那么无论如何您最终都会一次运行一个线程。
在每种情况下，您还必须计算使用线程所固有的成本（上下文切换、额外资源等）。如果成本超过收益，那么您很可能会因线程而实际减慢速度。
There are a bunch of cases where threading doesn't improve performance.
If your tasks are memory-bound, adding threads usually won't help. All you'll be doing is increasing contention for bus time and cache slots. As your threads push each other's data out of the cache, it increases the chances of a cache miss, which will slow things down -- even more so if you have more threads fighting over the bus.
If it's CPU-bound, the performance gain will be very dependent on how many cores you have. Once the number of threads exceeds the number of available cores, you won't gain anything.
If your tasks are working on the same data, you'll need synchronization between them. That synchronization will mean serializing some sections of code, and if the tasks are too closely related, you end up running one thread at a time anyway.
In each of these cases, you also have to figure in the costs inherent in the use of threads (context switching, extra resources, etc). If the costs exceed the gains, then you're very likely to actually slow down as a result of threading.