4 ms·

Excellent article. > Everyone knows that pigs can’t fly — just like everyone thinks they know that bytecode interpreters, as a technology for executing high-le

Excellent article. > Everyone knows that pigs can’t fly — just like everyone thinks they know that bytecode interpreters, as a technology for executing high-level languages, can’t be sped up without resorting to labour-intensive dynamic compilation. [citation needed] PHP (in recent versions) is a good example for a bytecode VM that's quite quick. So we already have a spectrum that probably covers an order of magnitude or so, just in the basic speed of bytecode execution.

willvarfar 8y ago
Some interpreters are faster than others. But lets list some interpreters and their (usually jit) compilation equivs: cpython vs pypy lua vs luajit dalvik vs art (which isn't jit) zend vs hhvm Okay, that last one, php7 is reckoned to be faster than hhvm on some sites. My gut feeling, though is that is because of the inefficiencies in php, many inherent in the language design, rather than because php7 were the only people to know how to write a fast interpreter. It seems a sound generalisation that you get another order of magnitude by moving from interpretation to compilation.
- pjmlp 8y ago
  ART is surely a JIT after Android 7.
  - willvarfar 8y ago
    Ah I thought it was compile-on-install?
    - pjmlp 8y ago
      Only in Android 5 and 6. Compile-on-install was taking so long that in Android 7, they re-introduced the JIT and have been improving it since. So on Android 7, ART is an hand-optimized Assembly interpreter, which gathers data to a PGO JIT, which likewise gathers data to PGO AOT when the device is idle. Afterwards they started to optimize this workflow and optimizations being done, and as of Android P, PGO files are uploaded to the Play Store, which are then delivered to identical devices when they fresh install the APK so that they can reach the AOT step with a good level of optimizations faster. Just follow all the links available on the left sidebar here, https://source.android.com/devices/tech/dalvik https://source.android.com/devices/tech/dalvik There are also a couple of Google IO talks for Android 7, 8 and 9 talking about some of these changes.
- deleted 8y ago
  [deleted]
- ufo 8y ago
  For dynamic languages you can only get a 10x speedup if you have a JIT doing speculative type-based optimizations. If you replace the interpreter with a typical ahead of time compiler you will at most get around a 2x speedup (mostly from saving on opcode dispatch overhead). At worst it may not even be worth the extra compilation time and memory usage.
  - UncleEntity 8y ago
    I'm not sure how you came up with those numbers but I disagree. A while back I made a python module for libjit and during experimentation I easily got more than 10x speedups by simply translating the python code to the jit. Dusted off the code and ran the test on two different gcd algorithms (time in seconds for 100000 iterations): gcd: 13.303379424003651 gcd2: 5.1671242880111095 jit_gcd: 0.327398027991876 jit_gcd2: 0.21529806801117957 The jitted functions would probably be a small bit faster if I did any sort of optimations other than a simple algorithmic translation.
    - vkazanov 8y ago
      So you did a wrapper around libjit and generated functions on-the-fly? I am not sure it counts as a full bytecode jit. :-) I did a very stupid jit for the PigletVM thing while working on the article and the difference was more like 1.2-1.5 compared to the first naive interpreter.
      - UncleEntity 8y ago
        Wasn't saying it was a full bytecode jit (that's a full on big project in itself) I was just doubting the numbers. Here's the (old, apparently before I figured out how to translate gcd2) file: https://github.com/eponymous/libjit-python/blob/master/sample/gcd_benchmark.py https://github.com/eponymous/libjit-python/blob/master/sampl...
        vkazanov 8y ago
        Well, this is the perfect case for jits: basic number crunching. Bytecode interpreters are pure overhead in this case. Problems usually come from jumping between jitted/non-jitted code or, say, pointer chasing in complex objects. Did you find any use for the libjit wrapper? is it usable practically?
- tyingq 8y ago
  I think it's pretty impressive that php7 was roughly on par with hhvm performance wise, yet a lot more backwards compatible. Without FB level funding and resources. They've also been able to iterate where subsequent 7.x releases had notable improvements over prior ones: https://www.phoronix.com/scan.php?page=news_item&px=PHP-7.3-Performance-Benchmarks https://www.phoronix.com/scan.php?page=news_item&px=PHP-7.3-...
  - yellowapple 8y ago
    I wonder how that parity might change now that HHVM is dropping support for PHP entirely and only supporting Hack?
    - tyingq 8y ago
      Not sure how relevant it will be for anyone but FB. As far as I know, everyone that went to HHVM went back to PHP.
vkazanov 8y ago
I am the author of the article :-) This sentence is more like a description of the current state of affairs: people go for very complicated jits instead of trying to push the basic interpreter to its limits. And jits are complicated, and are very hard to get right.
- souprock 8y ago
  I can confirm this. At work I helped create a PowerPC interpreter running on x86-64 that was faster than anything else I could find. In many cases, it was faster than actual PowerPC hardware. Our first two attempts at a JIT couldn't beat the interpreter. Eventually we did it. We had to, since the PowerPC system being emulated had real-time software running on a beast of a CPU. It was quad-core, 1.5 GHz, out-of-order, with multiple pipelines. For reasons, all 4 cores needed to be emulated on a single host core.
  - vkazanov 8y ago
    Sounds like a very interesting project! Could you share some details? What techniques did u use? I collect everything interpreter-related. But that's easy to see from the article :-)

