我记得在某处读到过，为了真正优化和加速代码的某些部分，程序员用汇编语言编写了该部分。我的问题是——
这个练习还做吗？以及如何做到这一点？ 用汇编语言编写是不是有点太麻烦和过时了？ 当我们编译 C 代码(有或没有 -O3 标志)时，编译器会做一些代码优化 & 链接所有库 & 将代码转换为二进制目标文件。所以当我们运行程序时，它已经是最基本的形式，即二进制。那么诱导“汇编语言”有什么帮助呢？ 我正在尝试理解这个概念，非常感谢任何帮助或链接。
更新:按照 dbemerlin 的要求改写第 3 点-因为您可能能够编写比编译器生成的更有效的汇编代码，但除非您是汇编专家，否则您的代码可能会运行得更慢，因为编译器通常比大多数人能更好地优化代码。
恢复到汇编语言唯一有用的时候是
CPU 指令在 C++ 中没有等效的功能(例如单指令多数据指令、BCD 或十进制算术运算)
并且编译器没有提供额外的函数来包装这些操作(例如，C++11 标准有 atomic operations 包括 compare-and-swap ，<cstdlib> 有 div / ldiv 等，用于有效地获得商和余数)并且没有好的第三方库(例如 http://mitpress.mit.edu/catalog/item/default.asp?tid=3952&ttype=2 )或
出于某种莫名其妙的原因 - 优化器未能使用最佳 CPU 指令 ...和...
使用这些 CPU 指令将为瓶颈代码提供一些显着且有用的性能提升。 简单地使用内联汇编来执行可以很容易地用 C++ 表达的操作——比如添加两个值或在字符串中搜索——会适得其反，因为:
编译器知道如何同样好地做到这一点
要验证这一点，请查看其汇编输出(例如 gcc -S )或反汇编机器代码 您人为地限制了它在寄存器分配、CPU 指令等方面的选择，因此使用执行硬编码指令所需的值来准备 CPU 寄存器可能需要更长的时间，然后需要更长的时间才能恢复到 future 指令的最佳分配
编译器优化器可以在指定不同寄存器的等效性能指令之间进行选择以最大程度地减少它们之间的复制，并且可以以这样的方式选择寄存器，即单个内核可以在一个周期内处理多条指令，而强制所有内容通过特定寄存器将序列化它
公平地说，GCC 有办法表达对特定类型寄存器的需求，而无需将 CPU 限制为精确的寄存器，仍然允许进行此类优化，但它是我见过的唯一解决此问题的内联程序集 如果明年推出新的 CPU 模型，其中另一条指令对于相同的逻辑运算速度提高 1000%，那么编译器供应商更有可能更新他们的编译器以使用该指令，因此您的程序在重新编译后将比您受益(或当时维护软件的人)编译器将为其所告知的目标体系结构选择最佳方法:如果您对一个解决方案进行硬编码，则它需要是最低公分母或 #ifdef -ed 适用于您的平台 汇编语言不像 C++ 那样可移植，无论是跨 CPU 还是跨编译器，即使您看似移植了一条指令，也有可能在重新注册对破坏安全的寄存器、参数传递约定等方面犯错。其他程序员可能不知道或不习惯汇编 我认为值得牢记的一个观点是，当 C 被引入时，它必须赢得许多对生成的机器代码大惊小怪的铁杆汇编语言程序员。那时机器的 CPU 能力和 RAM 较少，你可以打赌人们会为最微小的事情大惊小怪。优化器变得非常复杂并不断改进，而像 x86 这样的处理器的汇编语言变得越来越复杂，它们的执行管道、缓存和其他影响其性能的因素也变得越来越复杂。您不能再从每条指令的周期表中添加值了。编译器编写者花时间考虑所有这些微妙的因素(尤其是那些为 CPU 制造商工作的因素，但这也会增加其他编译器的压力)。现在对于汇编程序员来说，在任何非平凡的应用程序中平均比一个好的优化编译器生成的代码效率要高得多是不切实际的，而且他们极有可能做得更糟。因此，组件的使用应仅限于真正产生可衡量和有用差异的次数，值得耦合和维护成本。