C程序比Python子进程更快

scr*_*cry 11 c python benchmarking subprocess

我在C中有一个多线程mergesorting程序,以及一个用0,1,2或4个线程进行基准测试的程序.我还用Python编写了一个程序来进行多项测试并汇总结果.

奇怪的是,当我运行Python时,测试总是在大约一半的时间内运行,而不是直接在shell中运行它们.

例如,当我用400万个整数运行测试程序进行排序时(最后两个参数是生成整数的种子和模数):

$ ./mergetest 4000000 4194819 140810581084
0 threads:  1.483485s wall;  1.476092s user;  0.004001s sys
1 threads:  1.489206s wall;  1.488093s user;  0.000000s sys
2 threads:  0.854119s wall;  1.608100s user;  0.008000s sys
4 threads:  0.673286s wall;  2.224139s user;  0.024002s sys
Run Code Online (Sandbox Code Playgroud)

使用python脚本:

$ ./mergedata.py 1 4000000
Average runtime for 1 runs with 4000000 items each:
0 threads:   0.677512s wall;   0.664041s user;   0.016001s sys
1 threads:   0.709118s wall;   0.704044s user;   0.004001s sys
2 threads:   0.414058s wall;   0.752047s user;   0.028001s sys
4 threads:   0.373708s wall;    1.24008s user;   0.024002s sys
Run Code Online (Sandbox Code Playgroud)

无论我排序多少,或者我运行多少次,都会发生这种情况.python程序使用子进程模块调用测试程序,然后解析并聚合输出.有什么想法会发生这种情况吗?Python以某种方式优化执行吗?或者当我直接运行它时,有什么东西会减慢它我不知道的?

代码:https://gist.github.com/2650009

scr*_*cry 2

结果我将 sys.maxint 传递给子进程作为生成随机数的模数。C 截断了 64 位整数并将其解释为带符号的,即二进制补码中的 -1,因此每个随机数都被它取模并变成 0。因此,对所有相同的值进行排序似乎需要大约一半的时间很多时间作为随机数据。