话说为什么大家会集中探讨GIL？在这里题主的标准线是一个按bit解决的单线程DFS啊……简直没有GIL施展的余地好么……
这个八皇后的DFS，我的C++代码在不加某些评估性剪枝的状况下对15须要算18s左右（开O2大概8.6秒，与题主形容基本一致），然而能够确定的是你的解决方案里用了循环与递归。接下来须要剖析的无非是Python慢在哪个细节，以及是否改良的问题。
上面是两段用来测试的代码，首先是Python的：
class=”highlight”>
<code class="python3">#!/usr/bin/env python3
import time
def calc(n, i=0, cols=0, diags=0, trans=0):
if i == n:
return 1
else:
rt = 0
for j in range(n):
col = 1 << j
diag = 1 << (i - j + n - 1)
tran = 1 << (i + j)
if (col & cols) == 0 and (diag & diags) == 0 and (tran & trans) == 0:
rt += calc(n, i+1, cols | col, diags | diag, trans | tran)
return rt
if __name__ == '__main__':
t = time.time()
print(calc(13))
print(time.time() - t)
以及C++代码：
#include <chrono>
#include <iostream>
using namespace std;
long calc(int n, int i = 0, long cols = 0, long diags = 0, long trans = 0) {
if (i == n) {
return 1;
} else {
long rt = 0;
for (int j = 0; j < n; j++) {
long col = (1 << j);
long diag = (1 << (i - j + n - 1));
long tran = (1 << (i + j));
if (!(col & cols) && !(diag & diags) && !(tran & trans)) {
rt += calc(n, i + 1, col | cols, diag | diags, tran | trans);
}
}
return rt;
}
}
int main() {
auto t = chrono::system_clock::now();
cout << calc(13) << endl;
cout << (chrono::system_clock::now() - t).count() * 1e-6 << endl;
return 0;
}
这里的C++代码没依照OOP去写，怎么简略怎么来吧……
测试机器配置是Core i7 4870HQ，编译器用的Clang++ 8.1.0，Python解释器则是CPython 3.6.0。没测试15的数据量只测试一下13，因为15太费时间了……
因为这里压根不波及多线程问题，那基本上就跟GIL没有半毛钱关系了。
对于n=13，C++代码跑了0.48秒。为了确保不是编译器轻轻干了活，我顺便打成了-O0（实际上开O2能到0.2秒左右）。Python跑了24秒。
对于这个例子，最间接的影响其实在于：Python是逐句解释执行的，C++是先编译成本地代码，期间还有编译期的类型查看，不存在动静类型、动静查看，并且能够进行编译器优化。
之后应该考虑一下能不能进步一点点效率呢？
而后依据个别法则，Python的循环很慢，咱们能够思考改成列表开展：
<code class="python3">def calc(n, i=0, cols=0, diags=0, trans=0):
if i == n:
return 1
else:
return sum(
[
calc(n, i + 1, cols | (1 << j), diags | (1 << (i - j + n - 1)), trans | (1 << (i + j)))
for j in range(n)
if (cols & (1 << j)) == 0 and (diags & (1 << (i - j + n - 1))) == 0 and (trans & (1 << (i + j))) == 0
]
)
理当速度更快，实时也验证了：这样的Python代码须要跑18秒左右。依然存在数量级的差别，并没有解决基本问题，然而阐明了一点，CPython中for loop的实现其实一点都不快。
而后考虑一下，如果咱们应用其它解释器，特地是蕴含JIT的解释器，它将在执行过程中尝试将代码编译成本地二进制编码并执行，同时还能赋予一些额定优化，会不会好很多？
那么单纯地尝试一下PyPy3(5.8.0-beta, Python 3.5.3)，代码能有多快？
实际上，单纯的只是替换一下解释器，换成PyPy来做的话，本来这个24s的Python源码就只须要1s左右了。单单一个JIT能够使得性能晋升一个数量级，充分说明官网的CPython解释器的性能真心很烂……
PyPy的JIT比较简单纯正，并不是很激进，然而同样的代码如果能借助更好的JIT，以及更高性能的库，则能够体现出齐全不同的性能差。例如，如果应用llvm做JIT，同时加上能应用一些成熟的数学库做优化。咱们晓得NumPy这样的C扩大可能很大水平进步Python做数值计算的性能，同样的咱们也能够用Cython或者间接用C写Python扩大来强化计算能力。然而人都是懒的，从新写代码切实是有些麻烦。对于Python这种生态弱小的玩意来说，如果你的计算代码中只是单纯的应用了numpy的简略构造以及Python本身的规范构造，应用numba可能是最简略疾速的方法。
<code class="python3">#!/usr/bin/env python3
import time
from numba import jit
@jit
def calc(n, i=0, cols=0, diags=0, trans=0):
if i == n:
return 1
else:
rt = 0
for j in range(n):
col = 1 << j
diag = 1 << (i - j + n - 1)
tran = 1 << (i + j)
if (col & cols) == 0 and (diag & diags) == 0 and (tran & trans) == 0:
rt += calc(n, i+1, cols | col, diags | diag, trans | tran)
return rt
if __name__ == '__main__':
t = time.time()
print(calc(13))
print(time.time() - t)
这里只是很简略地退出了两行代码：从numba导入jit，用jit装璜咱们的计算函数。这段代码的运行工夫间接就缩短到了0.4s，和C++版本的O0编译后的程序速度简直一样。这还是思考到JIT须要预热的状况在内。这段代码，若是计算15的规模，只须要6.5s左右，甚至优于开O2的C++版本。
究其原因，JIT不仅仅在运行过程中将代码转为本地机器码，同时还会尝试进行优化。如果用cProfile之类的玩意剖析一下运行过程，能够分明看到这个优化过程。
本次分享就到这啦,如果对您有帮忙，麻烦点个赞和关注再走喔~谢谢浏览。
转载请注明原文链接：关于python:为什么Python比C慢很多
