@FrankHB 好吧，文件流……以上作废。首先 Debug 没啥可比性就不用管了（调_ITERATOR_DEBUG_LEVEL 和_GLIBCXX_DEBUG 也不能指望半径八两）。然后……噫，这些环境的外部变量太多，还是没啥可比性啊……

没 sync_with_stdio(false)纠结啥性能……是想看 cstdio （无误）实现得有多蠢么……

@wizardforcel 你还是没跳出套。
假设只侧重于某种性能，不依赖于另一种性能，让性能在整体上看起来不成问题，这没啥大不了的。（或者说，算是分析过了一些需求，应当赞赏？不过我觉得这是份内义务劳动……）
但一个怎么看实际上都已经通用过头的语言还用这种手段掩饰设计问题就流氓了点。
通用语言当然不是指面面俱到。一般来说通用语言需要满足不特定领域专业用户的期望，其中之一体现在工作得明显不够好的领域自觉退让，而不是赖着“能用”留下一坨不成熟可靠的解决方案，增加该领域用户的本不必要的选型成本。
技术上来讲通用和不通用没有很明确的界限，更多体现在设计者的表现的意图以及实际上扩散到了多少应用领域上并且流行了。对比一下， SQL 能干的活也挺多的，但还算是比较老实当 DSL 而不是到处刷存在感，所以姑且没有那么大问题。
当然 Python 某种意义上表现突出也不算一定就烂（其实光看技术方面的问题并没有某些 SQL 方言严重），可以用有足够相似点的实例对比来偷懒地洗。
比如你可以拿某些 Ruby 实现在某些主流性能指标上给 CPython 垫背，妥妥地。

最后，之前围绕展开的是你的其中部分观点，和 Python 其实关系不大，只是主题的关系顺便拿来当例子（虽然也不算躺枪）；换其它多数语言，上面很多部分也适用。这倒是正好说明了某些观点对语言设计者存在普遍的危害，所以有必要澄清。

@wizardforcel 我看到你要提的合理性就是工程上需要 trade off 以及性能需求不总是第一位的，这点很简单，不用那么漏洞百出的论调来复杂化和削弱可信性。

我旗帜鲜明地反对的是不分析性能需求的外延就主张放弃性能。只要能保证按照约定的质量按时交付，对性能吹毛求疵好歹对最终用户没有损害；而不仔细分析拿性能当妥协，很难保证不损害用户（本来理当享有）的利益。一家两家这样做没什么问题，但当这样成为业界主流时，不兼职开发的用户就只能挨宰了。这显然不是应该提倡的情形。

注意分析清楚保证没有 false negative 的性能缺陷实际上几乎总是很困难的（换句话说，即便是约定清楚了指标，你也不太可能让性能恰好降低到符合要求而腾出资源让位给其它需求），所以优先强调性能是一种保守（尽管可能低效以及同样反智）的工程策略。

这种主张有一些庸俗版本的说法，其中有不止一个问题。比如说，“计算资源过剩”——同时忽略了背景以及不同计算资源基本上很难全面过剩（真全过剩了用户算是一定意义上活该）的事实。

“服务器”的问题你刚好理解反了。我的意思是服务器（准确地说也不是所有服务器）常常恰好不关心某一种“性能”，所以写惯了服务器应用的开发者往往在这里少根筋。

具体说来，像 Web 服务器应用，同样是性能需求，吞吐量通常远远重要于交互操作的响应。这使得使用 STW 的 GC 作为一种优化是可以被接受的。但是有些人基于某些理由不顾性能需求的差异，就 yy 这样的场景同样适合于其它领域，把选型策略无条件上升到方法学；甚至不惜直接代替用户决策来保证系统可用性。

当然，大部分客户端的响应其实也并不是非常高，分时系统是可以接受的。但是实际用起来如何呢？当市面上主流产品没法保证不堆硬件就不损害日常体验，是不是反省是谁该给原则错误买单了？

嗯，上面婊的是 Java ；用户熟悉的代表坑货是 Android+OOM killer 。

不过考虑到语言内建 GC 的流行，大部分没有考虑清楚适用范围的语言在这里都难逃其咎。和这个主题直接相关的是， Python 从原则上（想做通用领域语言，想“简单”）就很不擅长应对这点，加上实现的实际表现也不咋地，所以成为靶子也不奇怪。

