
PHP Next Generation - maratd
http://www.php.net/archive/2014.php#id2014-05-27-1
======
gopalv
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.

------
chx
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
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
Why? Months of hard work can surely negate months of other hard work.

~~~
danudey
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'.

------
skywhopper
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-%04...](http://grokbase.com/p/php/php-
internals/1455aesx7r/phpng-%04refactored-php-engine-with-big-performance-
improvement)

~~~
rjknight
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
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).

------
1ris
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?

~~~
rafekett
you're probably interested in the downsides of HHVM, not Hack. Hack is really
just a PHP frontend built on top of HHVM. HHVM is the JIT.

\- it runs really well on expensive, FB hardware. there's no consideration
given to anything else (performance-wise) in development. that's not to say
it's slow, but it works best on 64GB servers with fat SSDs.

\- it's a huge moving target when it comes to php5 compatibility -- there are
a few intentional inconsistencies and a lot of unintentional ones. fixes for
zend incompatibilities have a whack-a-mole effect: the typical patch fixes one
inconsistency and introduces a few more.

\- bad documentation and bad code quality

\- it is open-source, but only in the most superficial sense. it's really an
FB internal project, so good luck making any changes that help you but don't
help FB

it's still better than zend PHP, and, to be fair, most of the
incompatibilities are in cases where zend behaves stupidly. source: i was an
HHVM contributor. (edited to space out my ascii list)

~~~
jkoudys
I half disagree with the third point - the documentation is certainly lacking
(I recently used Redis on an HHVM site, and the adaptor had no documentation
that it even existed; just read the source to figure it out), but it's a new-
ish, fast-moving project, so that's not too surprising.

The code quality, however, isn't 'bad' by any stretch of the imagination. The
FB team managing it is very knowledgeable about PHP internals, and are
appropriately strict about determining what zend-compatibility fixes to
commit. Their code's overall quite well-written, which makes me care a whole
lot less about how poorly it's documented.

~~~
rafekett
depends on what you define as good quality. it's efficient code, but it's
sparsely commented, and a style nightmare.

~~~
aruggirello
Odd. If I recall correctly, there was even a detailed FB PHP coding style
guide in the HHVM Git repo; that was afterwards removed though - I don't know
why.

------
mavci
Also "The new PHP" [http://programming.oreilly.com/2014/03/the-new-
php.html](http://programming.oreilly.com/2014/03/the-new-php.html)

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

