7 ms·

PHP Next Generation

192 points by maratd 12y ago

mavci 12y ago
Also "The new PHP" http://programming.oreilly.com/2014/03/the-new-php.html http://programming.oreilly.com/2014/03/the-new-php.html
skywhopper 12y ago
There's some seriously missing context to this post. It sounds like they are responding to some expectations posted elsewhere, but they don't link to what they're responding to. Or perhaps it's an update to something announced earlier, but they don't link to the past announcement. It's not clear what PHPng's relationship, if any, is to 5.5 or 5.6 in this post. Anyone have any pointers to the conversation they are participating in with this post? (mavci's link is an O'Reilly summary of the state of the PHP ecosystem and I didn't see any mention of PHPng.) UPDATE: Perhaps this link is what started the confusion the php.net post appears to be trying to address: http://grokbase.com/p/php/php-internals/1455aesx7r/phpng-%04refactored-php-engine-with-big-performance-improvement http://grokbase.com/p/php/php-internals/1455aesx7r/phpng-%04...
- viraptor 12y ago
  There was a link a couple of days ago where I learned about phpng for the first time - it was some argument between php developers where core devs argued a change that made php5 nicer (standardised 64/32 field lengths / formats) made the phpng work harder. (undone some structure size optimisations) Maybe people discovered phpng that way and started asking questions about it? I can't find the actual link unfortunately.
- rjknight 12y ago
  This is a recently published article which suggests that PHPNG is an upgrade to the Zend Engine designed to compete with HHVM: http://www.sitepoint.com/php-fights-hhvm-zephir-phpng/ http://www.sitepoint.com/php-fights-hhvm-zephir-phpng/
  - skywhopper 12y ago
    Yes, this is exactly what I was looking for. Thanks, rjknight. Someone visiting php.net without knowing the context would be seriously confused by this post (as I was).
- chc 12y ago
  If you Google "PHPng", you'll find a number of articles from the past few days about how the project is going to bring fancy stuff like a JIT compiler to the next version of PHP. Presumably this is to ensure expectations are set correctly and people don't think things are around the corner that actually aren't even in the country yet.
- mavci 12y ago
  sadly O'Reilly didn't mention Laravel too
deleted 12y ago
[deleted]
1ris 12y ago
Isn't Hack the PHP of the future, aviable today? For me it seems with hack there are no excuses anymore to still use php. I'd be glad if someone tell me some downsides of hack, it seems to good to be true. And how do the JITs compare?
- MAGZine 12y ago
  Facebook moves fast. I'm not saying that they're going to abandon Hack or give it away to Apache or something, but if I were a corporation, sticking with vanilla PHP is attractive because it has a large developing body, and it's future isn't dependent on the whim of one company. Otherwise, yeah, Hack is an improved PHP. To be clear, it adds additional functionality to PHP, but is still entirely backwards compatible. PHP >= 5.4 still has solid bones.
  - jkoudys 12y ago
    Hack also works really nicely with PHP - I think a lot of PMs hear about hack and think it's a workalike but completely separate language, not realizing that you can (and almost always will) have hacklang running alongside php. You're capable of declaring a class in hack (with strict-typing, method return types, better collection objects than just having 'Array' everywhere), with that class directly extending a PHP class. 80% of the reason I use hacklang is just so I can extend whatever base PHP classes my CMS provides, but implement my methods without having to add the piles of manual type-checking that PHP requires.
    - girvo 12y ago
      I've not tried this yet, though my boss has given me the go-ahead. What editor do you use to find out how it's going? I struggle a little bit with it because I'm yet to vim-hack running. Do you just stick to the "code save refresh" cycle? Does Hack give you type checking error messages in the web page? Can you run a "check types" command on code from the terminal?
      - anaphor 12y ago
chx 12y ago
Pierre Joye from Microsoft started a big refactor in the open (make string length size_t everywhere) meanwhile Dmitry Stogov of Zend worked in total secret on an even bigger refactor which is phpng, completely ignoring the size_t work (also known as 64 bit). A feud in PHP Internals followed not the first heated debate there... that mailing list is very useful as a textbook example of how not to run an open source community. At the end, Pierre have decided it's better to cooperate and now http://news.php.net/php.internals/74352 http://news.php.net/php.internals/74352 there's a vote that seems to pass and so on top of phpng size_t is also coming.
- Yver 12y ago
  Most disheartening is the way Zeev Suraski pleaded for votes against the size_t/int64 patch in a mail[1] titled "A call for help (urgent)" because, I quote, it "negates months of hard work". That was only a few days after Zend's secret project had been uncovered. The size_t/int64 refactor has been going through several iterations and RFCs since 2013. [1]: http://news.php.net/php.internals/74268 http://news.php.net/php.internals/74268
  - kachnuv_ocasek 12y ago
    Why? Months of hard work can surely negate months of other hard work.
    - danudey 12y ago
      Sure, but it seems pretty irrational to suddenly say 'Hey guys, we've been working on this code without telling anyone, so this community project that people have been working on for months should be abandoned'. They could have been integrating the changes in their code as they went, and then launched with 'Hey, we have this cool new project, including the optimization work that people have been doing'. Instead, they kept their work secret, knowing that their work was incompatible with another large refactor that people were contributing to, and then said 'hey, abandon all the work you were doing because who cares'.
