了解汇编程序的原因之一是，有时可以使用汇编程序来编写比用高级语言(特别是C语言)编写的代码性能更好的代码。然而，我也听人说过很多次，尽管这并非完全错误，但实际上可以使用汇编程序来生成性能更好的代码的情况极其罕见，并且需要汇编方面的专业知识和经验。
这个问题甚至没有涉及到这样一个事实，即汇编程序指令将是特定于机器的、不可移植的，或者汇编程序的任何其他方面。当然，除了这一点之外，了解汇编还有很多很好的理由，但这是一个需要示例和数据的具体问题，而不是关于汇编程序与高级语言的扩展论述。
谁能提供一些具体的例子，说明使用现代编译器汇编代码比编写良好的C代码更快，并且您能否用分析证据支持这一说法?我相信这些案例确实存在，但我真的很想知道这些案例到底有多深奥，因为这似乎是一个有争议的问题。
当前回答
使用SIMD指令的矩阵操作可能比编译器生成的代码更快。
其他回答
这个问题有点毫无意义，因为无论如何c都是编译到汇编程序的。 但是，通过优化编译器生成的汇编程序几乎是完全优化的，所以除非你在优化特定的汇编程序方面做了20个博士学位，否则你无法打败编译器。
这完全取决于你的工作量。
对于日常操作，C和c++已经很好了，但是有一些特定的工作负载(任何涉及视频的转换(压缩、解压缩、图像效果等))几乎需要组装才能达到性能。
它们通常还涉及使用特定于CPU的芯片组扩展(MME/MMX/SSE/等等)，这些扩展是为这些类型的操作而优化的。
在我的工作中，有三个原因让我了解和使用组装。按重要性排序:
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.
简短的回答吗?有时。
从技术上讲，每一个抽象都有成本，而编程语言是CPU如何工作的抽象。然而C非常接近。几年前，我记得当我登录UNIX帐户并收到以下财富信息时(当时这种东西很流行)，我笑出声来:
C程序设计语言——A 语言结合了 汇编语言的灵活性 汇编语言的强大。
这很有趣，因为这是真的:C就像可移植的汇编语言。
值得注意的是，汇编语言无论如何编写都可以运行。然而，在C语言和它生成的汇编语言之间有一个编译器，这是非常重要的，因为你的C代码有多快与你的编译器有多好有很大关系。
当gcc出现时，它如此受欢迎的原因之一是它通常比许多商业UNIX版本附带的C编译器要好得多。它不仅是ANSI C(没有任何K&R C的垃圾)，更健壮，通常能产生更好(更快)的代码。不是总是，而是经常。
我告诉你这一切是因为没有关于C和汇编器速度的统一规则，因为C没有客观的标准。
同样地，汇编程序也会根据你正在运行的处理器、你的系统规格、你正在使用的指令集等而有很大的不同。历史上有两个CPU体系结构家族:CISC和RISC。CISC中最大的玩家过去是，现在仍然是Intel x86架构(和指令集)。RISC主宰了UNIX世界(MIPS6000、Alpha、Sparc等等)。CISC赢得了民心之战。
不管怎样，当我还是一个年轻的开发人员时，流行的观点是，手写的x86通常比C快得多，因为架构的工作方式，它的复杂性受益于人类的操作。另一方面，RISC似乎是为编译器设计的，所以没有人(我知道)写Sparc汇编器。我相信这样的人确实存在，但毫无疑问，他们现在都疯了，被送进了精神病院。
指令集是一个重要的点，即使在同一家族的处理器。某些英特尔处理器具有SSE到SSE4等扩展。AMD有他们自己的SIMD指令。像C这样的编程语言的好处是，人们可以编写他们的库，以便对您运行的任何处理器进行优化。这在汇编程序中是一项艰苦的工作。
你仍然可以在汇编程序中做一些编译器无法做的优化，一个编写良好的汇编程序算法将会和它的C等效程序一样快或更快。更大的问题是:这样做值得吗?
Ultimately though assembler was a product of its time and was more popular at a time when CPU cycles were expensive. Nowadays a CPU that costs $5-10 to manufacture (Intel Atom) can do pretty much anything anyone could want. The only real reason to write assembler these days is for low level things like some parts of an operating system (even so the vast majority of the Linux kernel is written in C), device drivers, possibly embedded devices (although C tends to dominate there too) and so on. Or just for kicks (which is somewhat masochistic).
GCC已经成为广泛使用的编译器。它的优化通常不是很好。比编写汇编程序的普通程序员好得多，但就实际性能而言，并没有那么好。有些编译器产生的代码简直令人难以置信。所以一般来说，有很多地方你可以进入编译器的输出，调整汇编器的性能，和/或简单地从头重写例程。