注意，这里说的是 Python ，不是“互联网的” Python 。 Python 从来就不是互联网行业专用的 DSL 。否则，一开始就没必要讨论了。

Lisp 当然有另外的槽点，不过和这里的话题比较无关就是了（至少 Lisp 不存在一种大规模的主流实现能拉到那么多仇恨）。

@pyufftj “你的”计算机，谢谢。

@wizardforcel 我以最终用户的身份鄙视你的观点。

别以为你那边不需要高性能，就以为全球人民都不需要高性能。事实是能论证清楚哪里不需要“高性能”的用户压根就没几个，更别提逗比开发者乱加中间层挥霍的能有多少了。或许你都没感觉到能耗也算是性能需求的一部分吧？

至于“多数情况”，根本哪壶不开提哪壶。服务器吞吐量厨惯了也就罢了，随便一个客户端应用还 yy 整个机器内存“不用白不用”，谁 tm 给你的胆把用户的宿主环境不当多任务系统看？

这种不经过大脑分析需求“性能过剩”论给我的计算环境添堵有很大的功劳。比如说，市面上常规手持设备就没有一个能面向最终用户指定任务保证响应的，谁的锅？

面对横竖都是被坑的局面，用户能怎么办？把生态推倒全部自己撸一遍？开玩喜呢。

市场手段效果不显著，那么除了对付 dssq 见一次打死一次以外就没有效的通用解法了。

@hanfeng3015 王垠的私货要引用也行，但别不到点上。顺便他是一向很鄙视 Python 的。

语言的“速度”，其实是一句空话——这倒是没错，不过原因是——“速度”是个向量。搭配不当的语病 fail fast 就行了。

“语言只负责描述一个程序，而程序运行的速度，其实绝大部分不取决于语言。它主要取决于 1)算法和 2)编译器或解释器的质量。”

这里的外行在于语言忽略了语言钦定的语义。把一个语言设计成编译器或解释器实现得无论如何不得不低效（否则就不算符合语言规范要求）是很容易的。

不过 Python 的“慢”主要并不是这个问题。例如， GIL 就不是 Python 的锅而是 CPython 的锅。

然而最主流的实现如此熟练地甩锅给用户且用户经常不得不接受，也从侧面体现出设计之外的辣鸡了。

另外一个情况是语言自身描述性能规格的时候，比如要求时序。这里就没必要展开了。

所谓“ Lisp ……代价”指的更像是 Lisp 自身的抽象的缺陷。不过王垠近年来似乎终于知道 Lisp machine 一条路走到黑到处都不能 O(1)了？

@GeekGao 这里的出发点有两点：首先， native 这件事和性能本质上毫无关系；其次， native 也是相对而言的。是不是能更快，取决于实现的机制，而不是接口所在的具体层次。使用相对不 native 的接口的确可以给人造成慢的刻板印象，但现实中这主要错误的选型以及上层封装得太渣的锅。
x86 汇编背后的 ISA 一般计算机系统中的开发中不需要修改硬件实现的下界。这种层次的 native 仍然没有多少特殊性；像我所在的（硬件）项目就涉及实现 ISA ，于是 ISA 自然就不够 native 了。而对绝大多数软件项目来讲这个层次又太低了，实际根本不需要也不适合考虑这层东西。加上就像我所说的真没有性能更好的保证，所以这些东西和这个主题关心的东西无关。

@serial X 窗口系统所谓的 C/S 架构，其中的 server 指的是提供某些设备抽象在内的基础环境服务的实现；而 client 是这些服务的用户，也就是普通的 app 。 X client 一般利用 xlib 和 xcb 这样的 client API 来和 X server 通信。最终显示到设备这个过程，是 X server 内部实现保证的，普通的 X client 是不会直接插手的。这里的协议包括一个系列。
至于你说的“怎么显示”，实际上是指 client 决定要显示的具体内容，这点窗口系统管不着。对协议来讲，这算是透明的负载。在有底层窗口系统支持的情况下，普通 app 用的 UI 库也只能管到这（至少倒腾图形驱动不算是传统 UI 库的分内事）。
另一个类似的例子是普通 Win32 app 也不会插手 csrss 怎么和 NT executive 交互。没有公开协议。

