4 ms·

That's pretty nifty, but it seems like something a really good compiler could achieve automatically. Of course I'm not sure if any compilers actually are that g

by api 11y ago

That's pretty nifty, but it seems like something a really good compiler could achieve automatically. Of course I'm not sure if any compilers actually are that good.

frivoal 11y ago
This is a fairly mechanical conversion, so suppose a sufficiently smart compiler could do that. But assuming a sufficiently smart compiler when you depend on your code being fast tends to cause issues. Especially if you expect it to run on a bunch of platforms with compilers of varying qualities. Last time I saw code last this, we certainly couldn't rely on compilers being particularly smart, and we did care about speed.
Redoubts 11y ago
Well, this is what is going into Python 2.7.11 for a 15% speed up, so apparently compilers aren't that good yet. https://lwn.net/Articles/646888/ https://lwn.net/Articles/646888/
sklogic 11y ago
This is not exactly how fast bytecode interpreters are implemented. There is one next step - pre-caching the jump table straight into the bytecode. And there is absolutely no way compiler can transform your ad hoc switch-based interpreter into a threaded code interpreter automatically - it is not allowed to rewrite your data willy-nilly.
- frivoal 11y ago
  Hadn't thought of that, but it sounds interesting. I guess this means that opcodes in your bytecode need to be large enough to store a pointer, this could involve some tradeoffs in terms of minimizing instructions vs fitting in the cache, but I suppose it could fall on the right side of things often enough.
  - sklogic 11y ago
    32-bit opcodes are ok, even on 64-bit architectures, if you add a constant offset - see how it's done in OCaml.
    - frivoal 11y ago
      An offset from the first label, or some nearby alignment point? Makes sense. Do you have a pointer to the relevant part of OCaml's source? The whole thing is probably worth a read, but don't think I can set aside enough time for that soon, and it could take me a while to find the right part.
      - sklogic 11y ago
        https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c See the "Next" macro definition.
        frivoal 11y ago
        Nice. Simple and efficient. I am going to read more from that code base. Looks like this might be a nice read as well: https://ocaml.org/docs/papers.html#BytecodeCompilerandBytecodeInterpreter https://ocaml.org/docs/papers.html#BytecodeCompilerandByteco...

by api 11y ago

That's pretty nifty, but it seems like something a really good compiler could achieve automatically. Of course I'm not sure if any compilers actually are that good.

frivoal 11y ago

This is a fairly mechanical conversion, so suppose a sufficiently smart compiler could do that. But assuming a sufficiently smart compiler when you depend on your code being fast tends to cause issues. Especially if you expect it to run on a bunch of platforms with compilers of varying qualities. Last time I saw code last this, we certainly couldn't rely on compilers being particularly smart, and we did care about speed.

Redoubts 11y ago

Well, this is what is going into Python 2.7.11 for a 15% speed up, so apparently compilers aren't that good yet. https://lwn.net/Articles/646888/ https://lwn.net/Articles/646888/

sklogic 11y ago

This is not exactly how fast bytecode interpreters are implemented. There is one next step - pre-caching the jump table straight into the bytecode. And there is absolutely no way compiler can transform your ad hoc switch-based interpreter into a threaded code interpreter automatically - it is not allowed to rewrite your data willy-nilly.

frivoal 11y ago
Hadn't thought of that, but it sounds interesting. I guess this means that opcodes in your bytecode need to be large enough to store a pointer, this could involve some tradeoffs in terms of minimizing instructions vs fitting in the cache, but I suppose it could fall on the right side of things often enough.
- sklogic 11y ago
  32-bit opcodes are ok, even on 64-bit architectures, if you add a constant offset - see how it's done in OCaml.
  - frivoal 11y ago
    An offset from the first label, or some nearby alignment point? Makes sense. Do you have a pointer to the relevant part of OCaml's source? The whole thing is probably worth a read, but don't think I can set aside enough time for that soon, and it could take me a while to find the right part.
    - sklogic 11y ago
      https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c https://github.com/ocaml/ocaml/blob/trunk/byterun/interp.c See the "Next" macro definition.
      - frivoal 11y ago
        Nice. Simple and efficient. I am going to read more from that code base. Looks like this might be a nice read as well: https://ocaml.org/docs/papers.html#BytecodeCompilerandBytecodeInterpreter https://ocaml.org/docs/papers.html#BytecodeCompilerandByteco...