我曾经和一个人一起工作过，他说“如果编译器笨到不能弄清楚你要做什么，并且不能优化它，那么你的编译器就坏了，是时候换一个新的了”。我确信在某些情况下汇编程序会打败你的C代码，但是如果你发现自己经常使用汇编程序来“赢得”编译器，那么你的编译器就完蛋了。

对于编写试图强制查询计划器执行操作的“优化”SQL也是如此。如果您发现自己重新安排查询以让计划器执行您想要的操作，那么您的查询计划器就完蛋了——请更换一个新的计划器。

紧密循环，就像处理图像时一样，因为一张图像可能需要数百万像素。坐下来研究一下如何最好地利用有限的处理器寄存器会有很大的不同。下面是一个真实的例子:

http://danbystrom.se/2008/12/22/optimizing-away-ii/

处理器通常有一些深奥的指令，这些指令对于编译器来说太专业了，但有时汇编程序员可以很好地利用它们。以XLAT指令为例。如果您需要在循环中进行表查找，并且表限制在256字节，那么这非常棒!

更新:哦，当我们谈论一般循环时，最关键的是:编译器通常不知道常见情况下会有多少次迭代!只有程序员知道一个循环会被迭代很多次，因此用一些额外的工作来准备循环是有益的，或者如果它迭代的次数太少，以至于设置实际花费的时间比预期的迭代要长。

几乎任何时候编译器看到浮点代码，如果你使用的是旧的糟糕的编译器，手写的版本会更快。(2019年更新:对于现代编译器来说，这并不普遍。特别是在编译x87以外的东西时;编译器更容易使用SSE2或AVX进行标量数学运算，或任何具有平面FP寄存器集的非x86，不像x87的寄存器堆栈。)

主要原因是编译器不能执行任何健壮的优化。关于这个主题的讨论，请参阅来自MSDN的这篇文章。下面是一个例子，其中汇编版本的速度是C版本的两倍(用VS2K5编译):

#include "stdafx.h"
#include <windows.h>

float KahanSum(const float *data, int n)
{
   float sum = 0.0f, C = 0.0f, Y, T;

   for (int i = 0 ; i < n ; ++i) {
      Y = *data++ - C;
      T = sum + Y;
      C = T - sum - Y;
      sum = T;
   }

   return sum;
}

float AsmSum(const float *data, int n)
{
  float result = 0.0f;

  _asm
  {
    mov esi,data
    mov ecx,n
    fldz
    fldz
l1:
    fsubr [esi]
    add esi,4
    fld st(0)
    fadd st(0),st(2)
    fld st(0)
    fsub st(0),st(3)
    fsub st(0),st(2)
    fstp st(2)
    fstp st(2)
    loop l1
    fstp result
    fstp result
  }

  return result;
}

int main (int, char **)
{
  int count = 1000000;

  float *source = new float [count];

  for (int i = 0 ; i < count ; ++i) {
    source [i] = static_cast <float> (rand ()) / static_cast <float> (RAND_MAX);
  }

  LARGE_INTEGER start, mid, end;

  float sum1 = 0.0f, sum2 = 0.0f;

  QueryPerformanceCounter (&start);

  sum1 = KahanSum (source, count);

  QueryPerformanceCounter (&mid);

  sum2 = AsmSum (source, count);

  QueryPerformanceCounter (&end);

  cout << "  C code: " << sum1 << " in " << (mid.QuadPart - start.QuadPart) << endl;
  cout << "asm code: " << sum2 << " in " << (end.QuadPart - mid.QuadPart) << endl;

  return 0;
}

和一些数字从我的PC运行默认版本*:

  C code: 500137 in 103884668
asm code: 500137 in 52129147

出于兴趣，我用dec/jnz交换了循环，它对计时没有影响——有时更快，有时更慢。我想内存有限的方面使其他优化相形见绌。(编者注:更可能的情况是，FP延迟瓶颈足以隐藏循环的额外成本。对奇数/偶数元素并行进行两个Kahan求和，并在最后添加它们，可能会加快2倍的速度。)

哎呀，我正在运行一个稍微不同的代码版本，它输出的数字是错误的(即C更快!)修正并更新了结果。

我想说的是，当你比编译器更擅长一组给定的指令时。所以我认为没有通用的答案

我已经阅读了所有的答案(超过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.

不需要给出任何具体的示例或分析器证据，当您比编译器知道的更多时，您可以编写比编译器更好的汇编程序。

In the general case, a modern C compiler knows much more about how to optimize the code in question: it knows how the processor pipeline works, it can try to reorder instructions quicker than a human can, and so on - it's basically the same as a computer being as good as or better than the best human player for boardgames, etc. simply because it can make searches within the problem space faster than most humans. Although you theoretically can perform as well as the computer in a specific case, you certainly can't do it at the same speed, making it infeasible for more than a few cases (i.e. the compiler will most certainly outperform you if you try to write more than a few routines in assembler).

另一方面，有些情况下编译器没有那么多的信息——我想说主要是在使用不同形式的外部硬件时，编译器不知道这些信息。主要的例子可能是设备驱动程序，其中汇编程序结合人类对相关硬件的熟悉知识可以产生比C编译器更好的结果。

其他人提到了特殊用途指令，这就是我在上面一段中所说的——编译器可能对这些指令了解有限或根本不了解，这使得人类可以编写更快的代码。