二进制翻译优化

二进制翻译中最关心的是翻译后程序性能。如果翻译后程序性能较差，不仅会影响用户的使用体验， 还会影响程序执行的正确性。如需要翻译的程序存在超时机制模块，二进制翻译性能较差可能会引发程序的超时错误， 使得程序无法正常运行。

开销来源

二进制翻译中开销往往来源于以下几个方面：

• 翻译过程的开销：动态二进制翻译的“边翻译边运行”的运行模式会引入翻译过程开销，尤其对含有大量冷代码的程序，翻译开销带来的影响较为明显；
• 指令膨胀带来的开销：翻译后指令数相较于翻译前指令数的增多，会带来最直接的性能降低，这也是是造成程序性能开销的主要原因；
• 间接跳转带来的开销：间接跳转需要通过多次上下文切换及查找才能完成，会导致巨量的指令膨胀，所以每次的间接跳转开销都是巨大的；
• 其他开销：上下文切换、基本块链接和系统调用等因素也会影响翻译后程序的性能。

研究方向

更加优秀的翻译后代码

为了得到更好的翻译后代码，有各种工作做了一些尝试。如Dynamo¹，通过识别热点路径并进行优化的方式，得到更优代码； 还有HQEMU²，通过加入LLVM，将热点块交给编译器进行优化。

针对现有LATX翻译器，实现了指令流分析制导的动态二进制翻译优化方案 IFADO（Instruction Flow Analysis Directing Optimization）。 主要有以下优化方案：

• EFLAGS 延迟（懒惰）计算
• “反馈式”指令语义化翻译
• SSE 标量指令高位运算消除

更低的翻译开销

翻译开销主要两方面：

1. 上下文切换的开销：动态二进制翻译器在执行的过程中，一直在不断地进行翻译态以及执行态的切换，这里的行为类似于内核的线程切换，需要将所有寄存器的状态进行保存。如果此过程较为频繁，则会导致较大的性能开销，现有动态二进制翻译器几乎都可以做到在指令翻译后，几乎无需返回翻译态。
2. 指令翻译过程的开销：动态二进制翻译需要在运行时，实时将客户程序的汇编代码翻译为宿主平台的汇编代码，对于常见的传统CPU性能测试机，如SPEC CPU, Coremark等，翻译时间占比不到1%，这使得翻译开销看起来似乎不那么重要。然而，实际应用中，往往程序会基于JIT技术动态生成二进制代码，这使得翻译器需要处理自修改代码，使得翻译部分的性能开销变得突出。

对于上述问题，目前实验室有两个探索方向：

1. AOT技术：通过保存上一次翻译出的代码，使得下一次执行时无需进行翻译。看起来很美好，能够较为简单的解决这一问题，但实际工程中，往往存在许多重定位代码，导致AOT文件的加载带来开销，使得此优化效果并不明显。
2. 优化翻译速度：二进制翻译器自身在翻译过程中的行为与普通程序并无差异，因此可以通过常见的性能分析手段进行性能优化，例如使用perf，观察翻译态的性能瓶颈，优化相关函数。

间接跳转优化

间接跳转指令是通过寄存器中的值作为跳转目标的跳转指令，例如函数调用的结尾往往使用间接跳转返回，这样能够更容易地实现任意位置对函数的调用。

然而，客户程序间接跳转是基于客户程序地址计算的，这导致了翻译执行的代码如果直接按寄存器内的地址进行跳转则会直接跳转至未翻译的客户程序，导致错误。

通用解决方案

• 哈希表：利用客户程序地址做哈希运算，索引翻译后的地址。

优化解决方案

• return类间接跳转：影子栈优化技术，在翻译call时，将客户地址和宿主地址按对存入影子栈中，返回时快速索引。
• jmp table类间接跳转：识别相应跳转表，将其中的客户地址翻译为宿主地址，然后直接跳转。
• funtion pointer类间接跳转：这类间接跳转的目标往往固定，因此每次跳转前，先优先查找历史项，能够优化间接跳转速度。

这里只列举了部分软件优化方案，可能的硬件优化方案可以查看实验室微译器相关的文档。

其他

再次感谢胡起的贡献。

Advisor(s)

Maintainer(s)

Contributor(s)