了解汇编程序的原因之一是，有时可以使用汇编程序来编写比用高级语言(特别是C语言)编写的代码性能更好的代码。然而，我也听人说过很多次，尽管这并非完全错误，但实际上可以使用汇编程序来生成性能更好的代码的情况极其罕见，并且需要汇编方面的专业知识和经验。
这个问题甚至没有涉及到这样一个事实，即汇编程序指令将是特定于机器的、不可移植的，或者汇编程序的任何其他方面。当然，除了这一点之外，了解汇编还有很多很好的理由，但这是一个需要示例和数据的具体问题，而不是关于汇编程序与高级语言的扩展论述。
谁能提供一些具体的例子，说明使用现代编译器汇编代码比编写良好的C代码更快，并且您能否用分析证据支持这一说法?我相信这些案例确实存在，但我真的很想知道这些案例到底有多深奥，因为这似乎是一个有争议的问题。
当前回答
在历史上插话。
当我还年轻的时候(20世纪70年代)，根据我的经验，汇编是很重要的，更重要的是代码的大小，而不是代码的速度。
如果一个高级语言的模块是1300字节的代码，但该模块的汇编版本是300字节，那么当您试图将应用程序装入16K或32K的内存时，这1K字节就非常重要。
那时候编译器还不是很好。
在老式的Fortran中
X = (Y - Z)
IF (X .LT. 0) THEN
... do something
ENDIF
当时的编译器在X上执行了一个SUBTRACT指令，然后是一个TEST指令。 在汇编程序中，您只需在减法之后检查条件代码(LT零，零，GT零)。
对于现代系统和编译器来说，这些都不是问题。
我认为理解编译器在做什么仍然很重要。 当您使用高级语言编写代码时，您应该了解什么允许或阻止编译器执行循环展开。
当编译器执行“类似分支”的操作时，使用管道内衬和包含条件的前瞻计算。
当执行高级语言不允许的事情时，仍然需要汇编程序，比如读取或写入处理器特定的寄存器。
但在很大程度上，普通程序员不再需要它，除非对代码如何编译和执行有基本的了解。
其他回答
如果您没有查看编译器生成的内容的反汇编，您实际上无法知道编写良好的C代码是否真的很快。很多时候你会发现“写得好”是主观的。
因此，没有必要用汇编程序来获得最快的代码，但出于同样的原因，了解汇编程序当然是值得的。
很多年前，我教别人用c语言编程。练习是将图形旋转90度。他得到了一个花了几分钟才能完成的解，主要是因为他使用了乘法和除法等。
我向他展示了如何使用位移位重定义问题，在他拥有的非优化编译器上，处理时间缩短到大约30秒。
我刚刚得到了一个优化编译器，相同的代码在< 5秒内旋转图形。我看着编译器生成的汇编代码，从我所看到的，我决定我写汇编程序的日子结束了。
长波克，只有一个限制时间。当你没有足够的资源来优化每一个代码的变化，并花时间分配寄存器，优化一些溢出和诸如此类的事情时，编译器每次都会赢。对代码进行修改、重新编译和度量。如有必要重复。
此外，你可以在高水平方面做很多事情。此外，检查生成的程序集可能会给人一种代码是垃圾的印象，但实际上它的运行速度比您想象的要快。例子:
Int y = data[i]; //在这里做一些事情。 call_function (y,…);
编译器将读取数据，将其推入堆栈(溢出)，然后从堆栈读取并作为参数传递。听起来屎?它实际上可能是非常有效的延迟补偿，并导致更快的运行时。
//优化版本 call_function(数据[我],…);//毕竟不是那么优化。
优化版本的想法是，我们降低了寄存器压力，避免溢出。但事实上，“垃圾”版本更快!
看看汇编代码，只看指令，然后得出结论:指令越多，速度越慢，这将是一个错误的判断。
这里需要注意的是:许多组装专家认为他们知道很多，但知道的很少。规则也会随着架构的变化而变化。例如，x86代码并不存在总是最快的银弹。如今，最好还是按照经验法则行事:
记忆很慢 缓存速度快 尽量更好地使用缓存 你多久会错过一次?你有延迟补偿策略吗? 对于一个cache miss，你可以执行10-100个ALU/FPU/SSE指令 应用程序架构很重要。 . .但是当问题不在架构上时，它就没有帮助了
此外，过于相信编译器会神奇地将考虑不周到的C/ c++代码转换为“理论上最优”的代码是一厢情愿的想法。如果你关心这个低级别的“性能”，你必须知道你使用的编译器和工具链。
C/ c++中的编译器通常不太擅长重新排序子表达式，因为对于初学者来说，函数有副作用。函数式语言没有受到这个警告的影响，但它不太适合当前的生态系统。有一些编译器选项可以允许宽松的精确规则，允许编译器/链接器/代码生成器改变操作的顺序。
这个话题有点死路一条;对于大多数人来说，这是无关紧要的，而剩下的人，他们已经知道自己在做什么了。
这一切都归结为:“理解你在做什么”，这与知道你在做什么有点不同。
我需要对192位或256位的每次中断进行移位操作，每50微秒发生一次。
它通过一个固定的映射(硬件限制)实现。使用C语言，制作它只需要大约10微秒。当我把它翻译到Assembler时，考虑到这个映射的特定特性，特定的寄存器缓存，并使用面向位的操作;它只花了不到3.5微秒的时间。
我不能给出具体的例子，因为那是很多年前的事情了，但是在很多情况下，手工编写的汇编程序可以胜过任何编译器。原因:
您可以偏离调用约定，在寄存器中传递参数。 您可以仔细考虑如何使用寄存器，避免将变量存储在内存中。 对于跳转表之类的东西，可以避免检查索引的边界。
基本上，编译器在优化方面做得很好，这几乎总是“足够好”，但在某些情况下(如图形渲染)，你要为每一个周期付出高昂的代价，你可以走捷径，因为你知道代码，而编译器不能，因为它必须在安全的方面。
事实上，我听说过一些图形渲染代码，其中一个例程，如直线绘制或多边形填充例程，实际上在堆栈上生成了一小块机器代码并在那里执行，以避免关于线条样式、宽度、模式等的连续决策。
也就是说，我想让编译器为我生成好的汇编代码，但又不太聪明，它们通常都是这样做的。事实上，我讨厌Fortran的一个原因是它为了“优化”而打乱代码，通常没有什么重要的目的。
通常，当应用程序出现性能问题时，都是由于浪费的设计造成的。这些天，我永远不会推荐汇编程序的性能，除非整个应用程序已经在它的生命周期内进行了调优，仍然不够快，并且把所有的时间都花在了紧凑的内部循环中。
补充:我见过很多用汇编语言编写的应用程序，与C、Pascal、Fortran等语言相比，汇编语言的主要速度优势是因为程序员在用汇编语言编码时要谨慎得多。他或她每天要写大约100行代码，不管哪种语言，在编译器语言中，这将等于3或400条指令。
