问性能问题-高级编程语言和编译器的缺陷使程序集成为当今更好的选择。

EN

大会是广泛避免的。与高级语言相比，编写起来要困难得多，而且也不能明显地提高这种困难的性能。是的，最优秀的程序集程序员可能会比优化编译器编写更好的程序集，但这个编译器比绝大多数程序员要好得多。

编写非常快的程序集的困难在于，这需要非常详细地了解您所针对的处理器系列。不仅在“x86-64体系结构”的层次上，而且在“Skylake微体系结构”的层次上。一个装配指令的成本也取决于围绕它执行的指令。优化编译器有合适的成本模型，可以很好地利用处理器流水线。

这样就有两种情况可以适合编写程序集：

1. 对于无法依赖编译器优化的极端关键部分。这里的论点不是编译器不够好，而是您不想让将来的编译器版本发出更糟的程序集。另一个原因可能是，您拥有的信息无法提供给编译器，例如，这将允许您编写调用约定通常需要的簿记。
2. 使用您的语言中不可用的指令集功能。指令集有许多特定于处理器的扩展。重要的是，SIMD指令允许您将代码向量化，这可以极大地提高某些用例的数据吞吐量，如媒体转码、加密或数字。编译器可能无法使用这些扩展，除非您为编译器显式地启用它们，可能不知道较新的扩展，或者可能无法使用它们，因为它们违反了您的语言的语义。然而，如果应用程序依赖于矢量化，那么通常使用专用协处理器而不是通用CPU更好。GPU正是这样一个协处理器，因此经常用于图形或ML (这通常只是大量的矩阵乘法，很容易矢量化为融合的乘法指令)。因此，您可能会从编写着色器或使用OpenCL或CUDA等技术中看到更大的好处，而不是使用组装。

最后，编写程序集或使用矢量化可能不一定会使代码运行得更快。你还需要了解微结构。例如，使用SIMD指令甚至可以使代码运行得更慢，因为多个核心可能共享一个向量单元，从而将这些指令变成瓶颈。

与任何性能工作一样，不要盲目地“优化”：

1. 确定实际性能要求。
2. 衡量业绩。分析软件的瓶颈。
3. 尝试对这些瓶颈进行优化。量一下。如果没有用，就把它扔掉。
4. 重复直到您的性能要求得到满足。

当软件以易于理解的方式编写时，优化就更容易了。最大的胜利不是来自于更快地做同样的事情，而是来自于找到避免不必要的工作的方法。编写程序集与此目标背道而驰，因为它使软件更难理解。

即使在嵌入式系统中，现在也很少使用组装。要掌握比现代优化编译器生成的代码更好的手工组装代码是非常困难的，而当您瞄准更多现代处理器时，这种情况就变得更糟了。

在我的经验中，只有当您需要更多地控制指令和/或寄存器的使用时，程序集才会被使用。这里的主要示例来自操作系统领域，您可能希望在内核中执行编译器无法发出的特权指令，或者需要处理特殊寄存器(如程序计数器或堆栈指针)来实现任务切换。