5 ms·

Some interpreters are faster than others. But lets list some interpreters and their (usually jit) compilation equivs: cpython vs pypy lua vs luajit

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.

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.