了解汇编程序的原因之一是，有时可以使用汇编程序来编写比用高级语言(特别是C语言)编写的代码性能更好的代码。然而，我也听人说过很多次，尽管这并非完全错误，但实际上可以使用汇编程序来生成性能更好的代码的情况极其罕见，并且需要汇编方面的专业知识和经验。
这个问题甚至没有涉及到这样一个事实，即汇编程序指令将是特定于机器的、不可移植的，或者汇编程序的任何其他方面。当然，除了这一点之外，了解汇编还有很多很好的理由，但这是一个需要示例和数据的具体问题，而不是关于汇编程序与高级语言的扩展论述。
谁能提供一些具体的例子，说明使用现代编译器汇编代码比编写良好的C代码更快，并且您能否用分析证据支持这一说法?我相信这些案例确实存在，但我真的很想知道这些案例到底有多深奥，因为这似乎是一个有争议的问题。
当前回答
我认为汇编程序更快的一般情况是，当一个聪明的汇编程序员看到编译器的输出并说“这是性能的关键路径，我可以写这个更有效”，然后那个人调整汇编程序或从头重写它。
其他回答
我需要对192位或256位的每次中断进行移位操作，每50微秒发生一次。
它通过一个固定的映射(硬件限制)实现。使用C语言，制作它只需要大约10微秒。当我把它翻译到Assembler时，考虑到这个映射的特定特性，特定的寄存器缓存，并使用面向位的操作;它只花了不到3.5微秒的时间。
我已经阅读了所有的答案(超过30个)，并没有找到一个简单的原因:如果你读过并练习过Intel®64和IA-32架构优化参考手册，汇编程序比C更快，所以汇编程序可能更慢的原因是编写这种慢汇编程序的人没有阅读优化手册。
In the good old days of Intel 80286, each instruction was executed at a fixed count of CPU cycles. Still, since Pentium Pro, released in 1995, Intel processors became superscalar, utilizing Complex Pipelining: Out-of-Order Execution & Register Renaming. Before that, on Pentium, produced in 1993, there were U and V pipelines. Therefore, Pentium introduced dual pipelines that could execute two simple instructions at one clock cycle if they didn't depend on one another. However, this was nothing compared with the Out-of-Order Execution & Register Renaming that appeared in Pentium Pro. This approach introduced in Pentium Pro is practically the same nowadays on most recent Intel processors.
Let me explain the Out-of-Order Execution in a few words. The fastest code is where instructions do not depend on previous results, e.g., you should always clear whole registers (by movzx) to remove dependency from previous values of the registers you are working with, so they may be renamed internally by the CPU to allow instruction execute in parallel or in a different order. Or, on some processors, false dependency may exist that may also slow things down, like false dependency on Pentium 4 for inc/dec, so you may wish to use add eax, 1 instead or inc eax to remove dependency on the previous state of the flags.
如果时间允许，您可以阅读更多无序执行和注册重命名。因特网上有大量的信息。
There are also many other essential issues like branch prediction, number of load and store units, number of gates that execute micro-ops, memory cache coherence protocols, etc., but the crucial thing to consider is the Out-of-Order Execution. Most people are simply not aware of the Out-of-Order Execution. Therefore, they write their assembly programs like for 80286, expecting their instructions will take a fixed time to execute regardless of the context. At the same time, C compilers are aware of the Out-of-Order Execution and generate the code correctly. That's why the code of such uninformed people is slower, but if you become knowledgeable, your code will be faster.
除了乱序执行之外，还有很多优化技巧和技巧。请阅读上面提到的优化手册:-)
However, assembly language has its own drawbacks when it comes to optimization. According to Peter Cordes (see the comment below), some of the optimizations compilers do would be unmaintainable for large code-bases in hand-written assembly. For example, suppose you write in assembly. In that case, you need to completely change an inline function (an assembly macro) when it inlines into a function that calls it with some arguments being constants. At the same time, a C compiler makes its job a lot simpler—and inlining the same code in different ways into different call sites. There is a limit to what you can do with assembly macros. So to get the same benefit, you'd have to manually optimize the same logic in each place to match the constants and available registers you have.
我想说的是，当你比编译器更擅长一组给定的指令时。所以我认为没有通用的答案
Walter Bright的《optimization Immutable and Purity》可能值得一看，它不是一个概要测试，但向您展示了手写和编译器生成ASM之间的区别。Walter Bright写优化编译器，所以值得一看他的其他博客文章。
GCC已经成为广泛使用的编译器。它的优化通常不是很好。比编写汇编程序的普通程序员好得多，但就实际性能而言，并没有那么好。有些编译器产生的代码简直令人难以置信。所以一般来说，有很多地方你可以进入编译器的输出，调整汇编器的性能，和/或简单地从头重写例程。
