用于C/C ++的JIT优化器 [英] JIT optimizer for C/C++

问题描述

我正在阅读JIT优于预编译的优势，其中提到的一个优势是JIT可以根据实际的运行时数据来调整分支预测.自从我在大学写过一个编译器以来，已经有很长时间了，但是在我看来，在大多数情况下(没有明确的指令)，预编译代码也可以实现类似的目的.

I was reading about the advantages of JIT over precompiled and one of those mentioned was that a JIT could adjust branch predictions based on actual runtime data. Now it's been a long time since I wrote a compiler in college, but it seems to me that something similar can be achieved for precompiled code also in most cases (where there are no explicit gotos).

考虑以下代码:

   test x
   jne L2:
L1: ...
   jmp L3:
L2: ...
L3:

如果我们有一些运行时工具可以看到'jne L2'为真的次数，则它可以物理交换L1:块和L2:块中的所有指令.当然，它必须知道在交换过程中任何一个块内都没有线程，但是这些都是详细信息...

If we have some runtime instrumentation that sees how many times the 'jne L2' is true, it could physically swap all the instructions in the L1: block and the L2: block. Of course, it would have to know that no thread is within either block during the swap, but those are details...

   test x
   jeq L1:
L2: ...
   jmp L3:
L1: ...
L3:

我知道将程序代码加载到只读存储器等中时也会出现问题，但这是一个主意.

I understand there are also issues when the program code is loaded in readonly memory, etc. but it's an idea.

所以我的问题是，这样的JIT优化对于C/C ++是可行的，还是我错过了一些无法做到这一点的根本原因?那里有C/C ++的JIT优化器吗?

So my question is, is such a JIT optimization feasible for C/C++ or am I missing some fundamental reason why this cannot be done? Are there any JIT optimizers for C/C++ out there?

推荐答案

大多数现代CPU支持分支预测.它们具有较小的缓存，从概念上讲，CPU可使您在运行时重新排序.此缓存的大小相当有限，但可能意味着您没有获得想象中的好处.某些CPU甚至可以开始执行两个分支，并丢弃在未使用的分支上完成的工作.

Most modern CPU support branch prediction. They have a small cache which allow the CPU to notionally give you the benefits of re-ordering at runtime. This cache is fairly limited in size, but may mean you don't get as much benefit as you might imagine. Some CPUs can even start executing both branches and discard the work done on the branch not taken.

使用JIT编译器的最大优势来自于这样的代码.

The biggest advantage in using a JIT compiler comes from code like this.

if (debug) {
   // do something
}

JIT非常擅长检测和优化什么都不做的代码. (如果您有一个微基准测试，表明Java比C快很多，那么JIT很可能检测到您的测试在C编译器没有做的事情上没有做任何事情)

JITs are very good at detecting and optimising code which doesn't do anything. (If you have a micro-benchmark which suggests Java is much faster than C it is most likely the JIT has detected your test isn't doing anything where the C compiler didn't)

您可能会问，为什么C没有这样的东西?因为它具有更好"的功能

You might ask, why doesn't C have something like this? Because it has something "better"

#if DEBUG
    // do something
#endif

这是最佳选择，前提是调试很少更改，并且这些标志很少，因此您可以编译所有有用的组合.

This is optimal provided DEBUG rarely changes and you have very few of these flags so you can compile every useful combination.

此方法的问题是可伸缩性.您添加的每个标志都可以使要生成的预编译二进制文件数量加倍.

The problem this approach is scalability. Every flag you add can double the number of pre-compiled binaries to produce.

如果您有很多这样的标志，并且编译每个组合都是不切实际的，则需要依靠分支预测来动态优化代码.

If you have many such flags and it is impractical to compile every combination, you need to rely on branch prediction to optimise your code dynamically.

这篇关于用于C/C ++的JIT优化器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！