Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73892
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.83.41 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
In-Reply-To: <CA+9eiLtKFMWn7AXyS3_fni1Dyerx3DUW7imZ08P9gLr_FY=TaA@mail.gmail.com>
Date: Mon, 5 May 2014 16:07:18 +0200
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <139CBA89-9FBD-44E9-A4FC-5539F02943BC@googlemail.com>
References: <CA+9eiLtKFMWn7AXyS3_fni1Dyerx3DUW7imZ08P9gLr_FY=TaA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] phpng: Refactored PHP Engine with Big Performance Improvement
From: ingwie2000@googlemail.com (Kevin Ingwersen)

Hey!

This sounds like an amazing bit of updatng! :) I am very much looking =
forward to the new release of PHP. But, there is soemthing I do not =
understand.

I know that Zend is the current underlying VM, and further, this is not =
actual work by the PHP team=85am I right?
Further, will phpng replace the vm, or even more parts? Will it still =
need components like TSRM?

I am just asking, as I have been working with PHP within embedded =
aplications for a while now (currently working on porting autoconf to =
cDetect). If parts of the  source tree structure changed, I would need =
to refactor the building part as well.

Also, I am currently running a rather small but active community. To =
test phpng, I was thinking about silently injecting it thru the cgi =
script, to see how the performance owuld change. Does phpng have any =
effects on currently existing extensions (PDO, memcached)?

Kind regards, Ingwie!
Am 05.05.2014 um 15:07 schrieb Dmitry Stogov <dmitry@zend.com>:

> 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=92t be able =
to make
> any serious progress, and among other things started to experiment =
with
> memory managers, JIT technologies and other potential ideas.
>=20
> I spent a significant amount of time experimenting with JIT, and even
> created a PoC of transparent LLVM based JIT compiler embedded into =
OPCache.
> The results on bench.php was just amazing =96 (0.219 seconds against =
2.175 =96 *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, =
but
> 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=92s going to =
have any
> impact or not.
>=20
> 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 be
> published at *http://wiki.php.net/phpng <http://wiki.php.net/phpng>*), =
but
> in few words - we changed the basement trying to keep most of the =
building
> unchanged. Right now the new engine already makes *10-30% speedup of
> php*not only on benchmarks but on real-life applications as well!
>=20
>  *Some benchmarks we ran so far:*
>=20
> Wordpress 3.6 =96 20.0% gain (253 vs 211 req/sec)
>=20
> Drupal 6.1 =96 11.7% gain (1770 vs 1585 req/sec
>=20
> Qdig =96 15.3% gain (555 vs 482 req/sec)
>=20
> ZF test app =96 30.5% gain (217 vs 166 req/sec)
>=20
> On some apps we show better results than other PHP implementations. It =
will
> be great if others here could test this on their apps and compare to =
their
> existing PHP version to get additional results.
>=20
> The re-factoring is not finished yet as the focus was to first test =
whether
> this effort would deliver results. Not all extensions are supported, =
some
> tests are failing, and we also have more ideas for additional =
improvement.
>=20
> But =04we feel, we=92ve proven enough out to open it up for review, =
feedback
> and assistance, and wanted to involve the community as soon as we =
managed
> to get on a promising direction. There=92s more work to do in =
finishing
> support of all extensions and continue to make some additional engine
> improvements.
>=20
> =05Please try the refactored PHP engine and provide feedback re: =
performance,
> memory usage and any issues that come up. You may find it in *phpng* =
branch
> 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.
>=20
> I would like to say many thanks to Xinchen and Nikita who made =
significant
> part of presented work.
>=20
> I think that this engine can make the new major version of PHP we=92re
> talking about a lot more interesting.
>=20
> Thanks. Dmitry.