在处理器速度以MHz为单位，屏幕尺寸低于100万像素的时代，一个众所周知的更快显示的技巧是展开循环:为屏幕的每个扫描行写操作。它避免了维护循环索引的开销!再加上检测屏幕刷新，它非常有效。 这是C编译器不会做的事情……(虽然通常可以在速度优化和规模优化之间进行选择，但我认为前者使用了一些类似的技巧。)

我知道有些人喜欢用汇编语言编写Windows应用程序。他们声称他们更快(很难证明)和更小(确实如此!)。 显然，虽然这样做很有趣，但可能会浪费时间(当然，学习目的除外!)，特别是对于GUI操作…… 现在，也许某些操作(比如在文件中搜索字符串)可以通过精心编写的汇编代码进行优化。

长波克，只有一个限制时间。当你没有足够的资源来优化每一个代码的变化，并花时间分配寄存器，优化一些溢出和诸如此类的事情时，编译器每次都会赢。对代码进行修改、重新编译和度量。如有必要重复。

此外，你可以在高水平方面做很多事情。此外，检查生成的程序集可能会给人一种代码是垃圾的印象，但实际上它的运行速度比您想象的要快。例子:

Int y = data[i]; //在这里做一些事情。 call_function (y,…);

编译器将读取数据，将其推入堆栈(溢出)，然后从堆栈读取并作为参数传递。听起来屎?它实际上可能是非常有效的延迟补偿，并导致更快的运行时。

//优化版本 call_function(数据[我],…);//毕竟不是那么优化。

优化版本的想法是，我们降低了寄存器压力，避免溢出。但事实上，“垃圾”版本更快!

看看汇编代码，只看指令，然后得出结论:指令越多，速度越慢，这将是一个错误的判断。

这里需要注意的是:许多组装专家认为他们知道很多，但知道的很少。规则也会随着架构的变化而变化。例如，x86代码并不存在总是最快的银弹。如今，最好还是按照经验法则行事:

记忆很慢 缓存速度快 尽量更好地使用缓存 你多久会错过一次?你有延迟补偿策略吗? 对于一个cache miss，你可以执行10-100个ALU/FPU/SSE指令 应用程序架构很重要。 . .但是当问题不在架构上时，它就没有帮助了

此外，过于相信编译器会神奇地将考虑不周到的C/ c++代码转换为“理论上最优”的代码是一厢情愿的想法。如果你关心这个低级别的“性能”，你必须知道你使用的编译器和工具链。

C/ c++中的编译器通常不太擅长重新排序子表达式，因为对于初学者来说，函数有副作用。函数式语言没有受到这个警告的影响，但它不太适合当前的生态系统。有一些编译器选项可以允许宽松的精确规则，允许编译器/链接器/代码生成器改变操作的顺序。

这个话题有点死路一条;对于大多数人来说，这是无关紧要的，而剩下的人，他们已经知道自己在做什么了。

这一切都归结为:“理解你在做什么”，这与知道你在做什么有点不同。

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

只有在使用编译器不支持的特殊用途指令集时。

为了最大限度地利用具有多个管道和预测分支的现代CPU的计算能力，您需要以这样一种方式来构造汇编程序:a)人类几乎不可能编写b)甚至更不可能维护。

此外，更好的算法、数据结构和内存管理将为您提供至少一个数量级的性能，而不是在汇编中进行的微观优化。

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

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代码是否真的很快。很多时候你会发现“写得好”是主观的。

因此，没有必要用汇编程序来获得最快的代码，但出于同样的原因，了解汇编程序当然是值得的。