我不能给出具体的例子，因为那是很多年前的事情了，但是在很多情况下，手工编写的汇编程序可以胜过任何编译器。原因:

您可以偏离调用约定，在寄存器中传递参数。 您可以仔细考虑如何使用寄存器，避免将变量存储在内存中。 对于跳转表之类的东西，可以避免检查索引的边界。

基本上，编译器在优化方面做得很好，这几乎总是“足够好”，但在某些情况下(如图形渲染)，你要为每一个周期付出高昂的代价，你可以走捷径，因为你知道代码，而编译器不能，因为它必须在安全的方面。

事实上，我听说过一些图形渲染代码，其中一个例程，如直线绘制或多边形填充例程，实际上在堆栈上生成了一小块机器代码并在那里执行，以避免关于线条样式、宽度、模式等的连续决策。

也就是说，我想让编译器为我生成好的汇编代码，但又不太聪明，它们通常都是这样做的。事实上，我讨厌Fortran的一个原因是它为了“优化”而打乱代码，通常没有什么重要的目的。

通常，当应用程序出现性能问题时，都是由于浪费的设计造成的。这些天，我永远不会推荐汇编程序的性能，除非整个应用程序已经在它的生命周期内进行了调优，仍然不够快，并且把所有的时间都花在了紧凑的内部循环中。

补充:我见过很多用汇编语言编写的应用程序，与C、Pascal、Fortran等语言相比，汇编语言的主要速度优势是因为程序员在用汇编语言编码时要谨慎得多。他或她每天要写大约100行代码，不管哪种语言，在编译器语言中，这将等于3或400条指令。

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.

在Amiga上，CPU和图形/音频芯片会为了访问特定区域的RAM(具体来说是前2MB的RAM)而争斗。因此，当你只有2MB RAM(或更少)时，显示复杂的图形加上播放声音会杀死CPU的性能。

在汇编程序中，你可以巧妙地交错你的代码，使CPU只在图形/音频芯片内部繁忙时(即当总线空闲时)才尝试访问RAM。因此，通过重新排序指令，巧妙地使用CPU缓存，总线定时，你可以实现一些使用任何高级语言都不可能实现的效果，因为你必须为每个命令定时，甚至在这里或那里插入nop，以使不同的芯片不受彼此的雷达影响。

这也是为什么CPU的NOP (No Operation -什么都不做)指令实际上可以让你的整个应用程序运行得更快的另一个原因。

当然，这种技术取决于特定的硬件设置。这就是为什么许多Amiga游戏无法适应更快的cpu的主要原因:指令的计时错误。

我很惊讶居然没人这么说。如果用汇编编写strlen()函数，速度会快得多!在C中，你能做的最好的事情就是

int c;
for(c = 0; str[c] != '\0'; c++) {}

在组装过程中，你可以大大加快速度:

mov esi, offset string
mov edi, esi
xor ecx, ecx

lp:
mov ax, byte ptr [esi]
cmp al, cl
je  end_1
cmp ah, cl
je end_2
mov bx, byte ptr [esi + 2]
cmp bl, cl
je end_3
cmp bh, cl
je end_4
add esi, 4
jmp lp

end_4:
inc esi

end_3:
inc esi

end_2:
inc esi

end_1:
inc esi

mov ecx, esi
sub ecx, edi

长度单位是ecx。这一次比较4个字符，所以速度快4倍。并且考虑使用eax和ebx的高阶词，它将比之前的C例程快8倍!

几乎任何时候编译器看到浮点代码，如果你使用的是旧的糟糕的编译器，手写的版本会更快。(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更快!)修正并更新了结果。

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