在运行时创建机器代码怎么样?

我的兄弟曾经(大约在2000年)通过在运行时生成代码实现了一个非常快速的实时光线跟踪器。我不记得细节了，但有一些主模块是通过对象循环的，然后它准备和执行一些特定于每个对象的机器代码。

然而，随着时间的推移，这种方法被新的图形硬件淘汰，变得毫无用处。

今天，我认为大数据(数百万条记录)上的一些操作，如数据透视表、钻孔、实时计算等，都可以用这种方法进行优化。问题是:这样的努力值得吗?

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

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.

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

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

使用SIMD指令的矩阵操作可能比编译器生成的代码更快。

The question is a bit misleading. The answer is there in your post itself. It is always possible to write assembly solution for a particular problem which executes faster than any generated by a compiler. The thing is you need to be an expert in assembly to overcome the limitations of a compiler. An experienced assembly programmer can write programs in any HLL which performs faster than one written by an inexperienced. The truth is you can always write assembly programs executing faster than one generated by a compiler.

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

这些不仅在没有浮点数的设备上很方便，在精度方面也很出色，因为它们可以提供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?由编译器从标量代码自动生成。