2 ms·

Why aren't the processor manufacturers making their own JITs and AOT compilers? Surely that would be a competitive advantage.

by tormeh 12y ago

vardump 12y ago
Intel makes a famous AOT compiler, ICC. https://software.intel.com/en-us/intel-compilers https://software.intel.com/en-us/intel-compilers
- tormeh 12y ago
  Yes, but it's for developer-compiled languages. It's not like I switch from an AMD to an Intel processor and suddenly all C code on my machine has new instructions in them. Compiled code remains the way it is. This is not what I want. What I want is either JIT or AOT-on-end-device.
  - vardump 12y ago
    Binary (compiled code) JIT compilation could very well be faster than direct execution. I'm not aware of anyone currently using these techniques for running native code faster. Yet. You can also call these techniques binary translation if you like. At simplest level, one could for example dynamically replace relevant static library calls with higher performance versions. Perform function signature based optimization - when a certain known common function is found, simply replace it with a faster version. More advanced ones could for example inline functions, even those pointed by function pointers given a guard condition. It could also vectorize suitable serial code. Superoptimization techniques could also be applied to the instruction stream. http://en.wikipedia.org/wiki/Superoptimization http://en.wikipedia.org/wiki/Superoptimization Even complex optimizations are possible. Like memory access pattern translation. The JIT compiler could perform cache simulation and find a mapping between memory accesses that would increase true hardware level locality of reference. Performance could be improved by generating access transformation code when target binary tries to access memory. Like map image processing memory access code from row major to Z-order curve to increase cache hit probability. Unless memory mapped (either to other processes or physical hardware) the buffer resides the data would need to be translated back row-major only for system calls. A lazy page fault mechanism could also work in some cases.

Why aren't the processor manufacturers making their own JITs and AOT compilers? Surely that would be a competitive advantage.

by tormeh 12y ago

Why aren't the processor manufacturers making their own JITs and AOT compilers? Surely that would be a competitive advantage.

vardump 12y ago

Intel makes a famous AOT compiler, ICC. https://software.intel.com/en-us/intel-compilers https://software.intel.com/en-us/intel-compilers

tormeh 12y ago
Yes, but it's for developer-compiled languages. It's not like I switch from an AMD to an Intel processor and suddenly all C code on my machine has new instructions in them. Compiled code remains the way it is. This is not what I want. What I want is either JIT or AOT-on-end-device.
- vardump 12y ago
  Binary (compiled code) JIT compilation could very well be faster than direct execution. I'm not aware of anyone currently using these techniques for running native code faster. Yet. You can also call these techniques binary translation if you like. At simplest level, one could for example dynamically replace relevant static library calls with higher performance versions. Perform function signature based optimization - when a certain known common function is found, simply replace it with a faster version. More advanced ones could for example inline functions, even those pointed by function pointers given a guard condition. It could also vectorize suitable serial code. Superoptimization techniques could also be applied to the instruction stream. http://en.wikipedia.org/wiki/Superoptimization http://en.wikipedia.org/wiki/Superoptimization Even complex optimizations are possible. Like memory access pattern translation. The JIT compiler could perform cache simulation and find a mapping between memory accesses that would increase true hardware level locality of reference. Performance could be improved by generating access transformation code when target binary tries to access memory. Like map image processing memory access code from row major to Z-order curve to increase cache hit probability. Unless memory mapped (either to other processes or physical hardware) the buffer resides the data would need to be translated back row-major only for system calls. A lazy page fault mechanism could also work in some cases.