我想知道当文件存储在.txt（Windows）或NTFS（Linux）中的本地硬盘驱动器上时，是否可以使用并行性加快读取{{1}}文件的速度）。是否可以并行化此任务以获得小于O（n）的跨度？
例如，如果我有一个8,000行的文件，并且我想计算文件中ext3/ext4的数量，我可以将它分成8个线程来读取行x， 1-1000，... 1001-2000并加入结果（即汇总7,0001-8,000）？我想有一个带磁盘I / O的瓶颈，但我找不到一个很好的解释为什么，或者是否有办法只使用一个O（n）工作的线程来读取文件？是否有一个我失踪的概念？
我们可以假设该文件位于本地存储上x或NTFS。另外，如果重要的话，我正在使用Java的fork-join框架。
答案 0 :(得分：1)
嗯，你正确地想象有一个带磁盘I / O的瓶颈。 A＆＃34;正常＆＃34; SATA磁盘可能具有大约100 MB / s的BW（用于顺序IO）。将其与当代x86处理器内核的算术速率进行比较，假设时钟速度为2.5 GHz，每个时钟上的指令数为2，真正的＆＃34;代码，可能或可能不接近现实，但应该在球场。因此，在从磁盘读取单个字节所花费的时间内，CPU内核执行大约50条指令[*]。除非您的比较例程效率极低，否则每个字节不会花费50条指令来检查＆＃39; x＆＃39;在一条线上。通过多个线程添加更多核心，这个比例变得更加不平衡。
其次，由于您正在谈论.txt文件，如果您想将其拆分为多个线程，您如何知道1001行的起始位置？哦，对，你按顺序扫描文件并计算换行数。对于并行处理，通常需要某种索引文件格式，因此线程/进程#N可以从文件的正确部分进行I / O操作，而无需从头开始线性扫描文件。
[*]如果你开始考虑随机I / O而不是顺序，它会变得更有趣。在7.2k磁盘上，磁盘搜索大约为10毫秒;在那个时候CPU核心执行大约50000000条指令！