- CHY872 12y ago
gopalv 12y ago
Speaking as someone who's hit the barriers of PHP performance for many years, this is a good start. But I wish it was done a little nicely from the community point of view (the >4gb strings stuff). I'm considerably less talented than Dmitry and I spent several months of my life trying to unsuccessfully write a JIT for PHP - most of what stopped me was the rest of the Zend engine itself. While I was maintaining PHP-APC, I spent many weeks trying to write a basic block JIT for php, when Zend is using the CGOTO core (FYI, if you are still using APC, switch to Zend OpCache). This would compile code which didn't have any jumps into a native chunk and swap out the opcode's handler location into my native chunk. The little I did actually do ended up being fairly involved assembly rewrites of the inner loop. http://notmysock.org/blog/php/optimising-ze2 http://notmysock.org/blog/php/optimising-ze2 No matter what I did, the issues of the bytecode organization (the ->result reference) and the lack of type verifiability in the code generation resulted in me slowly throwing away every prototype somewhere between the for loop and running the default benchmark.php. I haven't read through all the changes yet, but IMHO the Zend engine will be an absolute pain to deal with until we get to type inference/verifiability into the bytecode format so that integers get integer register ops in the JIT instead of always being zval_* based. But a cleanup was due. And a faster VM (either HHVM or PHPng++) is good news for the regular PHP users.
atulatri 12y ago
I think it will be great if PHP's internal developers start focusing on HHVM. From comments it seems like some people are afraid that FB will keep driving HHVM project in it's own way. But this fact is dependent on contribution. FB may loose grip on HHVM if If people outside FB start contributing more on it.

192 points by maratd 12y ago

mavci 12y ago

Also "The new PHP" http://programming.oreilly.com/2014/03/the-new-php.html http://programming.oreilly.com/2014/03/the-new-php.html

skywhopper 12y ago

There's some seriously missing context to this post. It sounds like they are responding to some expectations posted elsewhere, but they don't link to what they're responding to. Or perhaps it's an update to something announced earlier, but they don't link to the past announcement. It's not clear what PHPng's relationship, if any, is to 5.5 or 5.6 in this post. Anyone have any pointers to the conversation they are participating in with this post? (mavci's link is an O'Reilly summary of the state of the PHP ecosystem and I didn't see any mention of PHPng.) UPDATE: Perhaps this link is what started the confusion the php.net post appears to be trying to address: http://grokbase.com/p/php/php-internals/1455aesx7r/phpng-%04refactored-php-engine-with-big-performance-improvement http://grokbase.com/p/php/php-internals/1455aesx7r/phpng-%04...

viraptor 12y ago
There was a link a couple of days ago where I learned about phpng for the first time - it was some argument between php developers where core devs argued a change that made php5 nicer (standardised 64/32 field lengths / formats) made the phpng work harder. (undone some structure size optimisations) Maybe people discovered phpng that way and started asking questions about it? I can't find the actual link unfortunately.
rjknight 12y ago
This is a recently published article which suggests that PHPNG is an upgrade to the Zend Engine designed to compete with HHVM: http://www.sitepoint.com/php-fights-hhvm-zephir-phpng/ http://www.sitepoint.com/php-fights-hhvm-zephir-phpng/
- skywhopper 12y ago
  Yes, this is exactly what I was looking for. Thanks, rjknight. Someone visiting php.net without knowing the context would be seriously confused by this post (as I was).
chc 12y ago
If you Google "PHPng", you'll find a number of articles from the past few days about how the project is going to bring fancy stuff like a JIT compiler to the next version of PHP. Presumably this is to ensure expectations are set correctly and people don't think things are around the corner that actually aren't even in the country yet.
mavci 12y ago
sadly O'Reilly didn't mention Laravel too

deleted 12y ago

[deleted]

1ris 12y ago

