@sagaxu 这无所谓的啦，这种用词我不太在意的。这楼一直在说加锁的事情，那并发（单线程）不用加，但是 1C1T 并行（多线程）就得加。而且你得和他解释为啥 1C1T 这也算并行，有些人还觉得 1T1C 同一时间只有一个线程在跑，不算并行嘞。

所以我都不在意这些用词了。就怕半桶水只知道这种用词，而不知道背后到底具体是什么场景。

@sagaxu 现代操作系统是时间片复用的并行操作系统。也就是说你一个线程比如 PyList_Append 做了一半，操作系统可能就会把这个线程停下来，换另一个线程去执行。因此 1C1T 也有并行，也要加锁。P.S. 这种停下来靠 CPU 硬件中断信号。

@Jirajine yysy qs，解决 GIL 只能靠砍掉 C 模块，拥抱 JIT/VM 。但那就不是 Cython 应该做的事情了。

@neoblackcap @LeeReamond

比如：

https://zhuanlan.zhihu.com/p/192974017

pybind11，C++ 与 python 互相调用的一个库。

你 C++ 可以有自己的 pthread 线程，甚至用上 uvloop 来做事件驱动，然后控制权可能又进入 python，然后又重新回到 c++。在 C++ 里面如果有多个 pthread native 线程，根本不归 python 管，同时去访问 PyList_Append，这就是 Python 无与伦比的自由度，也是它作为胶水语言的优势，但是也造成了 GIL 尾大不掉。

@LeeReamond 或者你可以实现自己的一套引用计数（仿照 C++ std::shared_ptr，直接在你的 struct XXXObject 内部嵌入一个 Py_Object*，在你自己的引用计数清零的时候去调用 python api 清理掉这个 python 对象）。

换句话说，Python 变成了 API，C++ 才是本体。。。从 C/C++ 代码角度看就是这样。

@neoblackcap 不，tracing gc 前提是有 vm 啊。

但是 python 在 c 扩展方面自由度太大了，根本做不了 vm 啊。。。
====


@LeeReamond 你理解错了，我指的不是 ctypes cffi 这种 C 扩展，而是直接在 C/C++ 项目里面 link python.dll ，主体是 C/C++ 的代码。你甚至可以在 C/C++ 里面直接 Py_ListAppend，或者调用某个对象的 __call__

@LeeReamond ……接楼上。

如果 Python 一开始就决定没有 GIL，那么每个 C 扩展库作者必须知道每个版本的 Python 内部的操作是怎么回事，小心地去处理每一次和 Python 对象的打交道。这个心智负担就太重了。肯定不能完全依赖于 C 扩展库的作者。

Java/C# 因为有 VM 所以可以大大简化这里的问题，但是 Python 因为允许完全不受管理的 C 扩展所以。。。GIL 是当年和现在都最容易的选择，也是现在很难解决的问题。

@LeeReamond 参见楼上 “如果 C 扩展要显式释放 GIL，那么该扩展就需要自行保证线程安全”

…… 所以其实 Python 成也“胶水”败也“胶水”。C 扩展库能这么容易访问 Python 底层的东西是个优势，可以迅速做一些系统层面的 API 调用、融合 C/C++ 做科学计算（ PyTorch，NumPy，或者 GPU 计算），或者在暴露 C/C++ 写的核心算法为 HTTP API 。但是同样的，这个优势也让 Python 在普通的多线程网络服务器上寸步难行。

我的看法是，Python 干好科学计算这方面的事情就行了。还有就是干好工具型胶水语言该做的事情，在性能无关的领域放光（比如运维）。科学计算本来就计算密集型，本来就要独占核心一直跑，根本不会有线程上下文切换。网络服务交给专业的，比如 Go，Java，C++ 什么的。多好。。。

说的更明确一些：哪怕 C 扩展库对自己的逻辑进行了加锁，但是由于要访问 Python 对象，进一步使用 Python 解释器的东西，它防止不了外面的代码同时访问相同的对象，然后就崩溃了。。。

所以面对 C 扩展库，GIL 喊了这么长时间都搞不掉。

1. Python 解释器层面的一些锁。这个其实想要优化总能优化的。
2. 保护 C 扩展模块，这方面是挺蛋疼的。

Python 生态半壁江山是 C 扩展库撑起来的，丢掉这部分江山等于自废武功。为了支持无锁而去掉 GIL 等于丢掉所有这些库，做网络应用的是爽了，但是 Python 就分裂了。

lz 可能不知道，北京上海的平均工资不到 1 万，更别提中位数了

@missder @chaowang C++ 的一些评论见我上面的楼。

另外编辑器的问题，我觉得是作者设计上和实现上偷懒了。C++ 最快的写法写起来还挺累人的，各种奇迹淫巧那不是炫技，而是用了就比 C 快，不用就比 C 慢很多。我写 C++ 经常不开优化比开优化慢 5 ～ 10 倍。

另外面向优化写代码必须消除 warning，任何 C++ 标准未定义行为都要绕道走。网上不也很多段子，什么什么公司的代码一开优化就崩溃么 2333 。

@pkookp8 C++ 追求的 zero-cost abstract，template 大法超级给力。

举个例子，std::sort(vec.begin(), vec.end(), [&](const auto& lhs, const auto& rhs) { return lhs < rhs; });

这里的比较器直接被 C++ 编译器内联了（开 -O2 ）。如果是 C 语言版本的快排：

bool fn(const void* a, const void *b)
qsort(..., &fn);

函数指针丢进去。除非给每个函数写特殊规则（比如 qsort 是库函数说不定还有机会），一般函数根本没有内联优化的可能性。

====

再比如 C++ 17 的各种骚操作，例如：

inline constexpr size_t pow2(int n) { return n == 0 ? 1 : 2 * pow2(n-1); }

...

template <int N>
if constexpr (pow2(N) > 1024) {
... branch A
} else {
... branch B
}

这段代码，pow2 和 constexpr 都是编译期就确定的行为，不会在运行时计算。

@AllenHua 2333 原来是直出，那只能佳能了。

你比如我，一般都后期的。（说实话调个色也就五分钟十分钟）。索尼大法的宽容度实在是好啊，有一天我拿着 a7r4，旁边另一个人拿着佳能不知道哪一款反正不是最近的，然后 ido 是室外漫展，光比强烈。然后。。。他发现他相机不行了。

近十年是互联网 /程序员红利。程序员这种和教师、医生不一样，是没有绝对鉄饭碗的。

其实 Python 做数据分析，性能绰绰有余了。。。

你说要性能？我看了看这两个月写的 2 万多行 C++