Announcement

Collapse
No announcement yet.

PHP 8.0 Likely To Have A New JIT Engine

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • PHP 8.0 Likely To Have A New JIT Engine

    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?pag...Early-JIT-Work

  • #2
    Yeah, but what about decorators and async?

    Comment


    • #3
      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.

      Comment


      • #4
        Originally posted by schmidtbag View Post
        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.

        Comment


        • #5
          "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.

          Comment


          • #6
            Originally posted by michal View Post
            "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?

            Comment


            • #7
              Originally posted by starshipeleven View Post
              No wait, since when C++ is a benchmark of speed for an interpreted language, again?
              The highest-performing programming language - in our times it happens to be C/C++ - is a natural benchmark for all other programming languages.

              Comment


              • #8
                Originally posted by starshipeleven View Post
                No wait, since when C++ is a benchmark of speed for an interpreted language, again?
                it's not a benchmark. it's point of comparison.

                Comment


                • #9
                  Originally posted by atomsymbol View Post
                  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.

                  Comment


                  • #10
                    Originally posted by michal View Post
                    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.

                    Comment

                    Working...
                    X