Arm Neon Intrinsics vs hand assembly

Question

https://web.archive.org/web/20170227190422/http://hilbert-space.de/?p=22

在这个相当过时的网站上，它表明手写的asm会比intrinsics带来更大的改进。我在想，即使到了2012年，这是不是目前的事实。

那么，使用gnu交叉编译器对内部函数的编译优化改进了吗？

Answer 1

我的经验是，内部函数并不真正值得这么麻烦。对于编译器来说，在内部函数之间插入额外的寄存器卸载/加载步骤太容易了。让它停止这样做的努力比仅仅用原始霓虹灯写东西要复杂得多。我在最近的编译器(包括clang 3.1)中见过这种东西。

在这个层面上，我发现你真的需要控制到底发生了什么。如果你只是按错误的顺序做事情，你可能会遇到各种各样的麻烦。在intrinsics中做这件事感觉就像是戴着焊工的手套做手术。如果代码对性能非常关键，以至于我需要内部函数，那么内部函数就不够好了。也许其他人在这里有不同的经历。

Answer 2

为了便于移植，我不得不在几个项目中使用霓虹灯内部函数。事实是，GCC不会从霓虹灯内部生成良好的代码。这不是使用内部函数的弱点，而是使用GCC工具的弱点。微软的ARM编译器从霓虹灯内部函数生成了很棒的代码，在这种情况下不需要使用汇编语言。可移植性和实用性将决定您应该使用哪种工具。如果你能写汇编语言，那就写asm吧。对于我的个人项目，我更喜欢用ASM编写时间关键型代码，这样我就不必担心有buggy/劣质的编译器会弄乱我的代码。

更新：，苹果LLVM编译器，介于GCC (最差)和微软(最好)之间。它在指令交错或优化寄存器使用方面做得不是很好，但至少它能生成合理的代码(不像某些情况下的GCC )。

Update2:针对ARMv8的Apple LLVM编译器已经有了显著的改进。它现在可以很好地从C和intrinsics生成ARMv8代码。

Answer 3

所以这个问题已经存在四年了，现在仍然出现在搜索结果中……

2016年的情况要好得多。

我从汇编到内部的许多简单代码现在被编译器优化得比我更好，因为我懒得做流水线工作(现在有多少不同的流水线？)，而编译器只需要我传递正确的--mtune=。

对于寄存器分配可能变得紧张的复杂代码，GCC和Clang仍然可以比手写代码慢两倍……或者三个(差不多)。它主要发生在寄存器溢出上，所以您应该从代码的结构中知道这是否有风险。

但它们有时都会出现令人失望的意外。我会说，现在这是值得冒险的(尽管我是为了冒险而付费的)，如果你真的被什么东西击中了，那么就提交一个bug。这样事情就会继续变得更好。