这很难具体地回答，因为这个问题非常不具体:到底什么是“现代编译器”?

理论上，几乎任何手动的汇编器优化都可以由编译器来完成——实际上它是否已经完成，不能笼统地说，只能说特定编译器的特定版本。许多可能需要花费大量的精力来确定它们是否可以在特定的上下文中应用而不产生副作用，以至于编译器编写者不会为它们烦恼。

以下是我个人经历中的几个例子:

Access to instructions that are not accessible from C. For instance, many architectures (like x86-64, IA-64, DEC Alpha, and 64-bit MIPS or PowerPC) support a 64 bit by 64 bit multiplication producing a 128 bit result. GCC recently added an extension providing access to such instructions, but before that assembly was required. And access to this instruction can make a huge difference on 64-bit CPUs when implementing something like RSA - sometimes as much as a factor of 4 improvement in performance. Access to CPU-specific flags. The one that has bitten me a lot is the carry flag; when doing a multiple-precision addition, if you don't have access to the CPU carry bit one must instead compare the result to see if it overflowed, which takes 3-5 more instructions per limb; and worse, which are quite serial in terms of data accesses, which kills performance on modern superscalar processors. When processing thousands of such integers in a row, being able to use addc is a huge win (there are superscalar issues with contention on the carry bit as well, but modern CPUs deal pretty well with it). SIMD. Even autovectorizing compilers can only do relatively simple cases, so if you want good SIMD performance it's unfortunately often necessary to write the code directly. Of course you can use intrinsics instead of assembly but once you're at the intrinsics level you're basically writing assembly anyway, just using the compiler as a register allocator and (nominally) instruction scheduler. (I tend to use intrinsics for SIMD simply because the compiler can generate the function prologues and whatnot for me so I can use the same code on Linux, OS X, and Windows without having to deal with ABI issues like function calling conventions, but other than that the SSE intrinsics really aren't very nice - the Altivec ones seem better though I don't have much experience with them). As examples of things a (current day) vectorizing compiler can't figure out, read about bitslicing AES or SIMD error correction - one could imagine a compiler that could analyze algorithms and generate such code, but it feels to me like such a smart compiler is at least 30 years away from existing (at best).

On the other hand, multicore machines and distributed systems have shifted many of the biggest performance wins in the other direction - get an extra 20% speedup writing your inner loops in assembly, or 300% by running them across multiple cores, or 10000% by running them across a cluster of machines. And of course high level optimizations (things like futures, memoization, etc) are often much easier to do in a higher level language like ML or Scala than C or asm, and often can provide a much bigger performance win. So, as always, there are tradeoffs to be made.

在我的工作中，有三个原因让我了解和使用组装。按重要性排序:

Debugging - I often get library code that has bugs or incomplete documentation. I figure out what it's doing by stepping in at the assembly level. I have to do this about once a week. I also use it as a tool to debug problems in which my eyes don't spot the idiomatic error in C/C++/C#. Looking at the assembly gets past that. Optimizing - the compiler does fairly well in optimizing, but I play in a different ballpark than most. I write image processing code that usually starts with code that looks like this: for (int y=0; y < imageHeight; y++) { for (int x=0; x < imageWidth; x++) { // do something } } the "do something part" typically happens on the order of several million times (ie, between 3 and 30). By scraping cycles in that "do something" phase, the performance gains are hugely magnified. I don't usually start there - I usually start by writing the code to work first, then do my best to refactor the C to be naturally better (better algorithm, less load in the loop etc). I usually need to read assembly to see what's going on and rarely need to write it. I do this maybe every two or three months. doing something the language won't let me. These include - getting the processor architecture and specific processor features, accessing flags not in the CPU (man, I really wish C gave you access to the carry flag), etc. I do this maybe once a year or two years.

这个问题有点毫无意义，因为无论如何c都是编译到汇编程序的。 但是，通过优化编译器生成的汇编程序几乎是完全优化的，所以除非你在优化特定的汇编程序方面做了20个博士学位，否则你无法打败编译器。

我认为汇编程序更快的一般情况是，当一个聪明的汇编程序员看到编译器的输出并说“这是性能的关键路径，我可以写这个更有效”，然后那个人调整汇编程序或从头重写它。

下面是一个真实的例子:固定点在旧编译器上进行乘法运算。

这些不仅在没有浮点数的设备上很方便，在精度方面也很出色，因为它们可以提供32位精度和可预测的错误(浮点数只有23位，很难预测精度损失)。即在整个范围内均匀的绝对精度，而不是接近均匀的相对精度(浮点数)。

