是并行File.Read快于顺序读取？

我只是想知道使用PLINQ/Parallel可以更快地平行File.Read吗？我的代码如下所示（.NET 4.0）：是并行File.Read快于顺序读取？

public static void ReadFileParallel(List<string> fileName) 
{ 
    Parallel.Foreach(fileName, file=>File.Read(file)); 
} 

public static void ReadFilePLINQ(List<string> fileName) 
{ 
    fileName.AsParallel().foreach(file=>File.Read(file)); 
}

我问这个是因为我认为这个文件读取IO束缚的原因，这样做平行不会帮助，是吗？

来源

2010-07-13 Graviton

这取决于。

如果您的文件位于不同的位置，不同的网络共享或不同的物理硬盘上，那么是的，并行加载可能会有所帮助。如果他们使用单个旋转硬盘驱动器，并行读取文件可能会严重影响您的性能，因为您可能会因这些并行读取而导致额外的搜索时间。

如果您的文件位于SSD上，您的性能可能会稍差，但这取决于您并行读取的文件数量以及它们的大小。我想象一下，在一定的文件大小阈值和并行读取次数下，性能会显着下降。很难告诉那个没有实验的人。

来源

2010-07-13 14:07:49

这些都是合理的标准。但在实践中，我会说测量它而不是猜测。 – 2010-07-13 14:09:24

有一个来自MSFT的优秀PDF，详细介绍了并行和线程的可能性。

它可能有帮助。

http://www.microsoft.com/downloads/details.aspx?FamilyID=86b3d32b-ad26-4bb8-a3ae-c1637026c3ee&displaylang=en

来源

2010-07-13 14:06:53 keyle

你会这样想，但那不是测量结果显示的。当文件I/O具有严重延迟时（尤其是通过网络）时，并行处理可以保持管道充满。

来源

2010-07-13 14:08:24

如果文件位于不同的磁盘上并且使其速度变慢（由于花费更多时间寻找），第一个近似值将有所帮助。

如果所有文件都被缓存（因为您可以使用多个核心），速度可能会稍快。

你最好的选择是运行一些基准测试。

来源

2010-07-13 14:08:39

你并不是正在做一个并行的File.Read，你正在并行地执行多个File.Reads。如果这些文件位于不同的主轴上，只需一次使用多个主轴，就可以提高吞吐量。

即使您使用单个主轴，如果每个Read之后都有CPU绑定处理，您也可以体验到改进的性能，但在这种情况下，对任务对象进行调度会更好。在这种情况下，您可以有一些任务从文件加载数据，而另一些则使用已加载的数据来执行一些繁重的处理。

来源

2010-07-13 14:11:43

是的，但是如果他的文件在同一个硬盘上，他就会打到头部搜索时间，吞吐量会下降2倍。请记住，3.5英寸7200 RPM驱动器的平均寻道时间为13-15毫秒，与容量和线性读写速率不同，这个数字在过去几年中是一致的 – Soonts 2010-07-13 14:23:47

这就是为什么我说“每次读取之后CPU绑定处理“，当一个线程正在读取文件时，另一个线程正在处理中，因此两个线程都处于工作状态。 – 2010-07-13 17:36:02

我认为你已经在这里碰到了头。

并行操作一般总是受限于资源用尽并行运行操作的点，但即使如此，在并行线程数量不断增加的情况下，您仍然会减少回报。

Jeff Atwood在推特上发布了一张有趣的图表，我将在后面添加一个有趣的图表，展示多线程环境下多核处理器的收益递减。当然，这不完全相同。但是让我们从这个想法来看待这个问题，即使100个硬盘驱动器上有100个文件，IO的某个地方也会降低到单个通道，这会导致读取增加量减少。

我基本上试图说的仅仅是并行运行并不意味着它会大幅加速，重要的是要考虑并行进程是如何实际执行的。

来源

2010-07-13 14:15:05 msarchet

这是棘手的业务。如果你做错了，磁盘头会来回移动，试图同时读取两个文件。这尤其是对大文件的一个问题。

但是，如果您并行读取大量小文件，则可能会稍微增加一点，因为磁盘子系统可以选择以不同于您询问的顺序读取文件。但是，在现实生活中我没有看到这种效果。

同时处理你对内容的处理可以与读取文件并行完成。因此，您需要在发货之前进行配置和基准测试。

来源

2010-07-13 14:25:38

是并行File.Read快于顺序读取？

回答

相关问题