PHP 8.0 Likely To Have A New JIT Engine

[phoronix]

Phoronix: PHP 8.0 Likely To Have A New JIT Engine

Zend has begun developing a new JIT (Just-In-Time) Engine for PHP and is expecting it will likely be ready for PHP 8.0...

http://www.phoronix.com/scan.php?page=news_item&px=PHP-8.0-Early-JIT-Work

[uid313]

Yeah, but what about decorators and async?

[schmidtbag]

I see no problem in there being an a JIT for PHP, but I don't think it should be the interpreter for it. If this is at all comparable to the way cpython vs pypy functions, a PHP JIT seems to be a bad idea. For example, pypy can sometimes be as much as 100x faster than regular cpython, but, that's only if the script involves an infinite/indefinite loop - something PHP isn't typically used for. Meanwhile, pypy is known to be slower than cpython when running a "simple" script (one without long loops); something PHP is meant to do. When it comes to interpreted languages, not all tests or benchmarks are equal. But, just because python behaves differently between interpreters, it doesn't mean the same results will occur for PHP.

[GrayShade]

I see no problem in there being an a JIT for PHP, but I don't think it should be the interpreter for it. If this is at all comparable to the way cpython vs pypy functions, a PHP JIT seems to be a bad idea. For example, pypy can sometimes be as much as 100x faster than regular cpython, but, that's only if the script involves an infinite/indefinite loop - something PHP isn't typically used for. Meanwhile, pypy is known to be slower than cpython when running a "simple" script (one without long loops); something PHP is meant to do. When it comes to interpreted languages, not all tests or benchmarks are equal. But, just because python behaves differently between interpreters, it doesn't mean the same results will occur for PHP.

Some part of that might be the code generation step. The difference is that a Python script will be compiled and run once, while PHP will run the same code over and over again. Thus, the JIT-ted code can be cached and reused for future requests. Serving a site is more like running code in a loop than just once.

[starshipeleven]

"As I mentioned we didn't try to achieve any real performance improvement yet, \
although we do currently see 20% speedup on bench.php, but a bit of a slowdown on \ real-life apps." this is a proof how bad in terms of performance php compiler is. a few years ago it was 40 times slower when comparing to compiled c++ code. now situation improved a little, but still interpreting code on the fly it's too slow.

No wait, since when C++ is a benchmark of speed for an interpreted language, again?

[starshipeleven]

The highest-performing programming language - in our times it happens to be C/C++ - is a natural benchmark for all other programming languages.

I meant that comparing a compiled language with a interpreted language is an apples vs oranges comparison.

[starshipeleven]

it's not a benchmark. it's point of comparison.

compiled languages are by design much faster than interpreted languages, so yeah, I'm not seeing the point of making a rigged comparison like that. C++ is always going to be much faster than a scripting language.

[senkal]

I use both languages and I know the difference between compiled and interpreted languages. my point is that php is terribly slow and there are much faster interpreted languages.

I have seen benchmarks where PHP(7) was much faster than, for example, Python or Ruby.
Since you say that is not the case, show some benchmarks, that is how you will validate your statement, not just by writing random stuff on forums.
Please consider PHP 7 only, as it is the stable version now.

[starshipeleven]

I use both languages and I know the difference between compiled and interpreted languages. my point is that php is terribly slow and there are much faster interpreted languages.

Fine with that, I just find weird the comparison with C++.

[reepca]

I think a decent point of comparison for interpreted languages would be a forth. It's the "C" of interpreted languages (and it doesn't have to be interpreted, though it is almost always interactive - know the difference!), and would serve as a good baseline comparison if we want to see how, for example, a certain interpreter for a language compares to a certain compiler for the same language if we try to look at the parts that aren't directly affected by interpreter/compiler status. So for example, gcc is to gforth as pypy is to cython. Obviously there are some flaws with that (just-in-time compilation and ahead-of-time compilation are two different beasts), but it would be an interesting comparison nonetheless. Honestly, I'd just be happy to see real-world benchmarks involving forth - the internet doesn't feel like showing me them :~(