By now probably everybody that is connected to PHP world knows about Facebook’s HipHop.
So here are my thoughts about it.

1. This is a very cool and exciting technology. There were multiple attempts to do this in various ways, and from what it looks, HipHop is the most successful and appealing. I know doing these things is not easy – I tried something like that myself somewhere back in 2006 but was unable to go past very basic examples (I also made a mistake of choosing C instead of C++ as target, which I now think was not a smart decision). And the progress and support for almost all of the PHP magic is definitely great. There still are unsupported areas, but mostly are dark corners into which not many people venture (or should venture, at least

2. I do not see it as a replacement for php.net code or Zend Engine. The mainstream of PHP development still happens in the community around php.net and I do not think it is going to change anytime soon. I also see the fact that HipHop engine basically re-implements all the extensions as a serious disadvantage, for which the solution should be sought, even though I completely understand the technical reasons for doing so. I do not know which kind of the solution but while for the company like Facebook it might be OK to “freeze” certain set of extensions and features and maybe catch up periodically, I think it is obvious how such model can be a problem for the wider adoption.

3. If we talk about broader adoption of this technology in a wider PHP world, there are some serious challenges to consider:

• Plugins: right now, you must compile your whole application. However, many real-life applications have extensive plugin models, which consist of their main competitive advantage – take WordPress, Drupal, Magento, any Zend Framework app – all of these allow to write custom plugins and run them alongside the main code base. The model in which you have to rebuild whole application each time you add/change a line of code is not acceptable in these circumstances.
• Modularity: this is connected to the above, but is a bit different. PHP right now runs on Apache, IIS, Lighty, nginx, and tons of other servers in different environments. For the use of the technology in the wide variety of environments PHP is used in, one must be able to modularize  and separate the application PHP code from the runtime and the environment.
• Portability: I tried to run a bunch of my scripts through the demo that the HipHop team was very kind to give me – and most of them experiences unsupported functions or some function didn’t work exactly as their PHP counterparts (random example: PHP’s fopen() would error out given empty first argument, while HPHP implementation would open the current directory as file. There are more such things…). Now, I admit, it would be very easy to fix them, to use different functions and they would work, but again I think it’s obvious how it can be a problem for a PHP programmer, if you are not coding targeting HipHop specifically – and especially of you use 3rd-party code. Having different implementations always presents portability challenges.
• Thread-safety: A huge problem with PHP thread-safety is third-party libraries. Many of them are not thread safe either explicitly, or, even worse, implicitly – i.e. they just have either bugs or information leaks between threads (like changing some setting in one thread and feeling its effect in another – imagine chdir() leaking through the thread boundaries – see how it can be a problem?) HipHop team’s answer to this question was “we had fixed all those extensions” – which, without diminishing the capabilities of this excellent team, I think is not a satisfactory answer. It very well may be that they indeed fixed all the problems they could see in the code they run – but let us not forget they run one (albeit huge) application. I have hard time believing they have fixed every threading problem with every C library in existence that has interface to PHP and will continue to do so as long as C libraries exist. This of course goes back to modularity question, since here we have coupling between compiling and runtime model.
• Debugging: obviously, debugging C++ code is orders of magnitude harder than PHP code. So you either need ninja debugging skills, or a very good set of tools to allow you to identify a problem in a live server running non-source PHP.

4. I also see certain danger potential in the success of this project. The danger primary being that the performan

Truncated by Planet PHP, read more at the original (another 2916 bytes)

Well we all have read the announcement and chatted, twittered or whatever about it. I agree thats its cool this is being open sourced. I do fear however this means that there is no one less company looking after APC (mainly leaving just Yahoo then?). For now I think this is mainly interesting for "researchers" willing to work on improving the compatibility and more importantly the workflow around HipHop. I do not expect that anyone can really get a meaningful return on investment who makes this their business anytime soon (unless they can sell people on the hype), besides FB of course.

Overall I am not so impressed with the numbers. Even a 50% speed gain across the board .. what does that really mean? Lets say Facebook spends one third of the request (and I expect this to be even lower) on network and disk I/O, then this means that they managed a performance increase by a factor of 4 in the pure PHP processing parts. Note that I talked to some of the guys at the presentation and they said that the noted 50% speed up was not a result of switching the webserver (the binary generated by way of the C++ transformation includes a multi threaded webserver).

This is of course a nice speedup but wouldn't we expect at least a 2 fold .. or more increase if we could transform our PHP code into a C extension? This approach seems a lot more feasible for the masses. Like we could just drop in a ext/symfony or ext/ZF and thanks to autoloading magic our setup would continue to run unchanged. While it might not get that 4 fold speed up .. I would be willing to wager that it would get a 2-3 speed increase in the pure PHP processing.

So again I welcome any company open sourcing stuff that solved real world problems, especially if they are also willing to support the community in understanding their solution. But to me this solution will only matter for the ultra large companies where every single percent of saved CPU cycles matter. For the rest of us I think we need to rely on APC for a bit longer. But maybe with this transformator out there, other people will start working on the much more feasible approach of writing a PHP Code to C extension transformator.

A lot has already be speculated about what percentage of existing PHP users would benefit from using HipHop. The numbers seem to range somewhere between 0% and 100%. I will not try a guess myself, but rather try to shed some light on some the most important prerequisites I think there are for a company to benefit from HipHop.

By now, you might have heard the details of HipHop, Facebook’s PHP-to-C++ convertor that was announced yesterday. Like most of you, I’m eagerly awaiting the release of the code so that I can play with it and learn in detail what it can do and what it can’t. For now, Marco’s post seems to have the most technical information in it so far.

I’m with Sebastian on this one. Whether or not you think Facebook’s HipHop is relevant to you, I think they deserve credit for having shared their particular solution with the wider community. (They’ll get extra credit when they actually release some code ) After all, they’ve built on top of open-source in the first place; giving something back to the community is part and parcel of being a good member of the community.

How many of you earn your living from open-source, but have never contributed anything back?

But that isn’t really what I want to blog about today.

I’ve been following the chat on Twitter about HipHop, and I think all the nay sayers have been overlooking an important point. HipHop has the potential to reduce the amount of power consumed in running a website. And surely that can only be a good thing for all of us?

If you don’t run your own servers in a data centre (for example you use a virtual server, or host on a shared hosting solution), then perhaps you might not be aware that the power required by each server in a rack is often a major factor in the overall cost of running the servers. Whether or not you believe in climate change, energy prices are on the rise. Whether or not you believe in peak oil, oil and natural gas supply issues are forecast to push energy prices up further. Taking steps to get more work done per unit of power consumed has been the focus of hardware manufacturers for several years now. Isn’t it time it also was the focus of the software community too?

CPU usage is only one aspect of the total power consumed by a server in a rack, but in my experience people tend to add more servers to their solution primarily because they need more CPUs running their web servers to handle more traffic. A reduction in the number of CPUs required will translate into a reduction of the number of servers required … which means a reduction in the amount of energy being consumed.

How can that not be a good thing, if it can be achieved?

I know the answer will be that PHP apps are not CPU-bound, that they spend much of their time waiting for results from the database. That might be true if you’re measuring a PHP app from the point of view of elapsed time, but what if you’re measuring the PHP app in terms of CPU cycles consumed? Every single PHP script has to run on a CPU, and has to get to the point where it’s sat waiting for the database. If HipHop means that each PHP script uses less CPU to get to the same point, that has to be a step in the right direction.

Until we can play with HipHop ourselves, it’s impossible to say whether it saves enough CPU cycles to allow us to use less CPUs and therefore less servers. Remember, you’ve still got the overhead of your operating system and web server to factor into the equation. And then there’s the energy cost of compiling your code in the first place during development; for seldom-visited websites, HipHop may increase overall energy requirements.

But it sure is nice to hope, isn’t it?

Disclosure: Since Facebook Inc. is a customer of thePHP.cc, I might be considered biased. For the purpose of this blog posting, consider me taking off my "thePHP.cc hat" and putting on my "PHP Community hat".

The Announcement

Yesterday Facebook Inc. announced "HipHop for PHP", a source code transformer that turns PHP 5.2 code (minus some features) into C++ code that can then be compiled with g++, for instance, to a regular binary.

The Summit

If you are following some key PHP community members on Twitter, you may have learned that a couple of weeks ago Facebook invited a select few to Palo Alto, CA to give them a sneak peek at the technology.

Terry Chay has a great summary of this event (including photos):

At the Summit
Facebook, Palo Alto, California

This "private summit" is one of the reasons why this announcement was preceded with a lot of rumors. I am not really interested in rumors (or conspiracy theories, for that matter), so I will focus on the technology and its impact here.

My Opinion

I am very happy — both as a "programming language geek" as well as an Open Source enthusiast — that Facebook Inc. decided to open source their solution to their problem. Understanding this is crucial:

• Facebook had a problem.
• Facebook found a solution for their problem.
• Facebook decided to share their solution with the PHP community at large.
  Kudos for that!

Now what was their problem?

Facebook has a large code base that would take a long time (one to two years by my estimation) to refactor or rewrite in either PHP or another programming language to achieve the performance improvement that Facebook was looking for. During this time of refactoring or rewriting, Facebook would not have been able to innovate.

In the past, Facebook tried to achieve performance improvements by contributing to PHP as well as APC. Many PHP deployments benefit from this contributions today, but for Facebook they were simply not enough.

From this perspective it makes a lot of sense to dramatically change the way that they deploy and execute their PHP code: without major modifications to their existing code base they are able to run it with a CPU usage reduced by 50%:

"Facebook sees about a 50% reduction in CPU usage when serving equal amounts of Web traffic when compared to Apache and PHP.

Facebook's API tier can serve twice the traffic using 30% less CPU."

This is a sustainable solution for them as it allows them to benefit from PHP's advantages such as shorter development cycles and lower training costs — while at the same time, thanks to HipHop, reducing their data center costs.

What others are saying ...

Terry Chay is spot on when he summarizes the impact of HipHop in his blog posting:

"Arguing against PHP for performance reasons no longer holds water. [...]

In practice, you can get the advantages of having a scripting language without operational costs. [...]

HipHop is a showcase. With it the PHP world can point to Facebook as being the busiest site built in a scripting language in the world."

Stefan Priebsch (also with thePHP.cc) makes the point that you need to rethink your PHP development before you can dance to the HipHop beat:

"HipHop executes PHP code bypassing the Zend Engine, so there is no guarantee that a program will behave exactly alike on PHP and HipHop. More and better automated unit and integration tests will be required to allow you to compare the results on PHP and on HipHop, and determine whether deviations are to be interpreted as a bug, or can be tolerated."

I could not agree more: As there is a real build — including a real compilation — with HipHop, best practices such as coding standards and continuous integration will be even more important.

In conclusion, I would like to welcome "HipHop for PHP" to the PHP ecosystem. Yes, it is not a solution for a problem faced by 99.9% of the PHP deployments out there. But this does not make it less interesting in any way.

One more thing ...

PHPUnit runs on "HipHop for PHP", details can be found in the wiki.

My apologies to Ron Burgundy for the title of the post, but I’m just a fan of the wisest man to ever live.

It’s not for you.

You, being the average PHP developer, systems administrator, hacker.  A lot is being made of how CPU load went down by 50% etc, that’s a great number and on the surface very hard to argue with, but to really understand it, you must understand the problem a lot better. Facebook didn’t decide to write HipHop and use it in production because they had all this money laying around and felt like paying 3 engineers to work on something. They looked at other existing alternatives, implemented them, and when they maxed them out, decided to switch.

HipHop Does Not:

If anything, HipHop should be your last resort.

But, it’ll help me reduce the number of web heads!

Yesterday, Facebook released HipHop for PHP, a compiler which makes native code from PHP sources (via C++ and gcc). They promise twice the speed with that approach, something which helps you a lot if you have 1000s of servers like Facebook. I won't bore you with the technical details and what it can and can not do as Ilia already summed that up pretty nicely.

We at Liip will certainly look into this technology once it's available and evaluate if it would makes sense for some of our customers and project. As HipHop is not a drop-in replacement for your existing setup this is something which has to be planned and tested carefully. You have to change the way your servers are setup and the way you develop and deploy. It even needs a server restart, if you change some code, so badmouths can now claim that PHP is even more becoming like Java :)

A high amount of Switzerland's most visited sites run on PHP (and some of them are even done by or with us) and maybe HipHop could be useful for some of them, after all the usual optimizations (like APC, memcached, etc) didn't help enough. But for most websites (and more so for small ones), PHP's speed isn't really the bottleneck, it's the database or some other external dependency. And for these cases HipHop isn't the holy grail. So before you change all your setup to fit into HipHop's requirements, do some decent evaluations, what really is the bottleneck in your application and decide accordingly.

There’s been lots and lots of discussion regarding the Facebook “Hyper PHP” release of HipHop for PHP. This new technology is an in-production converter for PHP that takes PHP code, converts it into C++ code, and creates a complete binary that can be run on a server natively. Facebook claims improvements of up to 50%, [...]

Today Facebook released a HipHop l33t shizznizzle of a tool for PHP but sadly it's not the PHPVille I was hoping for. PHPVille is probably a game that encourages PHP community members to work on the PHP project (over at php.net). Much like FarmVille, users simply cannot stop playing!

Possible game features:

• 
  
• Each SVN commit builds up your worth
• 
  
• Not tending to or feeding your PECL extensions will result in them drying up and dying
• 
  
• Dead PECL extensions may live on as zombies, as once in awhile people will resurrect them
• 
  
• Eventually you may purchase things like an @php.net email address, and karma for other SVN repositories
• 
  
• Neighbors share and improve each others code
• 
  
• Future enhancement: The selling of karma, in bulk
• 
  
• Future enhancement: When Oracle purchases PHP, you'll be rich! [in PHPVille cash]
• 
  

PHPVille members often discuss matters within the #php.pecl and #php.doc IRC channels on EFnet, or on the various mailing lists.

If you have other PHPVille ideas then please post them here and we'll create the best facebook application ever! Also, thanks to Ralph and Ilia for discussing this on IRC and offering some of the ideas above. :)

Facebook have announced a significant project around PHP that I saw previewed at a small tech summit last month. No, Facebook did not announce PHPVille. Facebook announced HPHP, pronounced hip-hop. "HipHop programmatically transforms your PHP source code into highly...