请原谅我使用“级别”这个词，但我不确定还有什么可以称之为“级别”。我正在写一个游戏引擎。该游戏引擎加载了操作所需的许多文件。这些文件主要是归档文件，其中包含大量文件。这些文件分别分为zlib压缩块。
我的问题是我应该在哪个级别实现多线程？
为了论证，让我们说：
15个存档文件（每个10mb）
每个档案中的20个文件（0.5mb）
每个文件由数百个压缩块组成。
我意识到如果我在块通胀水平上做到这一点，它会均匀地分配任务，如果有一个非常大的文件就没有瓶颈。但是我冒着创造太多线程的风险。
编辑：我应该澄清，我理解来自磁盘的多线程I / O并没有太多帮助。对于我的问题，我主要询问在不同级别处理和解析这些文件。想象一下，I / O已经处理好了，我只是担心解析这些文件。
答案 0 :(得分：3)
如果您的代码是I / O绑定到单个磁盘驱动器，那么多线程可能会适得其反。您需要确定程序读取文件所需的时间以及处理数据所需的时间。
如果大部分时间都用于从磁盘读取数据，那么多线程不会对你有所帮助。
如果大部分时间用于数据处理，那么每个核心1个线程是一个很好的经验法则，但是您应该将读取部分留给单个线程，并将处理部分保留到1个线程的池中每个代码（即单一生产者 - 多个消费者设计）。
答案 1 :(得分：2)
当您的工作单元太大/太粗时，您可能不会使所有CPU饱和，或者在处理最后一项时，某些CPU可能处于空闲状态，等待缓慢的项目完成。
当工作单元太小时，分配工作和合并结果的开销太大。
通常，最快的方法是使用从开销角度来看可接受的最小尺寸/级别。
在架构上，在更高级别执行并行操作通常更容易，因为您可以一次性自动并行化调用图的整个子树。
这些是权衡取舍。您需要根据自己的具体情况自行决定。听起来像文件级并行化是正确的方法。它为您提供15 * 20 = 300个工作项，通常分布在4-8个核心之间。这是一个很好的分配比例。
答案 2 :(得分：0)
作为一般规则，不要运行比逻辑cpus更多的线程。你不能加快速度而只是引入开销。
除非你有一些需要更专业处理的特定情况，否则我建议只创建一个线程池（执行器== cpus的数量），然后为每种情况创建一个运行/调度程序 - 一个用于安排归档为作业，然后将文件作为作业。选择性能更佳的解决方案。
如果不确切知道你的代码是什么样的，我怀疑你能得到更明确的答案。
答案 3 :(得分：0)
如果我理解你的问题，你会问你是否应该为每个档案文件或档案中的每个文件使用线程，甚至更低？
如果就是这样，我认为我们不能给你一个答案。首先，您需要多线程吗？你给出的数字并不令人印象深刻，看起来它应该只用一个线程运行得足够快。
如果没有，我会建议您实现最简单的多线程级别，即最高级别（对于每个存档文件），并再次查看是否需要更高的性能。
如果是，请执行其他级别并进行衡量。事先知道的因素太多了。如果没有，你可以继续工作： - ）