你好！我是 Oleksandr Kaleniuk，我是一个 C++ 爱好者。我已经用 C++ 写了 18 年，在这 18 年里，我一直在努力摆脱这种毁灭性的上瘾。
一切始于 2005 年末的一个 3D 空间模拟器引擎。这个引擎拥有 2005 年 C++ 所拥有的一切。三星级指针、八层依赖关系和随处可见的 C 风格宏。还有汇编位。斯捷潘诺夫式的迭代器和亚历山德列斯库式的元代码。代码应有尽有。当然，除了最重要问题的答案：为什么？
过了一会儿，这个问题也有了答案。但不是 “为什么”，而是 “为什么”。原来，这个引擎已经由 5 个不同的团队编写了大约 8 年。每个团队都为项目带来了自己喜欢的时尚，将旧代码包装成时尚风格的封装器，但却没有为引擎本身带来多少价值。
起初，我老老实实地努力摸索每一件小事。这并不是一个令人满意的经历，一点也不，在某些时候，我放弃了。我仍然在关闭任务，修复漏洞。不能说我的工作效率很高，只能说我的工作效率足够高，不至于被炒鱿鱼。但后来我的老板问我”你想不想把一些着色器代码从汇编改写成 GLSG？”我想天知道 GLSL 是什么样子，但它不可能比 C++ 更糟糕，于是就答应了。结果并没有更糟。
这就成了一种模式。我仍然主要使用 C++ 编写程序，但每次有人问我：”你想做那个非 C++ 的东西吗？”我都会说：”当然！”。我都会说 “当然！”。然后我就去做那件事，不管是什么。我用 C89、MASM32、C#、PHP、Delphi、ActionScript、JavaScript、Erlang、Python、Haskell、D、Rust 写过程序，甚至还写过糟糕得令人发指的 InstallShield 脚本语言。我用 VisualBasic 和 bash 写过程序，还用过一些专有语言，但我甚至不能合法地谈论这些语言。我甚至无意中自己做了一个。我做了一个简单的 Lisp 风格解释器，帮助游戏设计者自动加载资源，然后就去度假了。当我回来时，他们正在用这个解释器编写整个游戏场景，所以我们不得不支持它一段时间。
因此，在过去的 17 年里，老实说我一直想放弃 C++，但每次尝试了新的闪亮事物后，我又回来了。尽管如此，我还是认为用 C++ 编写程序是个坏习惯。它既不安全，也不像人们想象的那样有效，而且会浪费程序员大量的脑力在与制作软件无关的事情上。你知道在 MSVC 中 uint16_t(50000) + uin16_t(50000) == -1794967296 吗？你知道为什么吗？知道，我也是这么想的。
我认为，劝阻年轻一代不要把 C++ 作为自己的职业，是长期从事 C++ 编程人员的道德责任，就像无法戒酒的酗酒者有道德责任警告年轻人不要酗酒一样。
但为什么我就不能戒掉呢？这到底是怎么回事？问题在于，没有一种语言，尤其是所谓的 “C++ 杀手”，能在现代社会中提供任何优于 C++ 的真正优势。所有这些新语言的主要目的都是为程序员好。这很好，只是用糟糕的程序员写出好代码是二十世纪的问题，当时晶体管密度每 18 个月增长 2 倍，程序员人数每 5 年增长 2 倍。
我们现在生活在二十一世纪。世界上有经验的程序员比历史上任何时候都多。我们现在比以往任何时候都更需要高效的软件。
在二十一世纪，一切都比较简单。你有一个想法，把它包装成一些用户界面，然后作为桌面产品出售。速度慢吗？谁在乎呢？反正十八个月后，台式机的速度会提高两倍。重要的是进入市场，开始销售功能，而且最好没有错误。在这种情况下，当然，如果编译器能阻止程序员制造错误，那就太好了！因为错误不会带来现金，而且无论程序员增加了什么功能或错误，你都得付钱给他们。
现在情况不同了。你有了一个想法，将其封装在 Docker 容器中，然后在云中运行。现在，你可以从人们运行你的软件中获得收入，只要它能让他们的问题迎刃而解。即使它只做了一件事，但做对了，你也能获得收入。你不必为了卖出新版本的产品而在产品中塞满虚构的功能。另一方面，为你代码的低效付出代价的是你自己。每一个次优的例程都会显示在你的 AWS 账单上。
因此，在新形势下，您现在需要更少的功能，但同时也需要更好的性能来实现现有功能。
突然发现，所有的 “C++ 杀手”，即使是那些我衷心喜爱和尊重的，如 Rust、Julia 和 D，都没有解决二十一世纪的问题。它们仍停留在二十世纪。它们的确可以帮助你编写更多的功能和更少的错误，但当你需要从租用的硬件中榨取最后的 FLOPS 时，它们就帮不上什么忙了。
因此，与 C++ 相比，它们只是具有竞争优势。或者说，它们相互之间也没有竞争优势。它们中的大多数，例如 Rust、Julia 和 Cland 甚至共享同一个后台。如果所有赛车手都坐在同一辆车里，就没有人能赢得比赛。
那么，与 C++ 或所有传统的超前编译器相比，哪些技术能给你带来竞争优势呢？
问得好！
很高兴你这么问。
C++ 1号杀手 Spiral
在介绍 Spiral 本身之前，我们先来看看你的直觉有多灵敏。你认为标准 C++ 正弦函数和正弦的四元多项式模型哪个更快？
// 版本 1
auto y = std::sin(x);
// 版本 2
y = -0.000182690409228785*x*x*x*x*x*x*x
+0.00830460224186793*x*x*x*x*x
-0.166651012143690*x*x*x
+x;
下一个问题。使用带短路（short-circuiting）的逻辑运算，还是把逻辑表达式变成算术表达式？
// version 1
if (xs[i] == 1
&& xs[i+1] == 1
&& xs[i+2] == 1
&& xs[i+3] == 1) // xs are bools stored as ints
// version 2
inline int sq(int x) {
return x*x;
}
if(sq(xs[i] - 1)
+ sq(xs[i+1] - 1)
+ sq(xs[i+2] - 1)
+ sq(xs[i+3] - 1) == 0)
还有一个问题。有分支的交换排序和无分支的索引排序哪个排序 triplets 更快？
// version 1
if(s[0] > s[1])
swap(s[0], s[1]);
if(s[1] > s[2])
swap(s[1], s[2]);
if(s[0] > s[1])
swap(s[0], s[1]);
// version 2
const auto a = s[0];
const auto b = s[1];
const auto c = s[2];
s[int(a > b) + int(a > c)] = a;
s[int(b >= a) + int(b > c)] = b;
s[int(c >= a) + int(c >= b)] = c;
如果你果断地回答了所有问题，甚至不假思索或上网搜索，那么你的直觉就失败了。你没有发现陷阱。没有上下文，这些问题都没有明确的答案。
1.如果使用 clang 11 以 -O2 -march=native 构建多项式模型，并在英特尔酷睿 i7-9700F 上运行，其速度是标准正弦的 3 倍。但如果使用 NVCC 和 --use-fast-math，并在 GPU 即 GeForce GTX 1050 Ti Mobile 上运行，标准正弦比该模型快 10 倍。
2.在 i7 上用短路(short-circuiting)逻辑换取矢量化算术也是合理的。这使片段的运行速度提高了一倍。但在使用相同 clang 和 -O2 的 ARMv7 上，标准逻辑比微优化快 25%。
3.索引排序与交换排序相比，索引排序在英特尔上要快 3 倍，而交换排序在 GeForce 上要快 3 倍。
因此，我们都非常喜欢的微优化既可以将代码的速度提高 3 倍，也可以将速度降低 90%。这一切都取决于环境。如果编译器能为我们选择最佳的替代方案，例如，当我们切换编译目标时，索引排序会奇迹般地变成交换排序，那该有多好。但编译器不可能做到这一点。
1.即使我们允许编译器以多项式模型重新实现正弦，以精度换速度，它仍然不知道我们的目标精度。在 C++ 中，我们不能说 “这个函数允许有这样的错误”。我们只能使用编译器标志，如"--use-fast-math“，而且只能在翻译单元的范围内使用。
2.在第二个例子中，编译器并不知道我们的值仅限于 0 或 1，因此不可能提出我们可以提出的优化建议。我们或许可以通过使用适当的 bool 类型来暗示这一点，但那将是一个完全不同的问题。
3.在第三个例子中，两段代码差别很大，无法被视为同义词。我们把代码说得太细了。如果只是 std::sort，编译器就可以更自由地选择算法。但编译器既不会选择索引排序，也不会选择交换排序，因为这两种算法在大型数组上的效率都很低，而 std::sort 可以使用通用的可迭代容器。
这就是 Spiral 的由来。这是卡内基梅隆大学和苏黎世埃德根理工学院的一个联合项目。TL&DR：信号处理专家们厌倦了为每一个新硬件手工重写他们最喜欢的算法，于是编写了一个程序来替他们完成这项工作。该程序接收算法的高级描述和硬件架构的详细描述，并对代码进行优化，直至为指定的硬件实现最高效的算法。
与 Fortran 及其类似程序的一个重要区别是，Spiral 真正解决的是数学意义上的优化问题。它将运行时间定义为目标函数，并在受硬件架构限制的执行变体因子空间中寻找全局最优。这是编译器从未真正做到的。
编译器不会寻找真正的最优。它只是按照程序员教给它的启发式方法来优化代码。从本质上讲，编译器并不像机器那样寻找最优解，而是像汇编程序员那样工作。一个好的编译器就像一个好的汇编程序员，但仅此而已。
Spiral 是一个研究项目。它的范围和预算都很有限。但它所取得的成果已经令人印象深刻。在快速傅立叶变换方面，他们的解决方案明显优于 MKL 和 FFTW 实现。他们的代码快了约 2 倍。即使在英特尔平台上也是如此。
MKL 是英特尔自己开发的数学内核库，因此是由最懂硬件的人开发的。而 WWTF A. K. A. “西方最快傅立叶变换 “是一个高度专业化的库，由最了解算法的人提供。它们都是各自领域的佼佼者，而 Spiral 比它们都快了两倍，这实在令人吃惊。
当 Spiral 使用的优化技术最终定型并商业化时，不仅 C++，Rust、Julia 甚至 Fortran 都将面临前所未有的竞争。如果用高级算法描述语言编写代码能使速度提高 2 倍，为什么还要用 C++ 编写代码呢？
C++ 杀手之二 Numba
最好的编程语言是你已经非常熟悉的语言。连续几十年来，大多数程序员最熟悉的编程语言一直是 C 语言，它也是 TIOBE 指数的领头羊，其他 C 语言同类产品紧紧占据前十名。然而，就在两年前，一件闻所未闻的事情发生了。C 语言的第一名让给了其他语言。
这个 “别的东西 “似乎就是 Python。在上世纪 90 年代，Python 是一门没有人认真对待的语言，因为它是另一种脚本语言，我们已经有了很多脚本语言。
有人会说”呸，Python 很慢”，这看起来就像个傻瓜，因为这是术语上的无稽之谈。就像手风琴或煎锅一样，一门语言根本没有快慢之分。就像手风琴的速度取决于演奏者一样，语言的 “速度 “也取决于编译器的速度。
有人可能会继续说：”但 Python 不是编译语言”，这又是一个错误的说法。有很多 Python 编译器，其中最有前途的就是 Python 脚本。让我来解释一下。
我曾经有个项目。这是一个 3D 打印模拟项目，最初是用 Python 编写的，然后 “为了提高性能 “用 C++ 重写，然后移植到 GPU，所有这些都是在我加入之前完成的。然后，我花了几个月的时间将其移植到 Linux 上，为 Tesla M60 优化 GPU 代码，因为它是当时 AWS 上最便宜的 GPU，并验证 C++/CU 代码中的所有更改，以便与 Python 中的原始代码保持一致。因此，除了我通常擅长的设计几何算法之外，我什么都做了。
当我终于完成所有工作时，一位来自不来梅的兼职学生打电话问我：”你擅长异构计算吗？”你擅长异构技术，能帮我在GPU上运行一个算法吗？”当然可以！我向他介绍了 CUDA、CMake、Linux 构建、测试和优化，大概花了一个小时。他很有礼貌地听完了，但最后说”这一切都很有趣，但我有一个非常具体的问题。我有一个函数，我在它的定义前写了 @cuda.jit，但 Python 说什么数组，而且不编译内核。你知道问题出在哪里吗？
我不知道他自己在一天之内就弄明白了。显然，Numba 无法使用原生 Python 列表，它只接受 NumPy 数组中的数据。于是，他想出了这个办法，并在 GPU 上运行了他的算法。用 Python。他没有遇到我花了几个月时间才解决的问题。你想在 Linux 上运行吗？没问题，就在 Linux 上运行。你想让它与 Python 代码保持一致吗？没问题，它就是 Python 代码。你想针对目标平台进行优化吗？也没问题。Numba会根据你运行代码的平台对代码进行优化，因为它不会提前编译，而是在已经部署的情况下按需编译。
是不是很棒？嗯，不。反正对我来说不是。我花了几个月的时间用 C++ 解决在 Numba 中从未出现过的问题，而一个来自不来梅的临时工却在几天内做出了同样的东西。如果他不是第一次使用Numba，可能只需要几个小时。那么，”农巴 “到底是什么？它是一种什么样的巫术？
没有魔法。Python 装饰器会把每一段代码都变成抽象语法树，然后你就可以用它做任何你想做的事了。Numba 是一个 Python 库，它可以将抽象语法树编译成它所拥有的任何后端，并支持任何平台。如果你想将 Python 代码编译成大规模并行方式在 CPU 内核上运行，只需告诉 Numba 这样编译即可。如果你想在 GPU 上运行某些东西，同样，你只需提出要求即可。
@cuda.jit
def matmul(A, B, C):
"""Perform square matrix multiplication of C = A * B."""
i, j = cuda.grid(2)
if i < C.shape[0] and j < C.shape[1]:
tmp = 0.
for k in range(A.shape[1]):
tmp += A[i, k] * B[k, j]
C[i, j] = tmp
Numba 是使 C++ 过时的 Python 编译器之一。不过，从理论上讲，它并不比 C++ 更好，因为它使用相同的后端。它使用 CUDA 进行 GPU 编程，使用 LLVM 进行 CPU 编程。在实践中，由于不需要为每种新架构提前重建，Numba 解决方案能更好地适应每种新硬件及其可用优化。
当然，如果能像 Spiral 那样具有明显的性能优势就更好了。但是，Spiral更像是一个研究项目，它可能会杀死C++，但最终也只是在幸运的情况下。现在，使用 Python 的 Numba 就能实时扼杀 C++。因为如果你能用 Python 编写程序，并拥有 C++ 的性能，你为什么还要用 C++ 编写程序呢？
C++ 杀手之三 ForwardCom
让我们再玩一个游戏。我会给你三段代码，你来猜猜其中哪一段，或者更多，是用汇编编写的。它们是
invoke RegisterClassEx, addr wc ; register our window class
invoke CreateWindowEx,NULL,
ADDR ClassName, ADDR AppName,\
WS_OVERLAPPEDWINDOW,\
CW_USEDEFAULT, CW_USEDEFAULT,\
CW_USEDEFAULT, CW_USEDEFAULT,\
NULL, NULL, hInst, NULL
mov hwnd,eax
invoke ShowWindow, hwnd,CmdShow ; display our window on desktop
invoke UpdateWindow, hwnd ; refresh the client area
.while TRUE ; Enter message loop
invoke GetMessage, ADDR msg,NULL,0,0
.break .if (!eax)
invoke TranslateMessage, ADDR msg
invoke DispatchMessage, ADDR msg
.endw
(module
(func $add (param $lhs i32) (param $rhs i32) (result i32)
get_local $lhs
get_local $rhs
i32.add)
(export "add" (func $add)))
v0 = my_vector // we want the horizontal sum of this
int64 r0 = get_len ( v0 )
int64 r0 = round_u2 ( r0 )
float v0 = set_len ( r0 , v0 )
while ( uint64 r0 > 4) {
uint64 r0 >>= 1
float v1 = shift_reduce ( r0 , v0 )
float v0 = v1 + v0
}
如果你猜到这三个例子都是汇编程序，那么恭喜你！你的直觉已经变得更好了！
第一个是 MASM32。这是一个宏汇编器，带有 “if “和 “while”，人们用它来编写本地 Windows 应用程序。没错，不是 “过去写”，而是 “现在写”。微软热衷于保护 Windows 与 Win32 API 的向后兼容性，因此所有 MASM32 程序都能在现代 PC 上正常运行。
具有讽刺意味的是，C 的发明是为了让 UNIX 从 PDP-7 到 PDP-11 的转换变得更容易。它被设计成一种可移植的汇编程序，能够在 70 年代硬件架构的寒武纪大爆炸中幸存下来。但到了二十一世纪，硬件架构的发展却如此缓慢，以至于我二十年前用 MASM32 编写的程序如今可以完美地组装和运行，但我却没有信心，我去年用 CMake 3.21 编写的 C++ 应用程序如今还能用 CMake 3.25 编写。
第二段代码是 Web Assembly。它甚至不是宏汇编器，没有 “if “和 “while”，更像是浏览器的人可读机器代码。或者其他浏览器。从概念上讲，任何浏览器都可以。
Web Assembly 代码完全不依赖于硬件架构。它所服务的机器是抽象的、虚拟的、通用的，随你怎么称呼。如果你能读到这篇文章，那么你的物理机器上已经有一个了。
但最有趣的代码是第三段。它就是 ForwardCom，一个由著名的 C++ 和汇编优化手册作者 Agner Fog 提议的汇编程序。就像 Web Assembly 一样，它所涵盖的与其说是一个汇编器，不如说是一套通用指令集，其目的不仅是为了实现向后兼容性，也是为了实现向前兼容性。因此，ForwardCom 被命名为 “ForwardCom”。ForwardCom 的全称是 “开放式前向兼容指令集架构“。换句话说，与其说它是一个汇编提案，不如说是一个和平条约提案。
我们知道，所有最常见的架构系列：x64、ARM 和 RISC-V 都有不同的指令集。但没有人知道保持这种方式的充分理由。除了最简单的处理器，所有现代处理器运行的都不是你输入的代码，而是它们将你的输入转换成的微代码。因此，不只是 M1 对英特尔有向后兼容性层，每个处理器基本上都对其所有早期版本有向后兼容性层。
那么，是什么阻碍了架构设计师们就类似的层达成一致，但又能向前兼容呢？除了直接竞争的公司之间相互冲突的雄心壮志之外，什么也没有。但是，如果处理器制造商能够在某一时刻达成共识，采用通用指令集，而不是为每一个其他竞争者实施新的兼容性层，那么 ForwardCom 将使汇编编程回归主流。这个前向兼容性层将治愈所有汇编程序员最严重的神经衰弱：”如果我为这个特定的体系结构编写了千载难逢的代码，而这个特定的体系结构在一年内就会被淘汰，那该怎么办？
有了前向兼容性层，它就永远不会过时。这就是问题所在。
汇编编程还受到一个神话的阻碍，即汇编编写很难，因此不切实际。Fog 的主张也解决了这个问题。如果人们认为用汇编语言编写程序很难，而用 C 语言编写程序却不难，那么我们就把汇编程序做成 C 语言的样子。没有充分的理由让现代汇编语言的外观与其祖父在 50 年代的外观一模一样。
你刚才也看到了三个汇编示例。没有一个看起来像 “传统 “汇编，也不应该像。
因此，ForwardCom 是一种可以编写最佳代码的汇编语言，它永远不会过时，也不会让你学习 “传统 “汇编语言。就所有实际考虑而言，它是未来的 C 语言。而不是 C++。
那么，С++最终会在什么时候消亡呢？
我们生活在一个后现代世界。除了人，什么都不会死。就像拉丁语从未真正消亡一样，就像 COBOL、Algol 68 和 Ada 一样–C++ 注定要在生与死之间永恒地半死不活下去。C++ 永远不会真正消亡，它只会被更新、更强大的技术挤出主流。
好吧，不是 “将被挤走”，而是 “正在被挤走”。我是作为一名 C++ 程序员来到现在的工作岗位的，而今天，我的工作日是从 Python 开始的。我写下方程式，SymPy 帮我求解，然后将解法翻译成 C++。然后，我把这些代码粘贴到 C++ 库中，甚至懒得对其进行格式化，因为 clang-tidy 会帮我这样做。静态分析器会检查我是否弄乱了命名空间，动态分析器会检查是否有内存泄漏。CI/CD 将负责跨平台编译。剖析器能帮我了解代码的实际运行情况，反汇编器则能帮我了解代码运行的原因。
如果我把 C++ 换成 “非 C++”，我 80% 的工作将保持不变。C++ 与我的大部分工作根本无关。这是否意味着对我来说，C++ 已经死了 80%？
本文文字及图片出自 The Real C++ Killers (Not You, Rust)
你的反应是：