3 ms·

This article is not what you ask, but it is an example of a VM beating native: https://nullprogram.com/blog/2018/05/27/ https://nullprogram.com/blog/2018/05/27

This article is not what you ask, but it is an example of a VM beating native: https://nullprogram.com/blog/2018/05/27/ https://nullprogram.com/blog/2018/05/27/ Java uses the same technique. Basically, a JIT allows you to skip the overhead of the GOT. Devirtualization is another case. I have personally seen Java beating an existing C++ program for the reason I describe, but I cant publish the results here. You have to program carefully or you loose all speed benefits because of pointer chasing. But it is possible.

hyperman1 8y ago
I'll add another one: Inlining across libraries. AFAIK, Even if you statically precompile bytecode on the target system a la dotnet this is not possible as the individual library and executable files are barriers the compiler can't cross.
wolfgke 8y ago
> Basically, a JIT allows you to skip the overhead of the GOT. This is a problem that is GNU/Linux-specific. Windows DLLs are not PIC (position-independent code), so they do not suffer from this problem and don't need a GOT. See > https://www.symantec.com/connect/articles/dynamic-linking-linux-and-windows-part-one https://www.symantec.com/connect/articles/dynamic-linking-li... for details. The method that Windows uses is much faster in the average case, but slower in the "bad" case. So GNU/Linux vs Windows have different performance tradeoffs.
- hyperman1 8y ago
  Yes and no: there is another indirection mechanism at work on windows: All results for imports in the import table are at the beginning of the DLL's data segment. So a call to another DLL first has to fetch the data from there, then do an indirect call. In x86 assembler: some_import_address dd some_import ; will be filled in by dll import [... lots of unrelated code and data...] call [some_import_address] a JIT can read the address from code and do directly: call some_import that's one less memory load. The benefit is that the dynamic linking does not modify the code segment, so there are less private, modified pages mmapped, thus more sharing and less memory usage.

hyperman1 8y ago

I'll add another one: Inlining across libraries. AFAIK, Even if you statically precompile bytecode on the target system a la dotnet this is not possible as the individual library and executable files are barriers the compiler can't cross.

wolfgke 8y ago

> Basically, a JIT allows you to skip the overhead of the GOT. This is a problem that is GNU/Linux-specific. Windows DLLs are not PIC (position-independent code), so they do not suffer from this problem and don't need a GOT. See > https://www.symantec.com/connect/articles/dynamic-linking-linux-and-windows-part-one https://www.symantec.com/connect/articles/dynamic-linking-li... for details. The method that Windows uses is much faster in the average case, but slower in the "bad" case. So GNU/Linux vs Windows have different performance tradeoffs.

hyperman1 8y ago
Yes and no: there is another indirection mechanism at work on windows: All results for imports in the import table are at the beginning of the DLL's data segment. So a call to another DLL first has to fetch the data from there, then do an indirect call. In x86 assembler: some_import_address dd some_import ; will be filled in by dll import [... lots of unrelated code and data...] call [some_import_address] a JIT can read the address from code and do directly: call some_import that's one less memory load. The benefit is that the dynamic linking does not modify the code segment, so there are less private, modified pages mmapped, thus more sharing and less memory usage.