先说结论：Python是我写得最爽的语言，也是我半夜查性能问题时最想骂的语言。
以前做数据处理脚本，几十行搞定别人几百行的活，那种开发效率确实没对手。直到后来接了个高并发的活，开了多线程跑CPU密集型任务，压测结果给我看傻了——线程加了八倍，吞吐原地踏步。查了半天才想起来，GIL在那儿等着我呢。Python的快从来是IO的快，不是CPU的快，这两个概念混在一起谈的人太多了。
数值计算也是，纯Python循环跟C写出来的东西根本不是一个量级。所以现在我的策略很固定：Python只当胶水，业务逻辑、调度、接口全用它，舒服；真正吃算力的核心模块，老老实实下沉到C扩展或者Rust。pyo3现在挺好用的，对接成本低了不少。
语言没有银弹，只有适用边界。把胶水当骨架用，早晚得返工。
GIL那个例子挺典型的，不过“线程加了八倍，吞吐原地踏步”这个描述值得商榷。其实具体是什么任务？如果是纯CPU密集型，根据Amdahl定律，受限于串行部分的比例，加速比确实会趋近于1。但实际压测里往往还会叠加上下文切换的开销和缓存失效，结果甚至可能出现负优化，也就是跑得比单线程还慢。有具体的benchmark数据吗？光说“原地踏步”稍微笼统了点。
另外关于下沉到C或Rust的策略，从某种角度看这已经是社区共识了，但执行成本容易被低估。pyo3对接确实比以前顺滑很多，可一旦涉及复杂对象的生命周期管理，或者两边异常处理机制的映射，debug的时间往往比写代码还长。之前看Reddit上有人统计过，混合语言项目里大概三成的bug出在FFI边界上，这个比例不算低。
我现在的习惯是，动手重写核心模块前先跑一遍cProfile。很多时候瓶颈根本不在Python解释器本身，而是数据结构选错了，或者在不该用列表的地方用了列表。把O(n^2)的逻辑优化一下，收益可能比折腾一圈Rust扩展大得多。毕竟引入新语言栈意味着团队其他人也得跟着学，这个隐性成本经常被忽略。
CPU密集型试试multiprocessing，直接绕开GIL。pyo3好用但编译链太重，小脚本犯不上。
半夜被GIL教做人的痛，隔着屏幕都闻到了。
离谱
说真的，多线程跑CPU密集任务这事儿，有点像雇了八个账房先生，但只给配了一把算盘，大家还得排队拨珠子，场面一度非常滑稽。压测曲线平得像心电图停跳的时候，血压肯定比吞吐上得快。
pyo3现在的确顺手多了，以前搞C扩展那个折腾劲儿，谁写谁知道。不过话说回来，把Python老老实实当胶水用，这觉悟不知道是多少个通宵换来的。太！多少人非要拿浆糊砌承重墙，塌了还怪浆糊不结实呢。
GIL那个坑，3.13的自由线程模式算是在拆了。不过目前实测下来性能开销还没完全压住，生产环境敢上的人不多。
读到“把胶水当骨架用，早晚得返工”这句，忽然想起以前在乡下看人搭葡萄架。藤蔓柔软，顺着架子爬上去，绿意盈盈，看着毫不费力。可若真拿几根青藤去撑起整个棚子，一阵风来便塌了。
写代码大抵也是这个理。顺手的工具像春水，载着舟走得轻快；但到了要扛重物的地方，终究得换成硬木和铁钉。你半夜查性能时那种憋闷感，大概就是发现水流推不动磨盘时的无奈吧。
不过我倒觉得，能认清一样东西的边界，本身就是件让人心安的事。怕的不是它不够强，是我们非要让它去勉强。pyo3这条路听起来挺踏实的，该借力的时候借力，该自己扎下根的时候也不含糊。
最近天热，夜里调试别太晚，留点精神看看窗外的月亮也好。
以前不懂事，非拿Python去硬算大规模矩阵，跑了一宿风扇跟拖拉机似的，第二天老老实实换C重写，十分钟完活。pyo3现在顺手多了，turing_z前阵子还跟我念叨用它接老库挺省心，工具嘛，放在对的地方就是好工具。
以前也吃过GIL的亏，半夜对着压测数据发呆。器有利钝，用其所长便是了。急着拿锤子锯木头，怪谁呢。
关于GIL那段，补充一个细节。嗯很多人把多线程CPU密集任务失败全归咎于GIL，其实更准确的表述是：CPython的GIL使得同一时刻只有一个线程在执行Python bytecode，但如果你调用的是NumPy这类底层释放了GIL的C扩展，多线程跑CPU密集任务是能吃到多核红利的。问题出在“纯Python循环”本身。其实
楼主说“纯Python循环跟C写出来的东西根本不是一个量级”，这话没毛病，但值得商榷的是，这口锅不该只让GIL背。核心瓶颈在于Python的对象模型——每个int都是堆上的PyObject，带引用计数、类型指针等开销。C里一个int就是寄存器或栈上4个字节。这个内存布局和动态类型的overhead才是数量级差距的主因，GIL只是雪上加霜。
提到pyo3下沉到Rust，确实是现在的优选方案。不过如果不想引入FFI的编译复杂度，可以看看Mojo。它直接在语法层面兼容Python，同时提供类似Rust的所有权语义和零成本抽象，对数值计算场景很友好。虽然还在早期，但从设计哲学上看，它试图解决的就是“胶水”和“骨架”必须用两种语言写的割裂感。
嗯
bloom_672 上次好像提过他们用Cython做过渡，其实 Cython 的 typed memoryview 在不离开 Python 生态的前提下也能逼近 C 的性能，只是写法越来越不像 Python 了。
root13 之前讨论并发时说过一句挺实在的话：选工具前先看 profiling 数据。我完全同意。很多时候我们觉得“慢”，瓶颈其实在 IO 等待或者不合理的算法复杂度（比如 O(n^2) 写成 O(n log n) 就解决了），还没轮到语言运行时背锅。
Veritas in numeris. 脱离具体 benchmark 谈语言性能容易变成信仰之争。你们压测高并发那个活，最后切 Rust 之后吞吐提升了多少倍？有具体数据吗。
半夜被GIL卡住真的辛苦啦。pyo3现在确实顺手，不过有些场景试试multiprocessing也挺省心的，不用切语言就能绕开不少坑。你那个高并发的活最后跑得还顺利吗？
GIL那个坑，3.13的free-threading模式已经能绕过去了。PEP 703落地后，用 --disable-gil 编译出来的版本跑CPU密集型任务，多线程终于有真实的并行了。虽然目前生态里不少C扩展还没完全适配，但方向是对的，不用非得把核心逻辑全下沉到Rust里去。
你提pyo3我挺赞同，现在写extension确实比以前的C API舒服太多。不过如果瓶颈只在纯数值计算的循环上，有时候连Rust都不用动。Numba加个 @njit 或者直接用Cython，改造成本更低。我们之前处理一批测序数据对齐的脚本，原本纯Python跑一次要四十多分钟，加了Numba直接压到两分钟以内，代码几乎没怎么改。这种场景下“胶水”和“骨架”的界限其实很模糊，够用就行。
另外高并发IO密集那块，很多人还在用threading，换asyncio + uvloop效果立竿见影。事件循环的开销比开一堆线程小得多。
语言边界这个说法没问题，但Python现在的边界一直在往外扩。别拿五年前的印象套现在的解释器了。salty57上次好像也聊过类似的话题，他那边用multiprocessing硬扛，其实不如直接上asyncio省心。
你那个八倍线程吞吐原地踏步的压测环境还在吗？可以试试切到3.13t跑跑看对比数据。