了解汇编程序的原因之一是，有时可以使用汇编程序来编写比用高级语言(特别是C语言)编写的代码性能更好的代码。然而，我也听人说过很多次，尽管这并非完全错误，但实际上可以使用汇编程序来生成性能更好的代码的情况极其罕见，并且需要汇编方面的专业知识和经验。
这个问题甚至没有涉及到这样一个事实，即汇编程序指令将是特定于机器的、不可移植的，或者汇编程序的任何其他方面。当然，除了这一点之外，了解汇编还有很多很好的理由，但这是一个需要示例和数据的具体问题，而不是关于汇编程序与高级语言的扩展论述。
谁能提供一些具体的例子，说明使用现代编译器汇编代码比编写良好的C代码更快，并且您能否用分析证据支持这一说法?我相信这些案例确实存在，但我真的很想知道这些案例到底有多深奥，因为这似乎是一个有争议的问题。
当前回答
在Amiga上，CPU和图形/音频芯片会为了访问特定区域的RAM(具体来说是前2MB的RAM)而争斗。因此，当你只有2MB RAM(或更少)时，显示复杂的图形加上播放声音会杀死CPU的性能。
在汇编程序中，你可以巧妙地交错你的代码，使CPU只在图形/音频芯片内部繁忙时(即当总线空闲时)才尝试访问RAM。因此，通过重新排序指令，巧妙地使用CPU缓存，总线定时，你可以实现一些使用任何高级语言都不可能实现的效果，因为你必须为每个命令定时，甚至在这里或那里插入nop，以使不同的芯片不受彼此的雷达影响。
这也是为什么CPU的NOP (No Operation -什么都不做)指令实际上可以让你的整个应用程序运行得更快的另一个原因。
当然，这种技术取决于特定的硬件设置。这就是为什么许多Amiga游戏无法适应更快的cpu的主要原因:指令的计时错误。
其他回答
尽管C语言“接近”于对8位、16位、32位和64位数据的低级操作，但仍有一些C语言不支持的数学操作通常可以在某些汇编指令集中优雅地执行:
Fixed-point multiplication: The product of two 16-bit numbers is a 32-bit number. But the rules in C says that the product of two 16-bit numbers is a 16-bit number, and the product of two 32-bit numbers is a 32-bit number -- the bottom half in both cases. If you want the top half of a 16x16 multiply or a 32x32 multiply, you have to play games with the compiler. The general method is to cast to a larger-than-necessary bit width, multiply, shift down, and cast back: int16_t x, y; // int16_t is a typedef for "short" // set x and y to something int16_t prod = (int16_t)(((int32_t)x*y)>>16);` In this case the compiler may be smart enough to know that you're really just trying to get the top half of a 16x16 multiply and do the right thing with the machine's native 16x16multiply. Or it may be stupid and require a library call to do the 32x32 multiply that's way overkill because you only need 16 bits of the product -- but the C standard doesn't give you any way to express yourself. Certain bitshifting operations (rotation/carries): // 256-bit array shifted right in its entirety: uint8_t x[32]; for (int i = 32; --i > 0; ) { x[i] = (x[i] >> 1) | (x[i-1] << 7); } x[0] >>= 1; This is not too inelegant in C, but again, unless the compiler is smart enough to realize what you are doing, it's going to do a lot of "unnecessary" work. Many assembly instruction sets allow you to rotate or shift left/right with the result in the carry register, so you could accomplish the above in 34 instructions: load a pointer to the beginning of the array, clear the carry, and perform 32 8-bit right-shifts, using auto-increment on the pointer. For another example, there are linear feedback shift registers (LFSR) that are elegantly performed in assembly: Take a chunk of N bits (8, 16, 32, 64, 128, etc), shift the whole thing right by 1 (see above algorithm), then if the resulting carry is 1 then you XOR in a bit pattern that represents the polynomial.
尽管如此，除非有严重的性能限制，否则我不会求助于这些技术。正如其他人所说，汇编代码比C代码更难记录/调试/测试/维护:性能的提高伴随着一些严重的代价。
编辑:3。溢出检测在汇编中是可能的(在C中不能真正做到)，这使得一些算法更容易。
我曾经和一个人一起工作过，他说“如果编译器笨到不能弄清楚你要做什么，并且不能优化它，那么你的编译器就坏了，是时候换一个新的了”。我确信在某些情况下汇编程序会打败你的C代码，但是如果你发现自己经常使用汇编程序来“赢得”编译器，那么你的编译器就完蛋了。
对于编写试图强制查询计划器执行操作的“优化”SQL也是如此。如果您发现自己重新安排查询以让计划器执行您想要的操作，那么您的查询计划器就完蛋了——请更换一个新的计划器。
很多年前，我教别人用c语言编程。练习是将图形旋转90度。他得到了一个花了几分钟才能完成的解，主要是因为他使用了乘法和除法等。
我向他展示了如何使用位移位重定义问题，在他拥有的非优化编译器上，处理时间缩短到大约30秒。
我刚刚得到了一个优化编译器，相同的代码在< 5秒内旋转图形。我看着编译器生成的汇编代码，从我所看到的，我决定我写汇编程序的日子结束了。
这个问题有点毫无意义，因为无论如何c都是编译到汇编程序的。 但是，通过优化编译器生成的汇编程序几乎是完全优化的，所以除非你在优化特定的汇编程序方面做了20个博士学位，否则你无法打败编译器。
CP/M-86版本的PolyPascal (Turbo Pascal的兄弟)的一个可能性是用机器语言例程取代“使用生物将字符输出到屏幕上”的功能，本质上是给定x、y和字符串放在那里。
这使得更新屏幕的速度比以前快得多!
二进制文件中有足够的空间来嵌入机器代码(几百个字节)，也有其他的东西，所以尽可能多地压缩是必要的。
事实证明，由于屏幕是80x25，这两个坐标都可以容纳每个字节，所以都可以容纳两个字节的单词。这允许在更少的字节内完成所需的计算，因为单个添加可以同时操作两个值。
据我所知，没有C编译器可以在一个寄存器中合并多个值，对它们执行SIMD指令，然后再将它们分开(而且我不认为机器指令会更短)。