willvarfar 8y ago

Some interpreters are faster than others. But lets list some interpreters and their (usually jit) compilation equivs: cpython vs pypy lua vs luajit dalvik vs art (which isn't jit) zend vs hhvm Okay, that last one, php7 is reckoned to be faster than hhvm on some sites. My gut feeling, though is that is because of the inefficiencies in php, many inherent in the language design, rather than because php7 were the only people to know how to write a fast interpreter. It seems a sound generalisation that you get another order of magnitude by moving from interpretation to compilation.

pjmlp 8y ago
ART is surely a JIT after Android 7.
- willvarfar 8y ago
  Ah I thought it was compile-on-install?
  - pjmlp 8y ago
    Only in Android 5 and 6. Compile-on-install was taking so long that in Android 7, they re-introduced the JIT and have been improving it since. So on Android 7, ART is an hand-optimized Assembly interpreter, which gathers data to a PGO JIT, which likewise gathers data to PGO AOT when the device is idle. Afterwards they started to optimize this workflow and optimizations being done, and as of Android P, PGO files are uploaded to the Play Store, which are then delivered to identical devices when they fresh install the APK so that they can reach the AOT step with a good level of optimizations faster. Just follow all the links available on the left sidebar here, https://source.android.com/devices/tech/dalvik https://source.android.com/devices/tech/dalvik There are also a couple of Google IO talks for Android 7, 8 and 9 talking about some of these changes.
deleted 8y ago
[deleted]
ufo 8y ago
For dynamic languages you can only get a 10x speedup if you have a JIT doing speculative type-based optimizations. If you replace the interpreter with a typical ahead of time compiler you will at most get around a 2x speedup (mostly from saving on opcode dispatch overhead). At worst it may not even be worth the extra compilation time and memory usage.
- UncleEntity 8y ago
  I'm not sure how you came up with those numbers but I disagree. A while back I made a python module for libjit and during experimentation I easily got more than 10x speedups by simply translating the python code to the jit. Dusted off the code and ran the test on two different gcd algorithms (time in seconds for 100000 iterations): gcd: 13.303379424003651 gcd2: 5.1671242880111095 jit_gcd: 0.327398027991876 jit_gcd2: 0.21529806801117957 The jitted functions would probably be a small bit faster if I did any sort of optimations other than a simple algorithmic translation.
  - vkazanov 8y ago
    So you did a wrapper around libjit and generated functions on-the-fly? I am not sure it counts as a full bytecode jit. :-) I did a very stupid jit for the PigletVM thing while working on the article and the difference was more like 1.2-1.5 compared to the first naive interpreter.
    - UncleEntity 8y ago
      Wasn't saying it was a full bytecode jit (that's a full on big project in itself) I was just doubting the numbers. Here's the (old, apparently before I figured out how to translate gcd2) file: https://github.com/eponymous/libjit-python/blob/master/sample/gcd_benchmark.py https://github.com/eponymous/libjit-python/blob/master/sampl...
      - vkazanov 8y ago
        Well, this is the perfect case for jits: basic number crunching. Bytecode interpreters are pure overhead in this case. Problems usually come from jumping between jitted/non-jitted code or, say, pointer chasing in complex objects. Did you find any use for the libjit wrapper? is it usable practically?
tyingq 8y ago
I think it's pretty impressive that php7 was roughly on par with hhvm performance wise, yet a lot more backwards compatible. Without FB level funding and resources. They've also been able to iterate where subsequent 7.x releases had notable improvements over prior ones: https://www.phoronix.com/scan.php?page=news_item&px=PHP-7.3-Performance-Benchmarks https://www.phoronix.com/scan.php?page=news_item&px=PHP-7.3-...
- yellowapple 8y ago
  I wonder how that parity might change now that HHVM is dropping support for PHP entirely and only supporting Hack?
  - tyingq 8y ago
    Not sure how relevant it will be for anyone but FB. As far as I know, everyone that went to HHVM went back to PHP.

vkazanov 8y ago

I am the author of the article :-) This sentence is more like a description of the current state of affairs: people go for very complicated jits instead of trying to push the basic interpreter to its limits. And jits are complicated, and are very hard to get right.

souprock 8y ago
I can confirm this. At work I helped create a PowerPC interpreter running on x86-64 that was faster than anything else I could find. In many cases, it was faster than actual PowerPC hardware. Our first two attempts at a JIT couldn't beat the interpreter. Eventually we did it. We had to, since the PowerPC system being emulated had real-time software running on a beast of a CPU. It was quad-core, 1.5 GHz, out-of-order, with multiple pipelines. For reasons, all 4 cores needed to be emulated on a single host core.
- vkazanov 8y ago
  Sounds like a very interesting project! Could you share some details? What techniques did u use? I collect everything interpreter-related. But that's easy to see from the article :-)