读取大文件时是否消耗CPU?

这取决于硬件的配置方式。通常,由于 DMA . 但是,如果它从其他应用程序中启动交换,可能会非常昂贵。但还有很多。

如果可以的话,不要立刻读取大文件

如果你的文件真的很大,你应该使用 mmap 或者顺序处理,当您不需要同时读取整个文件时。试着分块消费是可能的。

例如,要对一个大文件中的所有值求和,不需要将该文件加载到内存中。你可以用小块来处理它,把总数加起来。在大多数情况下,内存是一种昂贵的资源。

读取是连续的

文件读取操作是否需要消耗1个核心?

是的,我认为大多数低级读取操作都是按顺序实现的(消耗1个核心)。

如果使用 asynchronous I/O 但它只是同一种“小块读取”技术的变体。您可以一次启动几个小的异步读取操作,但在使用结果之前,您必须始终检查操作是否已完成。

也见此 Stack Overflow answer 相关问题)。

并行读取和计算

以前我只创建两个线程,一个用于读取文件,一个用于计算?我应该创建一个额外的线程来进行计算吗?

这取决于,如果您需要所有数据来开始计算,那么就没有理由并行开始计算。它必须有效地等待直到阅读完成。

如果您可以开始计算,即使是部分数据,可能不需要一次读取整个文件。通常情况下,最好不要使用大文件。

您的瓶颈计算或IO是什么?

最后,您应该知道您的任务是计算界限还是输入输出界限。如果受输入输出子系统性能的限制,并行计算几乎没有什么好处。如果计算占用大量CPU,而读取时间可以忽略不计,则可以从并行计算中获益。输入输出通常是一个瓶颈,除非您正在进行一些数字处理。

这是一个很好的并行化候选者,因为这里有两种类型的操作——磁盘I/O(用于读取文件)和CPU负载(用于计算)。所以第一步是编写应用程序,这样文件I/O就不会阻塞计算。您可以通过一次从文件中读取一点并将其传递给计算线程来实现这一点。

但是现在你说你有两个核心想要利用。您关于并行化CPU密集型部分的第二个想法是正确的,因为只有在有多个处理器可供使用的情况下,我们才能并行化计算任务。但是,在这种情况下,应用程序的阻塞部分仍然是文件I/O—这取决于许多因素,唯一判断并行化级别合适的方法是进行基准测试。

所以需要注意的是:多线程处理很难,而且容易出错,如果您只能选择一个,那么拥有正确的代码比快速的代码更好。但我并不主张反对线程,正如您在网站上从其他人身上看到的那样。

我认为这取决于你正在执行的计算。如果您正在进行非常繁重的计算,那么我建议对应用程序进行线程处理。读取一个文件对CPU的要求很低,因此,通过线程化应用程序产生的开销可能会降低速度。

另一个需要考虑的问题是,如果需要在计算之前加载整个文件,如果需要,那么根本就没有线程化的必要,因为在执行另一个操作之前必须完成一个操作。