了解汇编程序的原因之一是，有时可以使用汇编程序来编写比用高级语言(特别是C语言)编写的代码性能更好的代码。然而，我也听人说过很多次，尽管这并非完全错误，但实际上可以使用汇编程序来生成性能更好的代码的情况极其罕见，并且需要汇编方面的专业知识和经验。
这个问题甚至没有涉及到这样一个事实，即汇编程序指令将是特定于机器的、不可移植的，或者汇编程序的任何其他方面。当然，除了这一点之外，了解汇编还有很多很好的理由，但这是一个需要示例和数据的具体问题，而不是关于汇编程序与高级语言的扩展论述。
谁能提供一些具体的例子，说明使用现代编译器汇编代码比编写良好的C代码更快，并且您能否用分析证据支持这一说法?我相信这些案例确实存在，但我真的很想知道这些案例到底有多深奥，因为这似乎是一个有争议的问题。
当前回答
C语言常常需要做一些从汇编编码员的角度看来不必要的事情，这只是因为C标准这么说。
例如，整数提升。如果你想在C语言中移动一个char变量，人们通常会期望代码实际上只做一个比特的移动。
然而，标准强制编译器在移位之前将符号扩展为int，然后将结果截断为char，这可能会使代码复杂化，这取决于目标处理器的架构。
其他回答
第一点不是答案。 即使你从来没有用它编程，我发现至少知道一个汇编指令集是有用的。这是程序员永无止境的追求的一部分，他们想知道得更多，从而变得更好。当你进入一个没有源代码的框架时，它也很有用，至少对正在发生的事情有一个粗略的了解。它还可以帮助您理解JavaByteCode和. net IL，因为它们都类似于汇编程序。
To answer the question when you have a small amount of code or a large amount of time. Most useful for use in embedded chips, where low chip complexity and poor competition in compilers targeting these chips can tip the balance in favour of humans. Also for restricted devices you are often trading off code size/memory size/performance in a way that would be hard to instruct a compiler to do. e.g. I know this user action is not called often so I will have small code size and poor performance, but this other function that look similar is used every second so I will have a larger code size and faster performance. That is the sort of trade off a skilled assembly programmer can use.
我还想补充一点，这里有很多中间地带，您可以用C编译代码并检查生成的程序集，然后更改C代码或调整并作为程序集进行维护。
我的朋友从事微控制器的工作，目前是用于控制小型电动机的芯片。他在低级c和汇编的组合中工作。他曾经告诉我，有一天他在工作中把主循环从48条指令减少到43条。他还面临着各种选择，比如代码已经增长到填满256k芯片，业务需要一个新功能，你呢
删除现有功能 减少部分或全部现有特性的大小，可能会以性能为代价。 提倡改用成本更高、功耗更高、外形更大的更大芯片。
我想补充一点，作为一个商业开发人员，我有很多的投资组合或语言、平台、应用程序类型，我从来没有觉得有必要深入编写程序集。我一直都很感激我所学到的知识。有时会被调试进去。
我知道我已经回答了“为什么我要学习汇编器”这个问题，但我觉得这是一个更重要的问题，而不是什么时候更快。
所以让我们再试一次 你应该考虑组装
致力于底层操作系统功能 在编译器上工作。 工作在一个极其有限的芯片，嵌入式系统等
记住比较你的程序集和生成的编译器，看看哪个更快/更小/更好。
大卫。
我需要对192位或256位的每次中断进行移位操作，每50微秒发生一次。
它通过一个固定的映射(硬件限制)实现。使用C语言，制作它只需要大约10微秒。当我把它翻译到Assembler时，考虑到这个映射的特定特性，特定的寄存器缓存，并使用面向位的操作;它只花了不到3.5微秒的时间。
在我的工作中，有三个原因让我了解和使用组装。按重要性排序:
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.
在运行时创建机器代码怎么样?
我的兄弟曾经(大约在2000年)通过在运行时生成代码实现了一个非常快速的实时光线跟踪器。我不记得细节了，但有一些主模块是通过对象循环的，然后它准备和执行一些特定于每个对象的机器代码。
然而，随着时间的推移，这种方法被新的图形硬件淘汰，变得毫无用处。
今天，我认为大数据(数百万条记录)上的一些操作，如数据透视表、钻孔、实时计算等，都可以用这种方法进行优化。问题是:这样的努力值得吗?
紧密循环，就像处理图像时一样，因为一张图像可能需要数百万像素。坐下来研究一下如何最好地利用有限的处理器寄存器会有很大的不同。下面是一个真实的例子:
http://danbystrom.se/2008/12/22/optimizing-away-ii/
处理器通常有一些深奥的指令，这些指令对于编译器来说太专业了，但有时汇编程序员可以很好地利用它们。以XLAT指令为例。如果您需要在循环中进行表查找，并且表限制在256字节，那么这非常棒!
更新:哦，当我们谈论一般循环时，最关键的是:编译器通常不知道常见情况下会有多少次迭代!只有程序员知道一个循环会被迭代很多次，因此用一些额外的工作来准备循环是有益的，或者如果它迭代的次数太少，以至于设置实际花费的时间比预期的迭代要长。
