FAQ
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.

Search Discussions

  • Sebastian Bergmann at May 5, 2014 at 1:49 pm

    Am 05.05.2014 15:07, schrieb Dmitry Stogov:
    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.
      Tried running PHPUnit 4.1's test suite with phpng:
      https://gist.github.com/sebastianbergmann/ad46f8e4e923578a72d5
  • Dmitry Stogov at May 5, 2014 at 1:56 pm
    It looks like a bug in GC. We will care about it in some point.

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 5:49 PM, Sebastian Bergmann wrote:

    Am 05.05.2014 15:07, schrieb Dmitry Stogov:
    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.
    Tried running PHPUnit 4.1's test suite with phpng:
    https://gist.github.com/sebastianbergmann/ad46f8e4e923578a72d5

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Andrea Faulds at May 5, 2014 at 2:01 pm
    This seems like something that would be a big feature for PHP 6. How much backwards-compatibility does it break?

    --
    Andrea Faulds
    http://ajf.me/
  • Dmitry Stogov at May 5, 2014 at 2:15 pm
    I would say it must be 100% compatible at the end, may be with exception
    for very rare and unclear cases that worked just because of existing
    implementation. (e.g. mixing foreach and next() on the same array).

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 6:01 PM, Andrea Faulds wrote:

    This seems like something that would be a big feature for PHP 6. How much
    backwards-compatibility does it break?

    --
    Andrea Faulds
    http://ajf.me/



  • Andrea Faulds at May 5, 2014 at 2:16 pm

    On 5 May 2014, at 15:15, Dmitry Stogov wrote:

    I would say it must be 100% compatible at the end, may be with exception for very rare and unclear cases that worked just because of existing implementation. (e.g. mixing foreach and next() on the same array).
    Of course it’s compatible with user land, what I meant to ask was how compatible is the ABI? Would this require a lot of changes to extensions and such?

    --
    Andrea Faulds
    http://ajf.me/
  • Andi Gutmans at May 5, 2014 at 2:26 pm
    Yes it does require changes in the extensions. I must say we’ve been able to hammer through them pretty quickly but it does require change due to the refactoring of the data types. It’s a refactoring exercise though not a rewrite. So relatively speaking not too painful and I think we’ve already worked through many of them so there are a lot of examples.

    Andi
    On May 5, 2014, at 7:16 AM, Andrea Faulds wrote:

    On 5 May 2014, at 15:15, Dmitry Stogov wrote:

    I would say it must be 100% compatible at the end, may be with exception for very rare and unclear cases that worked just because of existing implementation. (e.g. mixing foreach and next() on the same array).
    Of course it’s compatible with user land, what I meant to ask was how compatible is the ABI? Would this require a lot of changes to extensions and such?

    --
    Andrea Faulds
    http://ajf.me/


  • Andrea Faulds at May 5, 2014 at 2:30 pm
    Hmm. This is unrelated, but while you’re busy refactoring PHP, could you comment and document the bits you refactor a bit more? More documentation can only be a good thing, and it’s something Zend is sorely lacking.

    --
    Andrea Faulds
    http://ajf.me/
  • Dmitry Stogov at May 5, 2014 at 2:31 pm
    I'm doing it right now: https://wiki.php.net/phpng-int

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 6:30 PM, Andrea Faulds wrote:

    Hmm. This is unrelated, but while you’re busy refactoring PHP, could you
    comment and document the bits you refactor a bit more? More documentation
    can only be a good thing, and it’s something Zend is sorely lacking.

    --
    Andrea Faulds
    http://ajf.me/



  • Andrea Faulds at May 5, 2014 at 2:34 pm

    On 5 May 2014, at 15:31, Dmitry Stogov wrote:

    I'm doing it right now: https://wiki.php.net/phpng-int
    That’s great to see, thanks!

    --
    Andrea Faulds
    http://ajf.me/
  • Johannes Schlüter at May 5, 2014 at 3:26 pm
    Hi,
    On Mon, 2014-05-05 at 18:31 +0400, Dmitry Stogov wrote:
    I'm doing it right now: https://wiki.php.net/phpng-int
    I haven't looked deeply into it, but a thing I wondered about old zvals
    already:

    CELL Format (zval)

    +----------------------------------------------------------------------------------+
    VALUE (64-bit) |
    +--------------------------+-------------+-------------+-------------+-------------+
    UNUSED (32-bit) | UNUSED | const_flags | type_flags | TYPE |
    +--------------------------+-------------+-------------+-------------+-------------+
      63 32 31 24 23 16 15 8 7 0

    Have you tried movin the TYPE to the einning of the structure? - I
    assume checking/setting the type is the most common operation. By moving
    it upfront the address of the type equals the address of the zval, thus
    the CPU should be ale to access it without offset, might improve
    pipeline throughput.

    I haven't measured that, but miht be interesting while already chaning
    this.

    johannes
  • Dmitry Stogov at May 5, 2014 at 6:01 pm
    The improvement are made with JIT in mind. In the future, in many places we
    might predict the type and don't check it at all.

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 7:26 PM, Johannes Schlüter wrote:

    Hi,
    On Mon, 2014-05-05 at 18:31 +0400, Dmitry Stogov wrote:
    I'm doing it right now: https://wiki.php.net/phpng-int
    I haven't looked deeply into it, but a thing I wondered about old zvals
    already:

    CELL Format (zval)


    +----------------------------------------------------------------------------------+
    VALUE (64-bit)
    +--------------------------+-------------+-------------+-------------+-------------+
    UNUSED (32-bit) | UNUSED | const_flags | type_flags |
    TYPE |

    +--------------------------+-------------+-------------+-------------+-------------+
    63 32 31 24 23 16 15 8 7


    Have you tried movin the TYPE to the einning of the structure? - I
    assume checking/setting the type is the most common operation. By moving
    it upfront the address of the type equals the address of the zval, thus
    the CPU should be ale to access it without offset, might improve
    pipeline throughput.

    I haven't measured that, but miht be interesting while already chaning
    this.

    johannes
  • Bob Weinand at May 5, 2014 at 7:08 pm

    Am 5.5.2014 um 16:31 schrieb Dmitry Stogov <dmitry@zend.com>:
    I'm doing it right now: https://wiki.php.net/phpng-int

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 6:30 PM, Andrea Faulds wrote:

    Hmm. This is unrelated, but while you’re busy refactoring PHP, could you
    comment and document the bits you refactor a bit more? More documentation
    can only be a good thing, and it’s something Zend is sorely lacking.

    --
    Andrea Faulds
    http://ajf.me/

    Nice work!

    Just wondering why http://git.php.net/?p=php-src.git;a=commitdiff;h=f614fc68984b2d7fce3f275b8106955b5d910472 was reverted in phpng?

    Is there any real reason to still use IS_CONSTANT_ARRAY? The AST variant is much nicer, fixes a bug and removes the IS_CONSTANT_INDEX hack.

    Bob
  • Dmitry Stogov at May 5, 2014 at 7:33 pm
    Hi Bob,

    Actually, our patches were orthogonal, resolving the same hack in different
    ways.
    Sorry, I had a lot of work, and missed your patch when you committed it.
    Then I just wasn't able to merge them in reasonable time.

    We will need to discuss it in more details and then reimplement on top of
    phpng or revert in master.

    The thing I don't like in the patch, that you converted every
    IS_CONSTANT_ARRAY into IS_CONSTANT_AST.
    With this approach all the constant arrays have to be evaluated at run-time.
    However, I think about optimization when we won't copy constant arrays
    (without symbolic constants) from shared memory at all.
    I might be wrong, or misunderstand something in your patch, so we'll
    definitely need to talk, but now I would prefer to close the known problems
    first.

    Let's speak on next week.

    Thanks. Dmitry.



    On Mon, May 5, 2014 at 11:08 PM, Bob Weinand wrote:

    Am 5.5.2014 um 16:31 schrieb Dmitry Stogov <dmitry@zend.com>:

    I'm doing it right now: https://wiki.php.net/phpng-int

    Thanks. Dmitry.


    On Mon, May 5, 2014 at 6:30 PM, Andrea Faulds wrote:

    Hmm. This is unrelated, but while you’re busy refactoring PHP, could you
    comment and document the bits you refactor a bit more? More documentation
    can only be a good thing, and it’s something Zend is sorely lacking.

    --
    Andrea Faulds
    http://ajf.me/


    Nice work!

    Just wondering why
    http://git.php.net/?p=php-src.git;a=commitdiff;h=f614fc68984b2d7fce3f275b8106955b5d910472was reverted in phpng?

    Is there any real reason to still use IS_CONSTANT_ARRAY? The AST variant
    is much nicer, fixes a bug and removes the IS_CONSTANT_INDEX hack.

    Bob



  • Andi Gutmans at May 5, 2014 at 2:33 pm
    Yep agree. We started and definitely will need to do mode.

    Sent from my iPhone
    On May 5, 2014, at 10:30 AM, Andrea Faulds wrote:

    Hmm. This is unrelated, but while you’re busy refactoring PHP, could you comment and document the bits you refactor a bit more? More documentation can only be a good thing, and it’s something Zend is sorely lacking.

    --
    Andrea Faulds
    http://ajf.me/


  • Kevin Ingwersen at May 5, 2014 at 2:42 pm

    Am 05.05.2014 um 16:33 schrieb Andi Gutmans <andi@zend.com>:

    Yep agree. We started and definitely will need to do mode.

    Sent from my iPhone
    Mode? I think auto-correct likes you today =p

    Thats awesome, thanks for the replies. Hopefully the people at PHP-CPP will update their API as well to suit the updates, so that these things will continue to work as before.

    One thing, as you are on documenting: Documenting class usage from the C side (modifying properties etc) would be good to be documented a little bit more. Last time I looked into it, the object accessing API part was poorly documented.

    Going to do testing with phpng now and send results later. I will silently inject it into my currently running site, seeing how the performance will change.

    Kind regards, Ingwie.

    On May 5, 2014, at 10:30 AM, Andrea Faulds wrote:

    Hmm. This is unrelated, but while you’re busy refactoring PHP, could you comment and document the bits you refactor a bit more? More documentation can only be a good thing, and it’s something Zend is sorely lacking.

    --
    Andrea Faulds
    http://ajf.me/


  • Laruence at May 5, 2014 at 2:29 pm
    Hey:
    On Mon, May 5, 2014 at 10:16 PM, Andrea Faulds wrote:
    On 5 May 2014, at 15:15, Dmitry Stogov wrote:

    I would say it must be 100% compatible at the end, may be with exception for very rare and unclear cases that worked just because of existing implementation. (e.g. mixing foreach and next() on the same array).
    Of course it’s compatible with user land, what I meant to ask was how compatible is the ABI? Would this require a lot of changes to extensions and such?
          Not very much changes. the most significant changes are zend_hash_* APIs.

          but it's not very difficult to port a old ext into php-ng form

    thanks
    --
    Andrea Faulds
    http://ajf.me/




    --
    Laruence Xinchen Hui
    http://www.laruence.com/
  • Dmitry Stogov at May 5, 2014 at 2:30 pm
    yes. all the extensions will have to be changed.
    In some cases it may be difficult, but usually not too difficult.
    For example today Xinchen added support for 3 or 5 new extensions.

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 6:16 PM, Andrea Faulds wrote:


    On 5 May 2014, at 15:15, Dmitry Stogov wrote:

    I would say it must be 100% compatible at the end, may be with exception
    for very rare and unclear cases that worked just because of existing
    implementation. (e.g. mixing foreach and next() on the same array).


    Of course it’s compatible with user land, what I meant to ask was how
    compatible is the ABI? Would this require a lot of changes to extensions
    and such?

    --
    Andrea Faulds
    http://ajf.me/



  • Tjerk Meesters at May 8, 2014 at 11:42 am
    Hi,

    I coauthor the pecl extension for oauth; it currently supports >= 5.2 with
    only a few compiler directives, but these engine changes are quite
    extensive.

    My question is how to best approach this to maintain backwards
    compatibility?

    Thanks!
    On Mon, May 5, 2014 at 10:30 PM, Dmitry Stogov wrote:

    yes. all the extensions will have to be changed.
    In some cases it may be difficult, but usually not too difficult.
    For example today Xinchen added support for 3 or 5 new extensions.

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 6:16 PM, Andrea Faulds wrote:


    On 5 May 2014, at 15:15, Dmitry Stogov wrote:

    I would say it must be 100% compatible at the end, may be with exception
    for very rare and unclear cases that worked just because of existing
    implementation. (e.g. mixing foreach and next() on the same array).


    Of course it’s compatible with user land, what I meant to ask was how
    compatible is the ABI? Would this require a lot of changes to extensions
    and such?

    --
    Andrea Faulds
    http://ajf.me/





    --
    --
    Tjerk
  • Stas Malyshev at May 8, 2014 at 8:50 pm
    Hi!
    My question is how to best approach this to maintain backwards
    compatibility?
    I think this is best targeted for next major version, in which cases the
    extensions probably will have to have separate version/branch. With the
    depth of the changes done, I really don't see a good way to run both
    from the same codebase without making it either completely
    incomprehensible or very unstable.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Kevin Ingwersen at May 5, 2014 at 2:07 pm
    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 <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’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.
  • Andi Gutmans at May 5, 2014 at 2:25 pm
    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 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 <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’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
  • Dmitry Stogov at May 5, 2014 at 2:26 pm

    On Mon, May 5, 2014 at 6:07 PM, Kevin Ingwersen 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?

    I wouldn't talk about replacement. It's the same PHP with the evoluted Zend
    Engine (even the less significant change than moving from PHP-4 to PHP-5).

    Will it still need components like TSRM?
    yes.

    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)?
    yes. All the extensions need to be "ported" to support phpng.

    Thanks. Dmitry.
  • Thomas Hruska at May 5, 2014 at 2:59 pm

    On 5/5/2014 7:07 AM, Kevin Ingwersen wrote:
    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)
    What's the comparison to serving static HTML through PHP (no PHP tags)
    on the same setup?

    --
    Thomas Hruska
    CubicleSoft President

    I've got great, time saving software that you will find useful.

    http://cubiclesoft.com/
  • Dmitry Stogov at May 5, 2014 at 5:59 pm
    static HTML is served by web server and it's irrelevant to PHP performance.

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 6:59 PM, Thomas Hruska wrote:
    On 5/5/2014 7:07 AM, Kevin Ingwersen wrote:

    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)
    What's the comparison to serving static HTML through PHP (no PHP tags) on
    the same setup?

    --
    Thomas Hruska
    CubicleSoft President

    I've got great, time saving software that you will find useful.

    http://cubiclesoft.com/


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Timm Friebe at May 5, 2014 at 5:34 pm
    Hi,

    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.

    Wow, some great work!


    I do see a couple of failures running the XP Framework’s test suite (I’ll have a look into these and try to figure out what’s going on), but comparing these that *are* working, I can see the following:


    PHP 5.4
    OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed
    Memory used: 13877.78 kB (14830.66 kB peak)
    Time taken: 0.692 seconds


    PHP 5.5
    OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed
    Memory used: 13942.30 kB (14900.96 kB peak)
    Time taken: 0.583 seconds


    phpng
    OK: 1017/1042 run (25 skipped), 1017 succeeded, 0 failed
    Memory used: 10790.42 kB (11754.17 kB peak)
    Time taken: 0.385 seconds






    - Timm
  • Dmitry Stogov at May 5, 2014 at 6:16 pm
    Thanks for results! 34% speed improvement and 22% memory consumption
    improvement in comparison to PHP 5.5
    I'm always getting better results when bench against competitors myself :)
    So the third party benchmarks and comparisons really helps.

    phpng is still far away from production quality yet. It actually served the
    first wordpress request just a month ago.
    I hope we will able to catch most of the bugs soon.

    Thanks. Dmitry.

    On Mon, May 5, 2014 at 9:28 PM, Timm Friebe wrote:

    Hi,
    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.
    Wow, some great work!

    I do see a couple of failures running the XP Framework’s test suite (I’ll
    have a look into these and try to figure out what’s going on), but
    comparing these that *are* working, I can see the following:

    PHP 5.4
    OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed
    Memory used: 13877.78 kB (14830.66 kB peak)
    Time taken: 0.692 seconds

    PHP 5.5
    OK: 1019/1042 run (23 skipped), 1019 succeeded, 0 failed
    Memory used: 13942.30 kB (14900.96 kB peak)
    Time taken: 0.583 seconds

    phpng
    OK: 1017/1042 run (25 skipped), 1017 succeeded, 0 failed
    Memory used: 10790.42 kB (11754.17 kB peak)
    Time taken: 0.385 seconds

    - Timm
  • Timm Friebe at May 5, 2014 at 7:31 pm
    Hi again,
    ...
    It's been brought to my attention that in my previous comparison, there were
    also two skipped tests I'd overlooked, I've commented them so we're actually
    comparing apples with apples. Also, I got a couple more tests working, so here
    we go:

    5.5
    OK: 2987/3013 run (26 skipped), 2987 succeeded, 0 failed
    Memory used: 37065.45 kB (37350.91 kB peak)
    Time taken: 2.133 seconds

    phpng
    OK: 2987/3013 run (26 skipped), 2987 succeeded, 0 failed
    Memory used: 29315.42 kB (29583.73 kB peak)
    Time taken: 1.603 seconds
    (I’ll have a look into these and try to figure out what’s going on)
    Here's my summary of why there are failing tests (all of these work fine with
    5.4, 5.6-beta2, 5.7-dev-master). I've tried fixing them but haven't succeeded,
    but I thought I'd tell you anyways.


    1) Process control functions
    ============================
    proc_close() seems to always return exit code 1 regardless of the actual exit
    code:

    $ ./sapi/cli/php -r '$p= proc_open("ls -al buildconf", [0 => ["pipe", "r"], 1 =>
    ["pipe", "w"], 2 => ["pipe", "w"]], $pipes); var_dump(fread($pipes[1], 1024));
    foreach ($pipes as $pipe) { fclose($pipe); } var_dump(proc_close($p));'
    string(54) "-rwxr-xr-x 1 friebe friebe 772 Apr 18 16:21 buildconf
    "
    int(1)

    (should be: 0)

    $ ./sapi/cli/php -r '$p= proc_open("ls -ü", [0 => ["pipe", "r"], 1 => ["pipe",
    "w"], 2 => ["pipe", "w"]], $pipes); var_dump(fread($pipes[1], 1024)); foreach
    ($pipes as $pipe) { fclose($pipe); } var_dump(proc_close($p));'
    string(0) ""
    int(1)

    (should be: 2)

    It works fine in both situations if I don't explicitely fclose() all the pipes.

    2) Fatal error with DateTime
    ============================
    DateTime::date_timezone_set() must be derived from Date::date_timezone_set in
    Unknown on line 0
    DateTimeInterface::date_format() must be derived from Date::date_format in
    Unknown on line 0

    Unfortunately I can't exactly produce a small script to reproduce, but the
    `Date` class mentioned above basically does this:

    class Date extends Object {
      public function __construct($in) {
        $this->value= date_create($in, timezone_open(...));
      }
    }

    These errors are both produced by zend_parse_method_parameters(), where this_ptr
    points to the class `Date` and not to `DateTime`. I've only seen them with the
    date extension, nowhere else so far. Maybe that helps you.

    3) Fatal error: Can only throw objects
    ======================================
    References cause this. The ensure() function prevents uninitialized variable
    warnings:

    $ ./sapi/cli/php -r 'function ensure(&$e) { if ($e) return true; $e= null;
    return false; } $e= new Exception(""); if (ensure($e)) { throw $e; }'

    Fatal error: Can only throw objects in Command line code on line 1

    Expected outcome:

    PHP Fatal error:  Uncaught exception 'Exception' in Command line code:1
    # ...

    Adding a var_dump($e) right before the `throw` will actually dump the exception,
    so I guess this some refcount issue.

    -Timm
  • Pierre Joye at May 5, 2014 at 10:21 pm
    hi!
    On Mon, May 5, 2014 at 3:07 PM, Dmitry Stogov 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’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.
    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: 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.
    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 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.
    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,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Levi Morrison at May 5, 2014 at 10:28 pm

    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.
    This isn't a thought on how to do this, but rather another reason to be
    open: there are people out there with the talent and time who want to work
    on this stuff if only they knew about it (I know of at least one person).
  • Dmitry Stogov at May 6, 2014 at 12:03 am
    I understand.
    But now it's open and we still have a lot of problems to solve.
    If that person like to join and smart enough to not make slowdown, they are
    welcome now.

    Thanks. Dmitry.


    On Tue, May 6, 2014 at 2:28 AM, Levi Morrison wrote:

    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.
    This isn't a thought on how to do this, but rather another reason to be
    open: there are people out there with the talent and time who want to work
    on this stuff if only they knew about it (I know of at least one person).
  • Dmitry Stogov at May 5, 2014 at 11:44 pm
    On Tue, May 6, 2014 at 2:20 AM, Pierre Joye wrote:

    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.
    Note, that we even didn't try to run it on Windows.
    So it must be some problems.

    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.
    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?
    ZTS wasn't in our priority list, but Nikita made it more or less work.

    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.
    Do I understand correctly that you target php 6 for these changes, right?
    The next major release - 6 or 7, of course, if we port all extensions and
    solve all problems.

    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
    I afraid both ways aren't going to be simple.

    Anyway, I think 64-bit integer support on Windows64 makes full sense and
    it's possible to add it into "phpng" right now.

    I'm not so sure about size_t string length.

    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 understand your opinion, but when we started this project we didn't know
    if we will get any useful results at all.
    You know, I can't ask everyone in PHP community to freeze development and
    wait while we are thinking :)

    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.
    I don't see problem in hidden development. The formed ideas come as RFC
    with patches.
    Anyway, I'm open to discussions, if they won't take too mach time.

    Thanks. Dmitry.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Stas Malyshev at May 6, 2014 at 12:16 am
    Hi!
    Anyway, I think 64-bit integer support on Windows64 makes full sense and
    it's possible to add it into "phpng" right now.

    I'm not so sure about size_t string length.
    Shouldn't it be easier in phpng with everything using zend_string*
    instead of char*+int? As far as I can see, making zend_string use 64-bit
    length should be more or less painless, and then we only need to watch
    out when we take string length and assign it to some other variable,
    which shouldn't be too many places I hope.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Dmitry Stogov at May 6, 2014 at 12:22 am
    yes. it must be easier to implement (less places have to be changed), but
    it may increase memory consumption.

    Thanks. Dmitry.

    On Tue, May 6, 2014 at 4:16 AM, Stas Malyshev wrote:

    Hi!
    Anyway, I think 64-bit integer support on Windows64 makes full sense and
    it's possible to add it into "phpng" right now.

    I'm not so sure about size_t string length.
    Shouldn't it be easier in phpng with everything using zend_string*
    instead of char*+int? As far as I can see, making zend_string use 64-bit
    length should be more or less painless, and then we only need to watch
    out when we take string length and assign it to some other variable,
    which shouldn't be too many places I hope.

    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Hannes Magnusson at May 6, 2014 at 12:37 am

    On Mon, May 5, 2014 at 4:44 PM, Dmitry Stogov wrote:

    ZTS wasn't in our priority list, but Nikita made it more or less work.
    What is the argument to keep it?
    - It is the leading factor of broken builds
    - Endless API changes because of it
    - Noones friend
    - I am (blissfully?) unaware of any intentional deployment of zts

    -Hannes
  • Dmitry Stogov at May 6, 2014 at 4:58 am
    hi Hannes,

    We didn't come to any agreement to remove ZTS as well.
    I don't think we might remove something before opening the code.

    Thanks. Dmitry.


    On Tue, May 6, 2014 at 4:37 AM, Hannes Magnusson wrote:
    On Mon, May 5, 2014 at 4:44 PM, Dmitry Stogov wrote:


    ZTS wasn't in our priority list, but Nikita made it more or less work.
    What is the argument to keep it?
    - It is the leading factor of broken builds
    - Endless API changes because of it
    - Noones friend
    - I am (blissfully?) unaware of any intentional deployment of zts

    -Hannes
  • Pierre Joye at May 6, 2014 at 5:03 am

    On Tue, May 6, 2014 at 6:58 AM, Dmitry Stogov wrote:
    hi Hannes,

    We didn't come to any agreement to remove ZTS as well.
    I don't think we might remove something before opening the code.
    To remove TS support is hardly a question, and would be a very bad
    design decision. However to change its implementation (killing TSRM)
    could be something I can imagine. But it is a totally different topic
    and should be discussed in a separate thread/RFC.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at May 6, 2014 at 5:31 am
    agree.

    Dmitry.

    On Tue, May 6, 2014 at 9:03 AM, Pierre Joye wrote:
    On Tue, May 6, 2014 at 6:58 AM, Dmitry Stogov wrote:
    hi Hannes,

    We didn't come to any agreement to remove ZTS as well.
    I don't think we might remove something before opening the code.
    To remove TS support is hardly a question, and would be a very bad
    design decision. However to change its implementation (killing TSRM)
    could be something I can imagine. But it is a totally different topic
    and should be discussed in a separate thread/RFC.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at May 6, 2014 at 4:19 am

    On Tue, May 6, 2014 at 1:44 AM, Dmitry Stogov wrote:

    ZTS wasn't in our priority list, but Nikita made it more or less work.
    Why do I have a deja vu feeling? ;)

    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

    I afraid both ways aren't going to be simple.
    Rght, but again, I really do not feel comfortable to ask Anatal or my
    team to redo all the work. This would be very bad.
    Anyway, I think 64-bit integer support on Windows64 makes full sense and
    it's possible to add it into "phpng" right now.
    Again, it is by far not only a windows change, even if Windows is the
    platform with the most visible change from a user point of view.
    I'm not so sure about size_t string length.
    It is hardly imaginable to release php 6 with strings length still
    using integer. The memory consumption has been shown to be minimal
    during the discussions about the 64bit support. Or did I miss some
    important new information?
    I understand your opinion, but when we started this project we didn't know
    if we will get any useful results at all.
    You know, I can't ask everyone in PHP community to freeze development and
    wait while we are thinking :)
    No, but it is possible to get a branch and work on it, sync it with
    the other relevant branch. That is what we have done for the 64bit
    branch, providing updated builds and tests results while working on
    it. Everyone can test it or contribute. This is the way to do such
    things from a technical point of view. It is also the way to do it
    from a cooperation point of view, for the reasons I gave earlier.

    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.

    I don't see problem in hidden development. The formed ideas come as RFC with
    patches.
    Well, I do when it comes to such massive changes, no matter how
    positive they are. It is all about being open and transparent. Early
    participation eases the understanding of the changes, design or
    debugging of the new features or changes. This reduces the bus factor
    when it comes to maintain it and we both know that this has been an
    issue for too long for everything around the engine area.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at May 6, 2014 at 5:28 am

    On Tue, May 6, 2014 at 8:19 AM, Pierre Joye wrote:
    On Tue, May 6, 2014 at 1:44 AM, Dmitry Stogov wrote:

    ZTS wasn't in our priority list, but Nikita made it more or less work.
    Why do I have a deja vu feeling? ;)
    I really, don't see a lot of sense in using ZTS and didn't like to spend
    our time.

    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

    I afraid both ways aren't going to be simple.
    Rght, but again, I really do not feel comfortable to ask Anatal or my
    team to redo all the work. This would be very bad.
    I see your point. Please, look from mine.
    Just compare the sizes of diffs between branches.
    We won't be able to care about unstable development branches...

    We may help, with reimplementation of int64 patch, but actually we come to
    ask help ourselves.
    I hope we will found some compromise. It can't be a problem if our goals
    are not opposite :)

    Anyway, I think 64-bit integer support on Windows64 makes full sense and
    it's possible to add it into "phpng" right now.
    Again, it is by far not only a windows change, even if Windows is the
    platform with the most visible change from a user point of view.
    OK. Win64 is enough for this patch. I wouldn't care about others, because I
    even don't know the names.

    I'm not so sure about size_t string length.
    It is hardly imaginable to release php 6 with strings length still
    using integer. The memory consumption has been shown to be minimal
    during the discussions about the 64bit support. Or did I miss some
    important new information?
    I wouldn't mix size_t string length with 64-bit support. These are two
    independent changes.
    int64 would make 64-bit PHP version behave more or less consistent with
    minimal cost.

    size_t string length will increase memory consumption and memory traffic
    for the cases that no one web application will use (2GB strings).
    I'm trying to save (or even improve) memory consumption, because I know how
    it may affect performance because of CPU cache misses.

    Lets apply the first part first.

    Sorry, I already said my opinion about development.

    Thanks. Dmitry.


    I understand your opinion, but when we started this project we didn't know
    if we will get any useful results at all.
    You know, I can't ask everyone in PHP community to freeze development and
    wait while we are thinking :)
    No, but it is possible to get a branch and work on it, sync it with
    the other relevant branch. That is what we have done for the 64bit
    branch, providing updated builds and tests results while working on
    it. Everyone can test it or contribute. This is the way to do such
    things from a technical point of view. It is also the way to do it
    from a cooperation point of view, for the reasons I gave earlier.
    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.

    I don't see problem in hidden development. The formed ideas come as RFC with
    patches.
    Well, I do when it comes to such massive changes, no matter how
    positive they are. It is all about being open and transparent. Early
    participation eases the understanding of the changes, design or
    debugging of the new features or changes. This reduces the bus factor
    when it comes to maintain it and we both know that this has been an
    issue for too long for everything around the engine area.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at May 6, 2014 at 5:43 am

    On Tue, May 6, 2014 at 7:27 AM, Dmitry Stogov wrote:

    I really, don't see a lot of sense in using ZTS and didn't like to spend our
    time.
    Well, it is not a taste matter and we all have to take care of issues
    on platforms/sapis we do not use daily.
    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

    I afraid both ways aren't going to be simple.
    Rght, but again, I really do not feel comfortable to ask Anatal or my
    team to redo all the work. This would be very bad.

    I see your point. Please, look from mine.
    Just compare the sizes of diffs between branches.
    We won't be able to care about unstable development branches...
    It is stable as far as we can tell and has been working constantly
    since we proposed it. Tests results are public and very positive.
    Thing is that every individual here is not alone on working on php,
    care has to be taken.
    We may help, with reimplementation of int64 patch, but actually we come to
    ask help ourselves.
    I hope we will found some compromise. It can't be a problem if our goals are
    not opposite :)
    We have the same goals :) While performance is a lower priority to me
    than clean code and maintainability in the long run. But both
    performance and ease of maintainability can be achieved together.
    Anyway, I think 64-bit integer support on Windows64 makes full sense and
    it's possible to add it into "phpng" right now.
    Again, it is by far not only a windows change, even if Windows is the
    platform with the most visible change from a user point of view.

    OK. Win64 is enough for this patch. I wouldn't care about others, because I
    even don't know the names.
    Err, even Linux has a not so good 64bit implementation. We rely on
    single compiler behavior and 20 years old types described by many
    leading developers as hacks. PHP is one of the only OSS projects I
    know still relying on these types or using int for buffer size. I am
    not willing to tell you what you should care about but this is
    definitively an area that deserves more attention.
    I'm not so sure about size_t string length.
    It is hardly imaginable to release php 6 with strings length still
    using integer. The memory consumption has been shown to be minimal
    during the discussions about the 64bit support. Or did I miss some
    important new information?

    I wouldn't mix size_t string length with 64-bit support. These are two
    independent changes.
    int64 would make 64-bit PHP version behave more or less consistent with
    minimal cost.
    There are part of the same changeset. They are even deeply related.
    size_t string length will increase memory consumption and memory traffic for
    the cases that no one web application will use (2GB strings).
    I'm trying to save (or even improve) memory consumption, because I know how
    it may affect performance because of CPU cache misses.

    Lets apply the first part first.
    I have to disagree here, the patch contains both changes and will be
    proposed together. I do not see an appealing reason to split them for
    a minimal gain from a memory usage point of view. The importance and
    gains brought by these changes are too important. The "new" RFC and
    patch are ready, it will be proposed soonish. If accepted, let see
    what is the best way to make your patches work with it, we can help
    here with the moves anyway :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at May 6, 2014 at 5:57 am
    int64 proposal is still in draft for very long time.
    Do you provide support for all other unrelated proposals when you offer
    your own?

    Lets think how to integrate them. I propose doing it in two steps
    (measuring the performance and memory consumption difference).
    If the degradation is going to be invisible, I won't object.

    Thanks. Dmitry.



    On Tue, May 6, 2014 at 9:43 AM, Pierre Joye wrote:
    On Tue, May 6, 2014 at 7:27 AM, Dmitry Stogov wrote:

    I really, don't see a lot of sense in using ZTS and didn't like to spend our
    time.
    Well, it is not a taste matter and we all have to take care of issues
    on platforms/sapis we do not use daily.
    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

    I afraid both ways aren't going to be simple.
    Rght, but again, I really do not feel comfortable to ask Anatal or my
    team to redo all the work. This would be very bad.

    I see your point. Please, look from mine.
    Just compare the sizes of diffs between branches.
    We won't be able to care about unstable development branches...
    It is stable as far as we can tell and has been working constantly
    since we proposed it. Tests results are public and very positive.
    Thing is that every individual here is not alone on working on php,
    care has to be taken.
    We may help, with reimplementation of int64 patch, but actually we come to
    ask help ourselves.
    I hope we will found some compromise. It can't be a problem if our goals are
    not opposite :)
    We have the same goals :) While performance is a lower priority to me
    than clean code and maintainability in the long run. But both
    performance and ease of maintainability can be achieved together.
    Anyway, I think 64-bit integer support on Windows64 makes full sense
    and
    it's possible to add it into "phpng" right now.
    Again, it is by far not only a windows change, even if Windows is the
    platform with the most visible change from a user point of view.

    OK. Win64 is enough for this patch. I wouldn't care about others, because I
    even don't know the names.
    Err, even Linux has a not so good 64bit implementation. We rely on
    single compiler behavior and 20 years old types described by many
    leading developers as hacks. PHP is one of the only OSS projects I
    know still relying on these types or using int for buffer size. I am
    not willing to tell you what you should care about but this is
    definitively an area that deserves more attention.
    I'm not so sure about size_t string length.
    It is hardly imaginable to release php 6 with strings length still
    using integer. The memory consumption has been shown to be minimal
    during the discussions about the 64bit support. Or did I miss some
    important new information?

    I wouldn't mix size_t string length with 64-bit support. These are two
    independent changes.
    int64 would make 64-bit PHP version behave more or less consistent with
    minimal cost.
    There are part of the same changeset. They are even deeply related.
    size_t string length will increase memory consumption and memory traffic for
    the cases that no one web application will use (2GB strings).
    I'm trying to save (or even improve) memory consumption, because I know how
    it may affect performance because of CPU cache misses.

    Lets apply the first part first.
    I have to disagree here, the patch contains both changes and will be
    proposed together. I do not see an appealing reason to split them for
    a minimal gain from a memory usage point of view. The importance and
    gains brought by these changes are too important. The "new" RFC and
    patch are ready, it will be proposed soonish. If accepted, let see
    what is the best way to make your patches work with it, we can help
    here with the moves anyway :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at May 6, 2014 at 6:14 am

    On Tue, May 6, 2014 at 7:56 AM, Dmitry Stogov wrote:
    int64 proposal is still in draft for very long time.
    Sorry, but it was proposed and rejected because of the changes were
    too big for the 5.x serie. It has been said, as arguments for the no,
    that it would not be a problem for php 6. We are so far.
    Do you provide support for all other unrelated proposals when you offer your
    own?
    I do not understand the question, what do you mean?

    However, about support, we do offer support for almost every proposal,
    be for testing, build fixes, etc. Pro actively in most cases, whether
    it is in our priorities list or not. My reasoning here is pretty
    simple, a stable PHP, for all supported platform or configuration is
    critical for the success of PHP. Cooperation too.
    Lets think how to integrate them. I propose doing it in two steps (measuring
    the performance and memory consumption difference).
    If the degradation is going to be invisible, I won't object.
    The numbers are available already, using master and 5.5-5.6. We
    obviously do not have numbers using your patch but I do not think the
    delta will be any different.


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Dmitry Stogov at May 6, 2014 at 6:25 am

    On Tue, May 6, 2014 at 10:14 AM, Pierre Joye wrote:
    On Tue, May 6, 2014 at 7:56 AM, Dmitry Stogov wrote:
    int64 proposal is still in draft for very long time.
    Sorry, but it was proposed and rejected because of the changes were
    too big for the 5.x serie. It has been said, as arguments for the no,
    that it would not be a problem for php 6. We are so far.
    I was never glad with size_t string lengths and told about it.

    Do you provide support for all other unrelated proposals when you offer your
    own?
    I do not understand the question, what do you mean?
    I mean that when you develop something big, you have to be concentrated on
    the goals you are going to solve and not on compatibility with others
    proposals.

    However, about support, we do offer support for almost every proposal,
    be for testing, build fixes, etc. Pro actively in most cases, whether
    it is in our priorities list or not. My reasoning here is pretty
    simple, a stable PHP, for all supported platform or configuration is
    critical for the success of PHP. Cooperation too.
    Lets think how to integrate them. I propose doing it in two steps
    (measuring
    the performance and memory consumption difference).
    If the degradation is going to be invisible, I won't object.
    The numbers are available already, using master and 5.5-5.6. We
    obviously do not have numbers using your patch but I do not think the
    delta will be any different.
    phpng completely changes zval structure and reduces overhead of some
    subsystems, so the numbers might be different.

    Thanks. Dmitry.


    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Pierre Joye at May 6, 2014 at 6:41 am

    On Tue, May 6, 2014 at 8:25 AM, Dmitry Stogov wrote:

    On Tue, May 6, 2014 at 10:14 AM, Pierre Joye wrote:
    On Tue, May 6, 2014 at 7:56 AM, Dmitry Stogov wrote:
    int64 proposal is still in draft for very long time.
    Sorry, but it was proposed and rejected because of the changes were
    too big for the 5.x serie. It has been said, as arguments for the no,
    that it would not be a problem for php 6. We are so far.

    I was never glad with size_t string lengths and told about it.
    Do you provide support for all other unrelated proposals when you offer
    your
    own?
    I do not understand the question, what do you mean?

    I mean that when you develop something big, you have to be concentrated on
    the goals you are going to solve and not on compatibility with others
    proposals.
    Right, but this is possible to achieve by cooperating with the
    authors of other proposals. Early and well organized proposals
    minimize the pain for other developers while maximizing the chance of
    success.

    However, about support, we do offer support for almost every proposal,
    be for testing, build fixes, etc. Pro actively in most cases, whether
    it is in our priorities list or not. My reasoning here is pretty
    simple, a stable PHP, for all supported platform or configuration is
    critical for the success of PHP. Cooperation too.
    Lets think how to integrate them. I propose doing it in two steps
    (measuring
    the performance and memory consumption difference).
    If the degradation is going to be invisible, I won't object.
    The numbers are available already, using master and 5.5-5.6. We
    obviously do not have numbers using your patch but I do not think the
    delta will be any different.

    phpng completely changes zval structure and reduces overhead of some
    subsystems, so the numbers might be different.
    They will be different, no doubt here, but there should not be that
    much differences from a relative point of view.

    However I do not think I can go to my team and asked to do that from
    scratch based on a work in progress effort (even a very good one :).
    The more I look at it the more I think it is easier and faster to
    merge the 64bit and then adapt the other one, if accepted (for both
    proposals).

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Sebastian Bergmann at May 7, 2014 at 6:12 am

    Am 06.05.2014 07:43, schrieb Pierre Joye:
    Well, it is not a taste matter and we all have to take care of issues
    on platforms/sapis we do not use daily.
      Playing devil's advocate: does anyone really need SAPIs other than
      FastCGI, CLI, and embed? And if so: do we care enough to burden
      ourselves with their maintenance?
  • Pierre Joye at May 7, 2014 at 6:16 am

    On Wed, May 7, 2014 at 8:12 AM, Sebastian Bergmann wrote:
    Am 06.05.2014 07:43, schrieb Pierre Joye:
    Well, it is not a taste matter and we all have to take care of issues
    on platforms/sapis we do not use daily.
    Playing devil's advocate: does anyone really need SAPIs other than
    FastCGI, CLI, and embed? And if so: do we care enough to burden
    ourselves with their maintenance?
    Being in the same mode (Devil's advocate), let make PHP linux+gcc
    (some recent versions only), enable only phpdbg, fpm and cli, and be
    done with all the other platforms.

    Back to normal mode: it is not the way :)

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Zeev Suraski at May 7, 2014 at 6:41 am

    On 7 במאי 2014, at 09:13, Sebastian Bergmann wrote:


    Playing devil's advocate: does anyone really need SAPIs other than
    FastCGI, CLI, and embed? And if so: do we care enough to burden
    ourselves with their maintenance?
    I think you just called me "the devil" ;)

    Seriously, I can't think of any *real* reason of why anybody would
    need something other than these SAPIs in 2014 (other than FUD).
    Things like ISAPI and other more esoteric SAPIs are no brainers, and
    while mod_php may be a bit more of a leap of faith, it doesn't truly
    brings any tangible benefits over FastCGI (none that can't be
    relatively easily replicated in userland anyway, eg htscanner).

    I'd support it.

    Zeev
  • Pierre Joye at May 7, 2014 at 6:52 am

    On Wed, May 7, 2014 at 8:36 AM, Zeev Suraski wrote:
    On 7 במאי 2014, at 09:13, Sebastian Bergmann wrote:


    Playing devil's advocate: does anyone really need SAPIs other than
    FastCGI, CLI, and embed? And if so: do we care enough to burden
    ourselves with their maintenance?
    I think you just called me "the devil" ;)

    Seriously, I can't think of any *real* reason of why anybody would
    need something other than these SAPIs in 2014 (other than FUD).
    Things like ISAPI and other more esoteric SAPIs are no brainers, and
    while mod_php may be a bit more of a leap of faith, it doesn't truly
    brings any tangible benefits over FastCGI (none that can't be
    relatively easily replicated in userland anyway, eg htscanner).

    I'd support it.
    The problem here is not only the SAPIs but as a matter of fact Zend
    cares about what they need and that's about it, and pushed things very
    hard. We have to keep in mind that PHP success is not only based on
    his design ( :-> ) but also because its availability on a large
    variety of platforms.

    If some likes to have a striped down (to one) set of platforms (in
    this case, linux+gcc+fpm+cli), then go for it, the code is open and
    there are many places where to host it. Facebook did it with many
    other changes. But to restrict the future of PHP to fill some
    individual needs (entities or person) is not a good thing, not for php
    and certainly not for the communities.

    Now, on a more constructive side, there are ways to improve the
    situation and ease the overall development and maintenance work.
    Droping TSRM or drastically improve it (TLS f.e.) could be one of
    them.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Anatol Belski at May 7, 2014 at 7:21 am
    Hi Zeev,
    On Wed, May 7, 2014 08:36, Zeev Suraski wrote:
    On 7 במאי 2014, at 09:13, Sebastian Bergmann wrote:



    Playing devil's advocate: does anyone really need SAPIs other than
    FastCGI, CLI, and embed? And if so: do we care enough to burden
    ourselves with their maintenance?
    I think you just called me "the devil" ;)


    Seriously, I can't think of any *real* reason of why anybody would
    need something other than these SAPIs in 2014 (other than FUD). Things like
    ISAPI and other more esoteric SAPIs are no brainers, and
    while mod_php may be a bit more of a leap of faith, it doesn't truly brings
    any tangible benefits over FastCGI (none that can't be relatively easily
    replicated in userland anyway, eg htscanner).

    I'd support it.
    There's an RFC about it https://wiki.php.net/rfc/removal_of_dead_sapis .
    It came into being while working on the int64 branch, but now becomes more
    relevant with phpng. The simple idea is first to check all those, if it
    turns out those SAPIs will be supported by the authors, or at least
    there's a minority using them, it might make sense to port them.
    Implementing that RFC were a clean and predictable way to go IMHO.

    Regards

    Anatol
  • Ferenc Kovacs at May 7, 2014 at 9:56 am

    On Wed, May 7, 2014 at 8:36 AM, Zeev Suraski wrote:

    On 7 במאי 2014, at 09:13, Sebastian Bergmann wrote:


    Playing devil's advocate: does anyone really need SAPIs other than
    FastCGI, CLI, and embed? And if so: do we care enough to burden
    ourselves with their maintenance?
    I think you just called me "the devil" ;)

    Seriously, I can't think of any *real* reason of why anybody would
    need something other than these SAPIs in 2014 (other than FUD).
    Things like ISAPI and other more esoteric SAPIs are no brainers, and
    while mod_php may be a bit more of a leap of faith, it doesn't truly
    brings any tangible benefits over FastCGI (none that can't be
    relatively easily replicated in userland anyway, eg htscanner).

    I'd support it.

    Zeev

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    You forgot fpm and phpdbg from that list.
    A little bit offtopic, but I think it would be nice if we could have some
    pecl-like infrastructure to host and install 3rd party sapis without the
    need to bundle them with the core.

    ps: maybe something like https://bugs.php.net/bug.php?id=66589 could be
    also considered then.

    --
    Ferenc Kovács
    @Tyr43l - http://tyrael.hu

Related Discussions

People

Translate

site design / logo © 2018 Grokbase