新的吐槽

槽点太多，不知从何开始。

就拿C++来说吧，gcc几百年前就支持typeof和type_compatible了 ，而且连C语言都可以用。至于align之类的，C++还是勉为其难的纳入了标准，到C++17连attribtue也算进来了。gcc早就支持嵌套函数，lambda函数不过是嵌套函数的语法糖。所以激动个啥？ 当年有IOCCC大赛，像宏之类的各种东西被玩出花来了，现在把C++ template折腾的越来越复杂的怕不是当年那同一批人。

C++怕不是有强迫症，啥系统库函数都封装一遍，封就封把，封的还不完整。要是用户需求稍复杂又直接回到原型。这样玩很有意思么？代码编写时间从来就不是开发时间的重点。

很多C++的教材习惯把C批判一番，C当然有问题，缺乏语言级别的面向对象支持，没有命名空间，更别说包管理之类的东西。但很多人说的问题是不存在的-这是他们自己的问题而不是C的问题，比如某份2016年的文档说C语言不支持在for内定义循环变量，即不能for (int i; i < n; i++)，这和nvidia 2018年的文档说CPU没有FMA指令有异曲同工之妙。

至于python，抱歉，我看python的数值库函数没看出来简洁在哪了。问题就在这里，常见的能抽象的东西大家都抽象了，真正要做的往往是难以甚至无法抽象的东西-这种东西在高性能数值库开发中非常普遍。无论你用什么方式实现，代码复杂度本质是一样的。而很多小白对各种抽象的代价一无所知，他们能轻易写出慢几十上百倍的代码，在cache上的失误完全可以让代码复杂度的优势化为灰烬。硬件性能永远都是无法满足需求的！！！数值程序的原型验证请使用matlab，图形化显示，正确性验证，交互式调试，GPU/集群，简单的安装方式，性能调优，哪一个都比python强无数倍。

既然选择C++写数值程序，就不要惦记模板和编译器优化。在专业数值程序编写者面前，编译器的优化就是智障。很多C++数值库给人一种我自己也能用template写出高效简洁程序的错觉。第一，模板自身的实现/调试/优化一点都不简单，比如Eigen的作者针对每个架构做了优化并且检查生成的汇编代码，调用模板函数代码的优化同样令人抓狂，后期profile时看到一长串模板类函数名和层层封装套娃简直让人崩溃；第二，你以为这些库函数就靠谱了，too young too simple，某些库，说得直白点，就是垃圾。当我看到某知名python库的SVD使用1e-15作为阈值硬截断时惊呆了，至少你要考虑矩阵的维度和double/float类型的差异吧。其他种种都让我怀疑库函数编写者是不是把所有精力都放在写出好看的C++/python代码而不是性能和正确性上了；第三，抽象就意味着性能损失，再次强调，很多计算模式无法抽象为函数、模板、类的形式，跨for循环、跨函数之类改变执行流程的优化是常事；第四，代码简洁是因为减少了很多参数，但这意味着开发者需要理解减少的默认参数的意义、对性能的影响，代码编写者实际负担不会因为这种形式的简洁而降低。

effective C++本质就是从C的角度理解C++，要写出高效C，要从汇编的层次理解。高性能数值程序核心用C其实更合适，所见即所得，层层封装只会掩盖每步的计算代价，增加后期优化分析的困难。

连泛型的作用在这里都是可疑的，因为float和double经常要使用不同的常数，甚至不同的代码。顺便说下，float和double的SIMD指令不是相似的，涉及permute，shuffle操作时更是如此。在GPU上float和double完全就是两回事。强行特化或在一个模板类判断类型和写两份代码没有本质区别。不要说什么模板可以泛化到__float128之类的其他类型，谁告诉你新的类型就和float，double行为类似了？

论文中比较性能的方式就没几个靠谱的。不同编程语言对比是常态。严格的对比要确认所用编程语言，线程数，底层数值库选择，循环迭代及其他参数的微调，内部实际调用的算法（很多库函数内部有多种算法可选，默认的未必适合），必要时手动再优化一把。能做到这些的论文几乎没有，包括最近某获奖论文在程序运行用时上就有小动作，玩文字游戏。很多代码就是一坨翔，其性能数据没有任何参考意义。

最后，很多人优化来优化去连hotspot的概念都没有，计时方法也不对，优化个毛线！