这是因为multiprocessing在后台需要在主进程和工作进程之间进行进程间通信，并且通信开销比x * x您实际情况中的“实际”计算（）花费了更多的时间。
尝试使用“较重”的计算内核，例如
def f(x):
return reduce(lambda a, b: math.log(a+b), xrange(10**5), x)
我指出，OP观察到的cpu使用率低是由于其固有的IPC开销，multiprocessing但是OP不必为此担心太多，因为原始的计算内核太“轻”了，无法用作基准。 。换句话说，multiprocessing通过“太轻”内核的这种方式工作最差。我保证，如果OPx * x在之上实现现实世界的逻辑（我敢肯定，这会比“更重” ）multiprocessing，那么OP将实现不错的效率。我的论证得到了我提出的“重”内核的实验的支持。
@FilipMalczak，我希望我的澄清对您有意义。
顺便说有提高效率的一些方法x * x同时使用multiprocessing。例如，Pool除非需要实时解决每个作业，否则我们可以将1,000个作业合并为一个作业（例如，如果您实现REST API服务器，则不应该这样做）。
602392714
清零编程群