完全理解现代 pc 架构是否有可能获得比编译器更好的性能？

Question

我知道现在很多编译器都非常擅长优化代码。但是，如果一个人完全理解现代 pc 架构，是否有可能让代码比编译器更快？ 比如，如果他用 100% 的汇编编写代码，专注于架构呢？如果它确实有所作为，是否值得？

Answer 1

是的！ 经验丰富的开发人员可以在特定任务上明显击败编译器（考虑到相对大量的时间）。

一个原因是开发人员可以比编译器获得更多关于给定任务的信息（开发人员可以试验算法，了解数据大小、可能的输入、程序的执行上下文） .另一个原因是编译器并不完美（它们使用启发式算法）并且经常无法进行高级代码转换。

但是，通常只向编译器提供提示、调整编译参数、插入内联汇编或内置调用就足够了，而不是在汇编中编写完整的程序。

一个很好的例子是使用低级处理器指令，例如non-temporal instructions 或SIMD instructions 以及bit-wise instructions。这些指令通常可以从具有足够提示的编译器中生成。对于register allocation，目标硬件专家有可能设计出更好的汇编代码（在这种情况下，编译器提示是不够的）。

Answer 2

如果其中一些要求是真实的，有时人类可以产生更好的代码：

1. 人类需要有关目标架构的特定知识。
2. 人类知道编译器的所有技巧，例如（左移而不是乘法）。
3. 此外，人类还需要了解很多关于汇编/处理器的知识，例如流水线停顿、缓存未命中……
4. 人类将需要大量时间来完成重要的程序。

比如，如果他用 100% 汇编编写代码，专注于架构会怎样？

这个程序在这个 CPU 上会非常快，但是你必须为每个 cpu 从头开始​​重写它。 （就像您使用更快的 shr 指令为处理器 1 编写的一样，但处理器 2 具有更快的 div 指令。） 此外，开发时间将显着延长（高达 20 倍）==>更高的成本

如果它确实有所作为，是否值得？

仅适用于一小部分应用程序，例如为微控制器编写代码，或者如果您真的需要纯粹的性能（数据的数据处理，这无法在 GPU 上完成）。

更多信息： When is assembly faster than C?

但是： 首先使用其他算法，例如使用 Coppersmith–Winograd 算法而不是用于矩阵乘法的朴素算法。只有在使用所有其他可能性时，才使用组装，否则您很快就会陷入维护噩梦。

Answer 3

是的，人类在汇编程序中编码可以击败编译器。但总的来说，您最好将宝贵的时间花在更高层次的优化上。

为什么人类可以击败编译器？

因为编译器是由具有目标架构知识的人设计的。因此，在知识水平相同的情况下，人类可以生成至少与编译结果一样性能的汇编代码。

它可能会更好，因为人类开发人员可以针对给定任务进行优化，而编译器只能应用通用优化。

为什么这是个坏主意？

一切都与开发成本有关。

用汇编语言开发比用高级语言开发花费很多很多的时间，并且降低了可读性和可维护性。

在大多数情况下，您最好将相同的开发时间投入到高级优化中，例如更好的算法、局部优化，所有这些都基于对应用程序的全面分析以找到真正的瓶颈。

有了装配解决方案所需的预算，您甚至可以让两三个独立的、相互竞争的团队开发他们的高级解决方案，然后让他们将他们最好的想法组合成一个最终版本，并且仍有预算来进一步优化那个。