5 ms·

> You should first check if the compiler doesn't do it for you. It probably doesn't, because otherwise Intel wouldn't have submitted this patch that adds compu

• simias 11y ago
  I don't know the specifics but from the linked thread at https://bugs.python.org/issue4753 https://bugs.python.org/issue4753 : Having a jump table in itself isn't special (the compiler does exactly that when compiling the switch() statement). What's special is that a dedicated indirect jump instruction at the end of each opcode helps the CPU make a separate prediction for which opcode follows the other one, which is not possible with a switch statement where the jump instruction is shared by all opcodes. I believe that's where most of the speedup comes from. So I don't think you can conclude that the compiler "probably doesn't" generate the jump table, just that you might do a better job yourself if you know what you're doing.
• xigency 11y ago
  The same performance can easily be achieved by simple compiler optimizations like inlining functions, unrolling loops, peephole optimizations, etc. The fact that your compiler doesn't support the same performance doesn't necessarily mean to re implement things in a confusing way. Another way of achieving the exact same result would be to use an array of function pointers. I think the more interesting dilemma is when you have a more complex VM possibly operating on an abstract syntax tree instead of just a bytecode stream, and the ways to optimize code (in C) while maintaining a proper stack. After figuring out how to make a switch statement work, there are a ton of more pressing organizational concerns like how to make function trampolining work without any overhead. Another way to make it faster would be to have it interpret * two * op-codes at once, but hey, that wouldn't do anything except save two cycles and explode the code size to a square of what it was.
  • sklogic 11y ago
    Yes, that python patch is only halfway to a proper indirect threaded dispatch, it still got a lookup table. See the OCaml bytecode VM for a really high performance example of this approach. > a more complex VM possibly operating on an abstract syntax tree Don't do it.
    • thesz 11y ago
      > Don't do it. http://peterdn.com/files/A_JIT_Translator_for_Oberon.pdf http://peterdn.com/files/A_JIT_Translator_for_Oberon.pdf Oberon did it with relative success. Relative to other VMs at the time.
      • sklogic 11y ago
        We're not talking about JITs here. Of course an tree-based representation is better for JITs, and if using a flat VM you may have to promote it to a higher level AST (or at least an SSA-based) form anyway. But for an immediate execution, a flat stream of instructions (or, better, a threaded code) is much more efficient than any kind of tree. Yes, I'm aware of things like SISC, but I'm yet to see a proof that their approach is more efficient than a flat bytecode, even when JVM overhead is taken into consideration.
• duaneb 11y ago
  Considering CPython is designed to be so portable, I don't think this means anything about popular compilers.