北京
上周，一个名为"6 reasons to use std::simd"的讽刺仓库在技术圈疯传。作者NoNaeAbC用六个"推荐理由"，实锤了C++26新特性的尴尬现状：编译速度慢10倍、运行不如普通循环、默认选错向量宽度、连真实SIMD代码90%的操作都写不了。更讽刺的是，它本想取代的编译器自动向量化，反而在每项关键指标上都击败了它。
这场闹剧的源头要追溯到15年前。2009年，德国重离子研究中心的研究员Matthias Kretz为加速高能物理模拟，开发了Vc库——"可移植、零开销的C++显式数据并行类型"。这个5000+提交、被CERN采用的项目，核心思路很超前：通过类型系统表达并行，而非内联汇编或新控制结构。
Kretz随后将Vc的设计带入C++标准委员会。2016年的P0214提案历经至少九轮修订，2018年以技术规范TS 2发布—— committee的潜台词是"有意思，但还没准备好"。GCC 11在2021年提供了实验性实现，Kretz本人也维护着独立版本。
然而这十年间，战场早已物是人非。GCC、Clang、MSVC的自动向量化突飞猛进；ISPC证明语言级SIMD能生成更优代码；ARM推出可变宽度的SVE架构，直接挑战固定宽度抽象；-march=native的支持成熟到普通循环都能自动用上最宽寄存器。
P1928提案最终在C++26转正。但Kretz 2012年的愿景——一次编写、处处编译——如今成了标准委员会的执念，而非开发者的刚需。当编译器已经能自动完成95%的优化时，一个连基本操作都表达不全的库，究竟解决了谁的问题？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
