为什么pthreads多线程代码比fork实现的多进程代码运行速度更慢？

1. 核心错误：时间统计函数使用不当 #

你使用的clock()函数的统计规则不符合测试预期：

• POSIX标准中，clock()返回的是进程累计占用的CPU时间总和，而非实际流逝的物理时间（墙上时间）
• 多进程场景下，fork()创建的子进程的CPU时间不会计入父进程的clock()统计结果，你看到的0.000秒级别的结果其实只是父进程创建子进程、等待子进程、读取pipe数据的CPU耗时，子进程执行求和逻辑的CPU时间完全没被统计，这就是多进程结果看起来异常快的原因
• 多线程场景下，同一进程内所有线程的CPU时间会全部累加到进程的clock()统计结果中。比如你开2个线程同时各跑1秒，clock()返回的总耗时是2秒，这就是为什么多线程耗时看起来比单线程还长的原因，本质是统计规则完全错误。

2. 正确的时间统计方案 #

如果你要统计实际执行的物理时间，替换clock()为clock_gettime(CLOCK_MONOTONIC, &ts)即可，示例代码片段：

#include <time.h>
struct timespec start, end;
clock_gettime(CLOCK_MONOTONIC, &start);
// 执行测试逻辑
clock_gettime(CLOCK_MONOTONIC, &end);
double time_used = (end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9;

也可以直接在终端用time ./你的可执行文件名运行程序，输出的real时间就是实际物理耗时。
修正时间统计逻辑后，多核环境下多进程、多线程的执行耗时都会明显低于单线程，且多线程速度会略快于多进程，符合你对轻量级线程的认知。

3. 其他非核心优化点 #

• 多线程场景下不需要用pipe传递结果，直接把结果写入传入的任务结构体，或者pthread_join时带回返回值即可，减少不必要的系统调用开销
• 编译时建议开启-O2优化，编译器会自动优化求和循环逻辑，测试结果更准确

内容的提问来源于stack exchange，提问作者devi_D