Isn't Hack the PHP of the future, aviable today? For me it seems with hack there are no excuses anymore to still use php. I'd be glad if someone tell me some downsides of hack, it seems to good to be true. And how do the JITs compare?

MAGZine 12y ago
Facebook moves fast. I'm not saying that they're going to abandon Hack or give it away to Apache or something, but if I were a corporation, sticking with vanilla PHP is attractive because it has a large developing body, and it's future isn't dependent on the whim of one company. Otherwise, yeah, Hack is an improved PHP. To be clear, it adds additional functionality to PHP, but is still entirely backwards compatible. PHP >= 5.4 still has solid bones.
- jkoudys 12y ago
  Hack also works really nicely with PHP - I think a lot of PMs hear about hack and think it's a workalike but completely separate language, not realizing that you can (and almost always will) have hacklang running alongside php. You're capable of declaring a class in hack (with strict-typing, method return types, better collection objects than just having 'Array' everywhere), with that class directly extending a PHP class. 80% of the reason I use hacklang is just so I can extend whatever base PHP classes my CMS provides, but implement my methods without having to add the piles of manual type-checking that PHP requires.
  - girvo 12y ago
    I've not tried this yet, though my boss has given me the go-ahead. What editor do you use to find out how it's going? I struggle a little bit with it because I'm yet to vim-hack running. Do you just stick to the "code save refresh" cycle? Does Hack give you type checking error messages in the web page? Can you run a "check types" command on code from the terminal?
    - anaphor 12y ago

chx 12y ago

Pierre Joye from Microsoft started a big refactor in the open (make string length size_t everywhere) meanwhile Dmitry Stogov of Zend worked in total secret on an even bigger refactor which is phpng, completely ignoring the size_t work (also known as 64 bit). A feud in PHP Internals followed not the first heated debate there... that mailing list is very useful as a textbook example of how not to run an open source community. At the end, Pierre have decided it's better to cooperate and now http://news.php.net/php.internals/74352 http://news.php.net/php.internals/74352 there's a vote that seems to pass and so on top of phpng size_t is also coming.

Yver 12y ago
Most disheartening is the way Zeev Suraski pleaded for votes against the size_t/int64 patch in a mail[1] titled "A call for help (urgent)" because, I quote, it "negates months of hard work". That was only a few days after Zend's secret project had been uncovered. The size_t/int64 refactor has been going through several iterations and RFCs since 2013. [1]: http://news.php.net/php.internals/74268 http://news.php.net/php.internals/74268
- kachnuv_ocasek 12y ago
  Why? Months of hard work can surely negate months of other hard work.
  - danudey 12y ago
    Sure, but it seems pretty irrational to suddenly say 'Hey guys, we've been working on this code without telling anyone, so this community project that people have been working on for months should be abandoned'. They could have been integrating the changes in their code as they went, and then launched with 'Hey, we have this cool new project, including the optimization work that people have been doing'. Instead, they kept their work secret, knowing that their work was incompatible with another large refactor that people were contributing to, and then said 'hey, abandon all the work you were doing because who cares'.
CHY872 12y ago

gopalv 12y ago

Speaking as someone who's hit the barriers of PHP performance for many years, this is a good start. But I wish it was done a little nicely from the community point of view (the >4gb strings stuff). I'm considerably less talented than Dmitry and I spent several months of my life trying to unsuccessfully write a JIT for PHP - most of what stopped me was the rest of the Zend engine itself. While I was maintaining PHP-APC, I spent many weeks trying to write a basic block JIT for php, when Zend is using the CGOTO core (FYI, if you are still using APC, switch to Zend OpCache). This would compile code which didn't have any jumps into a native chunk and swap out the opcode's handler location into my native chunk. The little I did actually do ended up being fairly involved assembly rewrites of the inner loop. http://notmysock.org/blog/php/optimising-ze2 http://notmysock.org/blog/php/optimising-ze2 No matter what I did, the issues of the bytecode organization (the ->result reference) and the lack of type verifiability in the code generation resulted in me slowly throwing away every prototype somewhere between the for loop and running the default benchmark.php. I haven't read through all the changes yet, but IMHO the Zend engine will be an absolute pain to deal with until we get to type inference/verifiability into the bytecode format so that integers get integer register ops in the JIT instead of always being zval_* based. But a cleanup was due. And a faster VM (either HHVM or PHPng++) is good news for the regular PHP users.

atulatri 12y ago

I think it will be great if PHP's internal developers start focusing on HHVM. From comments it seems like some people are afraid that FB will keep driving HHVM project in it's own way. But this fact is dependent on contribution. FB may loose grip on HHVM if If people outside FB start contributing more on it.