---

现代编译器很好地优化了这个定点示例，因此对于仍然需要特定于编译器的代码的更现代的示例，请参见

获得64位整数乘法的高部分:使用uint64_t for 32x32 => 64位乘法的便携版本在64位CPU上无法优化，因此你需要intrinsic或__int128来在64位系统上实现高效的代码。 Windows 32位上的_umul128: MSVC在将32位整数转换为64时并不总是做得很好，因此intrinsic有很大帮助。

---

C语言没有完整的乘法运算符(由n位输入产生2n位)。在C语言中表达它的通常方法是将输入转换为更宽的类型，并希望编译器能够识别输入的上半部分是不有趣的:

// on a 32-bit machine, int can hold 32-bit fixed-point integers.
int inline FixedPointMul (int a, int b)
{
  long long a_long = a; // cast to 64 bit.

  long long product = a_long * b; // perform multiplication

  return (int) (product >> 16);  // shift by the fixed point bias
}

这段代码的问题在于，我们做了一些不能直接用c语言表达的事情。我们希望将两个32位的数字相乘，得到一个64位的结果，并返回中间的32位。然而，在C语言中这个乘法是不存在的。您所能做的就是将整数提升为64位，并执行64*64 = 64乘法。

x86(以及ARM、MIPS和其他)可以在一条指令中完成乘法运算。一些编译器过去常常忽略这一事实，并生成调用运行时库函数来进行相乘的代码。移位到16也经常由库例程完成(x86也可以做这样的移位)。

所以我们只剩下一两个乘法库调用。这造成了严重的后果。不仅移位速度较慢，而且在整个函数调用中必须保留寄存器，而且对内联和展开代码也没有帮助。

如果你在(内联)汇编器中重写相同的代码，你可以获得显著的速度提升。

除此之外:使用ASM并不是解决问题的最佳方法。大多数编译器允许你以内在的形式使用一些汇编指令，如果你不能用c语言表达它们。例如，VS.NET2008编译器将32*32=64位的mul公开为__emul，将64位的移位公开为__ll_rshift。

使用intrinsic，你可以以一种c编译器有机会理解发生了什么的方式重写函数。这允许代码内联，寄存器分配，公共子表达式消除和常量传播也可以完成。与手工编写的汇编程序代码相比，您将获得巨大的性能改进。

供参考:VS.NET编译器的定点mul的最终结果是:

int inline FixedPointMul (int a, int b)
{
    return (int) __ll_rshift(__emul(a,b),16);
}

定点除法的性能差异更大。通过编写几行asm代码，我对除法重的定点代码进行了10倍的改进。

---

使用Visual c++ 2013为这两种方式提供了相同的汇编代码。

2007年的gcc4.1也很好地优化了纯C版本。(Godbolt编译器资源管理器没有安装任何早期版本的gcc，但即使是较旧的gcc版本也可以在没有intrinsic的情况下做到这一点。)

在Godbolt编译器资源管理器上查看用于x86(32位)和ARM的source + asm。(不幸的是，它没有任何旧到足以从简单的纯C版本生成糟糕代码的编译器。)

---

现代cpu可以做一些C语言根本没有操作符的事情，比如popcnt或位扫描来查找第一个或最后一个设置位。POSIX有一个ffs()函数，但是它的语义不匹配x86 bsf / bsr。见https://en.wikipedia.org/wiki/Find_first_set)。

一些编译器有时可以识别一个计数整数中设置位数的循环，并将其编译为popcnt指令(如果在编译时启用)，但在GNU C中使用__builtin_popcnt要可靠得多，或者在x86上(如果你的目标硬件是SSE4.2: _mm_popcnt_u32 from < immintrinh >)。

或者在c++中，赋值给std::bitset<32>并使用.count()。(在这种情况下，该语言已经找到了一种方法，可以通过标准库可移植地公开popcount的优化实现，以一种总是编译为正确的方式，并且可以利用目标支持的任何东西。)参见https://en.wikipedia.org/wiki/Hamming_weight#Language_support。

类似地，ntohl可以在一些具有它的C实现上编译为bswap(用于端序转换的x86 32位字节交换)。

---

intrinsic或手写asm的另一个主要领域是使用SIMD指令进行手工向量化。编译器对于dst[i] += src[i] * 10.0;这样的简单循环并不糟糕，但是当事情变得更复杂时，编译器通常做得很糟糕，或者根本不自动向量化。例如，你不太可能得到任何像如何实现atoi使用SIMD?由编译器从标量代码自动生成。