了解汇编程序的原因之一是，有时可以使用汇编程序来编写比用高级语言(特别是C语言)编写的代码性能更好的代码。然而，我也听人说过很多次，尽管这并非完全错误，但实际上可以使用汇编程序来生成性能更好的代码的情况极其罕见，并且需要汇编方面的专业知识和经验。
这个问题甚至没有涉及到这样一个事实，即汇编程序指令将是特定于机器的、不可移植的，或者汇编程序的任何其他方面。当然，除了这一点之外，了解汇编还有很多很好的理由，但这是一个需要示例和数据的具体问题，而不是关于汇编程序与高级语言的扩展论述。
谁能提供一些具体的例子，说明使用现代编译器汇编代码比编写良好的C代码更快，并且您能否用分析证据支持这一说法?我相信这些案例确实存在，但我真的很想知道这些案例到底有多深奥，因为这似乎是一个有争议的问题。
当前回答
只要有合适的程序员，汇编程序总是可以比C程序快(至少稍微快一点)。如果不能从汇编器中取出至少一条指令，则很难创建一个C程序。
其他回答
长波克，只有一个限制时间。当你没有足够的资源来优化每一个代码的变化，并花时间分配寄存器，优化一些溢出和诸如此类的事情时，编译器每次都会赢。对代码进行修改、重新编译和度量。如有必要重复。
此外，你可以在高水平方面做很多事情。此外，检查生成的程序集可能会给人一种代码是垃圾的印象，但实际上它的运行速度比您想象的要快。例子:
Int y = data[i]; //在这里做一些事情。 call_function (y,…);
编译器将读取数据，将其推入堆栈(溢出)，然后从堆栈读取并作为参数传递。听起来屎?它实际上可能是非常有效的延迟补偿，并导致更快的运行时。
//优化版本 call_function(数据[我],…);//毕竟不是那么优化。
优化版本的想法是，我们降低了寄存器压力，避免溢出。但事实上，“垃圾”版本更快!
看看汇编代码，只看指令，然后得出结论:指令越多，速度越慢，这将是一个错误的判断。
这里需要注意的是:许多组装专家认为他们知道很多，但知道的很少。规则也会随着架构的变化而变化。例如，x86代码并不存在总是最快的银弹。如今，最好还是按照经验法则行事:
记忆很慢 缓存速度快 尽量更好地使用缓存 你多久会错过一次?你有延迟补偿策略吗? 对于一个cache miss，你可以执行10-100个ALU/FPU/SSE指令 应用程序架构很重要。 . .但是当问题不在架构上时，它就没有帮助了
此外，过于相信编译器会神奇地将考虑不周到的C/ c++代码转换为“理论上最优”的代码是一厢情愿的想法。如果你关心这个低级别的“性能”，你必须知道你使用的编译器和工具链。
C/ c++中的编译器通常不太擅长重新排序子表达式，因为对于初学者来说，函数有副作用。函数式语言没有受到这个警告的影响，但它不太适合当前的生态系统。有一些编译器选项可以允许宽松的精确规则，允许编译器/链接器/代码生成器改变操作的顺序。
这个话题有点死路一条;对于大多数人来说，这是无关紧要的，而剩下的人，他们已经知道自己在做什么了。
这一切都归结为:“理解你在做什么”，这与知道你在做什么有点不同。
我曾经和一个人一起工作过，他说“如果编译器笨到不能弄清楚你要做什么，并且不能优化它，那么你的编译器就坏了，是时候换一个新的了”。我确信在某些情况下汇编程序会打败你的C代码，但是如果你发现自己经常使用汇编程序来“赢得”编译器，那么你的编译器就完蛋了。
对于编写试图强制查询计划器执行操作的“优化”SQL也是如此。如果您发现自己重新安排查询以让计划器执行您想要的操作，那么您的查询计划器就完蛋了——请更换一个新的计划器。
如果您没有查看编译器生成的内容的反汇编，您实际上无法知道编写良好的C代码是否真的很快。很多时候你会发现“写得好”是主观的。
因此，没有必要用汇编程序来获得最快的代码，但出于同样的原因，了解汇编程序当然是值得的。
http://cr.yp.to/qhasm.html有很多例子。
The question is a bit misleading. The answer is there in your post itself. It is always possible to write assembly solution for a particular problem which executes faster than any generated by a compiler. The thing is you need to be an expert in assembly to overcome the limitations of a compiler. An experienced assembly programmer can write programs in any HLL which performs faster than one written by an inexperienced. The truth is you can always write assembly programs executing faster than one generated by a compiler.
