C++ 使用多线程的硬盘争用

我还没有对此进行任何概要测试，但是对于使用多个线程与使用一个线程从硬盘加载资源的优缺点，一般的共识是什么？注意。我不是在说主线

我会认为使用多个“其他”线程进行加载是毫无意义的，因为HD不能同时做两件事，因此肯定只会导致磁盘争用

不知道该走哪条建筑之路，感谢您的建议

编辑：抱歉，我的意思是SSD驱动器而不是磁驱动器。两者对我来说都是高清的，但我更感兴趣的是带有单个SSD驱动器的系统

正如评论中指出的，使用多线程的一个优点是，大文件加载不会延迟向线程加载程序的接收者呈现较小的for。在我的例子中，这是一个很大的优势，因此即使这样做需要一些性能，拥有多个线程也是可取的

我知道没有简单的答案，但我要问的真正问题是，与只允许1个资源加载程序线程相比，使并行磁盘写入顺序化（在操作系统层）会有什么样的性能损失？推动这一趋势的因素是什么？我不是说像平台、制造商等。我是说，从技术上讲，OS/HD交互的哪些方面会影响这种惩罚？（理论上）

进一步编辑： 我的确切用例是纹理加载线程，它只存在于从HD加载然后“传递”到opengl，因此线程中的“计算”最少（可能是一些类型转换等）。在这种情况下，线程将花费大部分时间等待HD（我想），因此，了解如何管理OS-HD交互非常重要。我的操作系统是Windows 10

注意，我不是在说主线

主线程与非主线程对读取磁盘的速度没有影响

我会认为使用多个“其他”线程进行加载是毫无意义的，因为HD不能同时做两件事，因此肯定只会导致磁盘争用

事实上，不仅尝试的并行读取被迫彼此等待（因此实际上不是并行的），而且它们还将使磁盘的访问模式变得随机，而不是顺序的，由于磁盘头寻道时间的原因，顺序的速度要慢得多

当然，如果要处理多个硬盘，那么为每个驱动器指定一个线程可能是最佳选择

---

现在，如果您使用的是固态驱动器而不是硬盘驱动器，情况就不那么清楚了。多线程可能更快、更慢或更具可比性。可能涉及很多因素，如固件、文件系统、操作系统、驱动器相对于其他瓶颈的速度等

---

---

在任何一种情况下，RAID都可能会使此处所做的假设失效。

很多人会告诉你，HD不能同时做多件事。这并不完全正确，因为现代IO系统有很多间接寻址。用一个线程很难使它们饱和

以下是我经历过的三个场景，其中IO有助于多线程

有时IO读取库的计算量非常大，可以考虑读取压缩视频，或者在传输发生后进行奇偶校验。一个例子是对多个线程使用

robocopy

。使用128个线程启动

robocopy

并不罕见

许多操作系统设计为单个进程不能使IO饱和，因为这会导致系统无响应。在一个案例中，我的读取速度提高了3%，因为我接近IO饱和。如果存在一些系统策略将数据分条到不同的驱动器，这一点是双重的，如可能设置的HPC集群中的Lustre驱动器。对于我的应用程序，最佳线程数为两个

更复杂的IO，如RAID卡，包含大量高速缓存，可保持HD磁头不断读写。要获得最佳吞吐量，您需要确保磁头在旋转时不断读写，而不仅仅是移动。实际上，唯一的方法是使卡的板载RAM饱和。

因此，很多时候，您可以通过使用多个线程来重叠一些较小的计算量，而使用更大的磁盘阵列则会变得棘手

不知道该走哪条建筑之路，感谢您的建议

---

确定每个线程的工作量是最常见的体系结构优化。编写代码以便于增加IO工作线程数。您将需要进行基准测试。

这取决于您将要执行的数据处理量。这将确定应用程序是I/O绑定还是计算绑定

例如，如果您对数据所要做的只是一些简单的算术运算，例如添加1，那么您最终将受到I/O限制。CPU向数据添加1的速度远远快于任何I/O系统传递数据流的速度

但是，如果要对每批数据进行大量工作，例如FFT、滤波器、卷积（我在这里选择随机的DSP例程名称），那么很可能最终会受到计算限制；CPU无法跟上拥有SSD的I/O子系统交付的数据

判断一个算法的结构应该如何与底层机器的底层功能相匹配是一门艺术，反之亦然。有一些评测工具，如FTRACE/Kernelshark、英特尔的VTune，这两种工具在准确分析正在发生的事情时都很有用。谷歌做了很多工作来衡量他们的硬件每瓦有多少搜索实现，电力是他们最大的成本

一般情况下，输入/输出