@lovedebug 你数一下 0 的个数大概就不能指望是 IEEE-754 的双精度了，起码是扩展双精度。
@iVanilla PHP 还真有相关的 bug ，而且曾经造成了比较严重的后果，不过具体表现和系统相关： https://bugs.php.net/53632

@serial 有一点你说反了。装 X 的架构中，显示图形的是 X server ，而不是“客户端”。

哪里战了，不就是科普一些废话浪费口水罢了。倒是照例钓出个别对语言实现常识少根筋的的。（以下无涉勿对号入座。）

@kingmo888
但是人家 R 和 Matlab 可是老老实实当 DSL ，没像 py 几乎啥玩意儿都想掺一脚交易一下……

@est
毕竟当年的汇编也比较图样嘛……对硬布线的实现有些迷信也是容易理解的。不过现在呢？

@GeekGao
为什么和 native 有关系？是说 native 就有性能优势么。然而你所谓的 x86 ，钦定的 native operating mode 可是不鸟 x64 来着，一坨 SIMD 就这样废了……
而且说到底这种程度的 native 还不是要被 decoder 艹一遍嘛。敢直接操作没 renaming 过的 register file 么？
最后，你最好别对硬件实现的节操有多少幻想。（虽然昨天我这还是决定 RCP/RSQRT(PD/PS/SD/SS)还是 EU 支持算了……拆二十几条 uop 性能上太蠢，简直是找卡马克打嘛……）

@luluuulu4848
哪个语言钦定解释哪个语言钦定编译，编译的目标是什么，能看清楚再扯蛋么。
（不是我黑……其实即便是 CPython 这样的软蛋，吊打 cint 这样的“ C/C++”实现，还是绰绰有余的……）

@aisk Linux 发行版和 Linux 当然不是一回事。 Linux 项目哪里维护 GUI 了？也不都需要装 X 嘛， Wayland 不知是不是够用了……
顺便多数语言就是没法做一般意义的操作系统，除非修改语言本身（不止是语言的实现）。 ISO C 和 ISO C++说清楚了 freestanding environment ，所以实现可以直接往上糊。 Java 和 C#之类就得借助外部的 spec 。多数其它语言根本就没能耐管这个。

权威答案：不用想了。
就现在的业内平均教育水平，一年经验的小鲜肉，多数连哪些东西算 C 艹都搞不明白。

……你这 C 艹读着也疼得紧啊。
一行 template<typename T>搞定的东西，非得 typedef 啥 ll 邪教……

一时没反应过来，蓝苍蝇是什么鬼……

@chengzi 非正常环境非正常需求挂了我也能理解，但不管三七二十一只能一气呵成，自动把中间过程不留痕迹地干掉而不留下可能让用户干预改变默认操作的接口，那么……至少可以说是功能太弱。讲道理，断点续传这种二十年前就逐渐普及的东西在今天不支持显然不该是技术原因；而这导致实际体验远远不如传统的离线安装。看来得怪我在墙内咯……

“单核 CPU 在同一时间内只能够运行一个进程”当然是错的。“单进程多线程可以同时用到 CPU 的双核心”在主流操作系统上没有问题。
因为同时多线程(SMT)，现代超标量处理器（一个 CPU 物理核心）可以同时跑超过一个线程（否则执行单元空着太浪费），例如 Intel 的 hyperthreading 支持一个物理核心跑两个线程。讲几核的 CPU 的核心数一般直接指物理核心数，如果是指逻辑核心数一般直接会说线程数，几个逻辑核心就同时支持几套架构状态和几个线程。
对操作系统内核 /执行体来说，直接可见的 CPU 资源是逻辑核心，可以调度的任务一般直接实现成 CPU 支持的线程，所以单核 CPU 可以同时跑多个任务。不同操作系统中任务的概念不一样。例如 Windows NT 调度的是线程，进程只是线程的容器； Linux 内核不区分进程或者线程，调度的任务在用户空间可以被实现成一个进程或进程中的线程。
注意用户空间的线程和 CPU 上跑的线程不是一回事，只不过流行的系统很多直接采用 1:1 映射简化实现罢了。

@skydiver 有没有包管理器还是有些差距的。

@upczww Arch 至少文档比较全。另外相对容易定制，正常情况下不作死就不太容易浪费时间。

@imn1 虚拟机也有制造额外兼容问题的风险。之前 vmware 上不了某个版本的 X ，降级解决。