Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102418
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.178 as permitted sender)
MIME-Version: 1.0
References: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
In-Reply-To: <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
Date: Mon, 25 Jun 2018 17:14:02 +0300
Message-ID: <CAJHtznyYe8yEHjRRF7=h-rH6grNzvJ0QOhOUNeck_kgan8V9QQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000ac6c4056f77ffd7"
Subject: Re: [PHP-DEV] PHP 2^3
From: vsuraski@gmail.com (Zeev Suraski)

--0000000000000ac6c4056f77ffd7
Content-Type: text/plain; charset="UTF-8"

On Mon, Jun 25, 2018 at 3:31 PM Zeev Suraski <zeev@zend.com> wrote:

> 1. JIT.  As most of you probably know, we've invested heavily in re-doing
> JIT on top of the PHP 7 infrastructure.  There are good news and bad news.
> The good news is that - like the JIT POC we did back in 2014 - the results
> for CPU intensive workloads are remarkable.  The bad news is that it
> doesn't significantly move the needle for typical Web workloads.
> That said, unlike 2014 - where we had another avenue to go after, this
> time we believe that JIT doesn't improve the performance of typical Web
> workloads simply because the bottleneck there is no longer PHP code
> execution.
> However, I still think we should still include JIT in the next major
> version of PHP for at least 2 reasons:
>   - It will open the door for new types of workloads for PHP (non Web)
>   - It may open the door for new built-in functionality being written in
> PHP - for more secure code (e.g. a PHP unserialize() implementation,
> instead of one in C)
> In addition, it's always possible that we're missing something in our
> benchmarks and that there are real world Web workloads that would actually
> benefit from the speedup.
> One thing worth noting is that in all likelihood, we'd want to make
> OPcache (or at least large parts of it) a part of the core engine (and no
> longer a separate extension) as a part of the JIT effort.
> - (bonus) Combined with other things we're experimenting with, the
> compound effect may still result in better performance for Web apps.
> To get a feel for the performance gains we're talking about here, I
> recorded a benchmark comparing PHP 7.0 and the JIT PoC, available here:
> https://www.youtube.com/watch?v=dWH65pmnsr
>
> Argh - the URL was trimmed - that's the correct one:

https://www.youtube.com/watch?v=dWH65pmnsrI

Zeev

--0000000000000ac6c4056f77ffd7--