Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73919
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLtKFMWn7AXyS3_fni1Dyerx3DUW7imZ08P9gLr_FY=TaA@mail.gmail.com>
References: <CA+9eiLtKFMWn7AXyS3_fni1Dyerx3DUW7imZ08P9gLr_FY=TaA@mail.gmail.com>
Date: Tue, 6 May 2014 00:20:53 +0200
Message-ID: <CAEZPtU6Eh6pXOXyX_pVEm2bcsZtfoLwLND-HeCuk3xMuwpc4xQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] phpng: Refactored PHP Engine with Big Performance Improvement
From: pierre.php@gmail.com (Pierre Joye)

hi!

On Mon, May 5, 2014 at 3:07 PM, Dmitry Stogov <dmitry@zend.com> wrote:
> For people who know me it's not a secret that PHP performance is my main
> responsibility and passion at Zend. Actually, starting from PHP 5.0 we
> already made 6 times speedup on synthetic benchmarks and about 2 times
> speedup on real-life applications. We endlessly made improvements in PHP
> engine and OPCache. However, by PHP 5.5 release we weren=E2=80=99t be abl=
e to make
> any serious progress, and among other things started to experiment with
> memory managers, JIT technologies and other potential ideas.
>
> I spent a significant amount of time experimenting with JIT, and even
> created a PoC of transparent LLVM based JIT compiler embedded into OPCach=
e.
> The results on bench.php was just amazing =E2=80=93 (0.219 seconds agains=
t 2.175 =E2=80=93 *10
> times speedup of PHP 5.5*), but on real-life apps we got just few percent
> speedup. This made us look much deeper into some of the runtime
> characteristics and what was truly the bottleneck to making more
> substantial progress. It was clear the VM is already highly optimized, bu=
t
> works with data structures that require endless memory allocation,
> deallocation and reference counting. Typical real-life PHP application
> spends about 20% of the CPU time in memory manager, 10% doing hash tables
> operations, 30% in internal functions and only 30% in VM. Of course, we
> tried to JIT only VM code and in most cases it had to perform the same
> memory allocations. So we decided to change focus and work on the big
> bottlenecks. The idea was to change our data types to minimize heap
> allocations. This was a very difficult decision because we had to start
> with a huge refactoring, and we had no idea whether it=E2=80=99s going to=
 have any
> impact or not.
>
> Now I'm glad to present you a result of our recent four month work. It's =
a
> refactoring of the PHP engine that significantly improves performance,
> memory usage and builds a foundation for a lot more future performance
> improvements incl. JIT. I'll avoid technical details (more details will b=
e
> published at *http://wiki.php.net/phpng <http://wiki.php.net/phpng>*), bu=
t
> in few words - we changed the basement trying to keep most of the buildin=
g
> unchanged. Right now the new engine already makes *10-30% speedup of
> php*not only on benchmarks but on real-life applications as well!
>
>   *Some benchmarks we ran so far:*
>
> Wordpress 3.6 =E2=80=93 20.0% gain (253 vs 211 req/sec)
>
> Drupal 6.1 =E2=80=93 11.7% gain (1770 vs 1585 req/sec
>
> Qdig =E2=80=93 15.3% gain (555 vs 482 req/sec)
>
> ZF test app =E2=80=93 30.5% gain (217 vs 166 req/sec)
>
> On some apps we show better results than other PHP implementations. It wi=
ll
> be great if others here could test this on their apps and compare to thei=
r
> existing PHP version to get additional results.
>
> The re-factoring is not finished yet as the focus was to first test wheth=
er
> this effort would deliver results. Not all extensions are supported, some
> tests are failing, and we also have more ideas for additional improvement=
.
>
> But  we feel, we=E2=80=99ve proven enough out to open it up for review, f=
eedback
> and assistance, and wanted to involve the community as soon as we managed
> to get on a promising direction. There=E2=80=99s more work to do in finis=
hing
> support of all extensions and continue to make some additional engine
> improvements.

It is an awesome step moving forward, thanks to everyone involved in
this work! I will see how fast we can integrate this branch in our
tests.


>  Please try the refactored PHP engine and provide feedback re: performanc=
e,
> memory usage and any issues that come up. You may find it in *phpng* bran=
ch
> at *php.net <http://php.net>*. Some instructions may be found at
> *http://wiki.php.net/phpng
> <http://wiki.php.net/phpng>*. As mentioned, there are some missing
> extensions so not everything will run.

Could you move these pages (this one and the internal one) either to
/draft or /rfc please? the latter makes more sense

However I suppose basic windows tests are missing, as well as TS
sapis, right? Is it at least supposed to work in TS mode, by design?
Or should we expect some major issues?

> I would like to say many thanks to Xinchen and Nikita who made significan=
t
> part of presented work.
>
> I think that this engine can make the new major version of PHP we=E2=80=
=99re
> talking about a lot more interesting.

Do I understand correctly that you target php 6 for these changes, right?

Also one thing is totally missing, and is also caused by something
that becomes a common case, the 64bit support as it should be has been
totally ignored. That makes Anatol work to keep the 64bit branch
almost useless. My take on it is that we should either:

- move your patch to this branch and then merge to master
- merge the 64bit branche then this patch

That being said, I am not sure what requires less effort but I do not
feel comfortable to scratch the 64bit branch and begins from almost
zero.

There is something that we have to improve, drastically,
communication. Such major changes, developed (and still being worked
on) should pop up in the list and in the radar of other developers
much earlier in the process. For two critical reasons:

1. Avoid work conflicts, be for similar features/changes or other
areas being deadly affected by such changes
2. Increase visibility, feedback and cooperations. The earlier other
developers are involved the better it is  to get more people involved
in the engine development and maintenance.

I am not sure how to change that or make developers being more open
and stopped hidden developments. Any ideas or thoughts on this topic
are welcome. It is critical and vital for php, a must do.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org