C++由于 CPU 类型的原因，Boost 多线程比单线程慢？
我之前发布过一些boost多线程。这次我只是好奇和失望，因为我认为多线程应该比单线程更快。
两个线程是 FILE I/O 读取/解析 CSV 数据。当我使用多线程时，每台 DELL DESKTOP OPTILEX 745 的 PENTIUM D CPU 平均需要大约 40 秒。
使用单线程时，同一台 PC 平均需要大约 8-10 秒。
我曾尝试使用这两个线程中完全不同的参数名称，结果没有什么不同。如果有人以前使用过c++ boost多线程来读取大数据文件并解析，我很想听听你的意见。谢谢。 安德鲁
I had posted some boost multithreads before. This time I just curious and disappointed because I thought multithreads suppose to be faster than single one.
Two threads are FILE I/O read/parse the CSV data. When I used multithreads, it took about 40 seconds average per machine PENTIUM D CPU from DELL DESKTOP OPTILEX 745.
With single thread, it took about 8-10 seconds average same PC.
I had tried to use completely different parameters name from these two threads, the result is no different. If someone had been used c++ boost multi-threads for reading big data file and parsing before, I would love to hear your opinions. Thanks.
Andrew
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果他们使用相同的文件句柄读取相同的文件，那么他们可能会花大部分时间等待其他线程完成。如果他们使用不同的文件句柄来读取同一个文件，他们就会迫使磁盘不断来回查找，这不像直接顺序读取那样有效。
线程不会加速大文件的读取和解析。它的作用是让您在读取和解析文件时完全执行其他操作。
您已经创建了 I/O 瓶颈，而线程对此无济于事。线程旨在当算法可以分解为独立的执行线程时减少 CPU 瓶颈；很大程度上依赖于先前输出的算法（文件解析是一种情况）通常不能很好地线程化。
如果您可以分解解析问题并让每个线程解析文件的不同部分，您可能会得到一点改进，但可能不会，因为搜索会浪费您的时间。如果您可以让一个线程执行批量读取和一些预处理，然后将块交给线程池进行真正的繁重处理（有吗？），那么您可能会看到比单线程有一些明显的改进。
这都是一般性的，有点意识流，但很难用你所付出的去做更多的事情。我希望它有帮助。
If they're reading the same file with the same file handle, then they might be spending most of their time blocked waiting for the other thread to get done. If they're using different file handles to read the same file, they're forcing the disk to keep seeking back and forth, which isn't as efficient an operation as a straight sequential read.
Threading doesn't speed up big file reading and parsing. What it does is let you do something else entirely while the file is being read and parsed.
You've created an I/O bottleneck, which threading does not help with. Threading is intended for reducing CPU bottlenecks when the algorithm can be broken into independent threads of execution; algorithms that have a lot of dependency on previous output (file parsing is one case) generally don't thread well.
If you can split up the parsing problem and have each thread parse a different part of the file, you might get a little improvement, but probably not since the seeking will be wasting your time. If you can have one thread doing bulk reading and some preprocessing, then handing off chunks to a thread pool for the real heavy processing (is ther any?), then you might see some noticeable improvement over single threading.
This is all general and a bit stream-of-consciousness, but it's hard to do much more with what you're giving. I hope it helps.
如果不看到代码，很难确切地说出发生了什么，但一般来说，多线程并不一定能为您带来更好的性能，而且实际上常常会导致明显的性能下降。
在您的情况下，如果您同时有两个线程读取和解析，那么它们可能会争夺 I/O，并且可能会争夺任何共享读/写内存区域周围的锁，这两者都会导致单线程运行速度减慢。线程版本不会有问题。
为了正确地做到这一点，您可能需要一个线程从文件中读取数据，另一个线程在数据进入生产者/消费者队列时解析数据。这将最大限度地减少锁争用（因为它只能通过等待者来实现），并确保您真正利用问题中可用的并行化。
话虽这么说，单线程版本可能仍然更快；情况经常如此。
Without seeing your code it's hard to say exactly what's going on, but in general, multiple threads don't necessarily get you better performance, and in fact can very often lead to obvious performance degradation.
In your situation, if you are having both threads read and parse, then they could be contending for I/O, and possibly the locks surrounding any shared read/write memory areas, both of which would introduce a slow-down where the single-threaded version would have no issue.
To do this properly, you would probably want a single thread reading from the file, and another thread parsing the data as it came in on a producer/consumer queue. This would minimize the lock contention (since it can be implemented with waiters only), and would ensure that you were acutally taking advantage of the parralellization available in your problem.
That being said, a single-threaded version might still be faster; it's often the case.