这是因为
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通过“太轻”内核的这种方式工作最差。我保证，如果OP
x *x在之上实现现实世界的逻辑（我敢肯定，这会比“更重”
）
multiprocessing，那么OP将实现不错的效率。我的论证得到了我提出的“重”内核的实验的支持。
@FilipMalczak，我希望我的澄清对您有意义。
顺便说有提高效率的一些方法
x *x同时使用
multiprocessing。例如，
Pool除非需要实时解决每个作业，否则我们可以将1,000个作业合并为一个作业（例如，如果您实现REST
API服务器，则不应该这样做）。
