了解汇编程序的原因之一是，有时可以使用汇编程序来编写比用高级语言(特别是C语言)编写的代码性能更好的代码。然而，我也听人说过很多次，尽管这并非完全错误，但实际上可以使用汇编程序来生成性能更好的代码的情况极其罕见，并且需要汇编方面的专业知识和经验。
这个问题甚至没有涉及到这样一个事实，即汇编程序指令将是特定于机器的、不可移植的，或者汇编程序的任何其他方面。当然，除了这一点之外，了解汇编还有很多很好的理由，但这是一个需要示例和数据的具体问题，而不是关于汇编程序与高级语言的扩展论述。
谁能提供一些具体的例子，说明使用现代编译器汇编代码比编写良好的C代码更快，并且您能否用分析证据支持这一说法?我相信这些案例确实存在，但我真的很想知道这些案例到底有多深奥，因为这似乎是一个有争议的问题。
当前回答
Walter Bright的《optimization Immutable and Purity》可能值得一看，它不是一个概要测试，但向您展示了手写和编译器生成ASM之间的区别。Walter Bright写优化编译器，所以值得一看他的其他博客文章。
其他回答
，问了这个问题，并给出了使用汇编的利弊。
只有在使用编译器不支持的特殊用途指令集时。
为了最大限度地利用具有多个管道和预测分支的现代CPU的计算能力，您需要以这样一种方式来构造汇编程序:a)人类几乎不可能编写b)甚至更不可能维护。
此外，更好的算法、数据结构和内存管理将为您提供至少一个数量级的性能，而不是在汇编中进行的微观优化。
这很难具体地回答，因为这个问题非常不具体:到底什么是“现代编译器”?
理论上，几乎任何手动的汇编器优化都可以由编译器来完成——实际上它是否已经完成，不能笼统地说，只能说特定编译器的特定版本。许多可能需要花费大量的精力来确定它们是否可以在特定的上下文中应用而不产生副作用，以至于编译器编写者不会为它们烦恼。
一个更著名的组装片段来自Michael Abrash的纹理映射循环(在这里详细解释):
add edx,[DeltaVFrac] ; add in dVFrac
sbb ebp,ebp ; store carry
mov [edi],al ; write pixel n
mov al,[esi] ; fetch pixel n+1
add ecx,ebx ; add in dUFrac
adc esi,[4*ebp + UVStepVCarry]; add in steps
现在，大多数编译器将高级CPU特定指令表示为intrinsic，即编译为实际指令的函数。MS Visual c++支持MMX、SSE、SSE2、SSE3和SSE4的intrinsic，因此您不必太过担心使用特定于平台的指令来进行汇编。Visual c++还可以通过适当的/ARCH设置来利用您所针对的实际体系结构。
在历史上插话。
当我还年轻的时候(20世纪70年代)，根据我的经验，汇编是很重要的，更重要的是代码的大小，而不是代码的速度。
如果一个高级语言的模块是1300字节的代码，但该模块的汇编版本是300字节，那么当您试图将应用程序装入16K或32K的内存时，这1K字节就非常重要。
那时候编译器还不是很好。
在老式的Fortran中
X = (Y - Z)
IF (X .LT. 0) THEN
... do something
ENDIF
当时的编译器在X上执行了一个SUBTRACT指令，然后是一个TEST指令。 在汇编程序中，您只需在减法之后检查条件代码(LT零，零，GT零)。
对于现代系统和编译器来说，这些都不是问题。
我认为理解编译器在做什么仍然很重要。 当您使用高级语言编写代码时，您应该了解什么允许或阻止编译器执行循环展开。
当编译器执行“类似分支”的操作时，使用管道内衬和包含条件的前瞻计算。
当执行高级语言不允许的事情时，仍然需要汇编程序，比如读取或写入处理器特定的寄存器。
但在很大程度上，普通程序员不再需要它，除非对代码如何编译和执行有基本的了解。
