Hi Kevin,
The Zend Engine for many years now has been an integral part of the PHP source tree and enjoys
contributors from all over the community (not just Zend).
This refactoring exercise doesn’t change any of that and as Dmitry mentioned, is really a
refactoring of the Zend Engine vs. a new thing. This started as experimental work and once we
figured it was a great, viable direction to head in we decided to share it. It does have
implications for PHP extensions because we made changes to the datatype structures, etc. but it’s
been relatively straightforward to update the various extensions to conform to the refactored
structures.
The benefits do seem to be massive (exceeding our initial expectations). Memory usage is
*significantly* down, overall performance impact on real-world apps is significant and with these
changes it’s opened up a lot of additional opportunities for further optimization down the road as
we are not bottlenecked by our data structures.
Andi
On May 5, 2014, at 7:07 AM, Kevin Ingwersen <[email protected]> wrote:
> 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…am 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 <[email protected]>:
>
>> 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’t be able 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 OPCache.
>> The results on bench.php was just amazing – (0.219 seconds against 2.175 – *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’s 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 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!
>>
>> *Some benchmarks we ran so far:*
>>
>> Wordpress 3.6 – 20.0% gain (253 vs 211 req/sec)
>>
>> Drupal 6.1 – 11.7% gain (1770 vs 1585 req/sec
>>
>> Qdig – 15.3% gain (555 vs 482 req/sec)
>>
>> ZF test app – 30.5% gain (217 vs 166 req/sec)
>>
>> 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.
>>
>> 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.
>>
>> But we feel, we’ve 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’s more work to do in finishing
>> support of all extensions and continue to make some additional engine
>> improvements.
>>
>> Please 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.
>>
>> I would like to say many thanks to Xinchen and Nikita who made significant
>> part of presented work.
>>
>> I think that this engine can make the new major version of PHP we’re
>> talking about a lot more interesting.
>>
>> Thanks. Dmitry.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>