blog’s amazing

HipHop for PHP from Facebook hit the streets several days ago resulting in dozens of posts about the technology. Let’s see what the PHP community says:

• Marco Tabini enlists the HipHop features and encourages using it
• the echolibre blog talks about possible security/buffer overflow implications, and mentions similar available solutions
• Ilia Alshanetsky provides an excellent and thorough overview: he goes into technical details and also practical usage. Though 99.9% of PHP deployments out there do not share the same challenges as Facebook (massive, continually evolving code base and equally massive traffic), [HipHop is also] an incredibly impressive technical achievement, [...] a very helpful development for PHP community in general.
• Brandon Savage: benefits are large for producers of large-scale web applications written in PHP and who distribute PHP code to clients directly - but HipHop is not the choice of the every day developer.
• Christian Stocker/LIIP: 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.
• Vid Luther/ThirdPartyCode: It’s not for you. The number of servers arguments comes into play when you can eliminate > 100 servers. If you’re going from 4 servers to 2, I guarantee you that you’re doing it wrong.
• Sebastian Bergmann: 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. [...] 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.
• Stuart Herbert “Can HipHop Help The Planet?”: [...] 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. [...] 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. [...] But it sure is nice to hope, isn’t it?
• Lukas Kahwe Smith/Poo-tee-weet: I do not expect that anyone can really get a meaningful return on investment who makes this their business anytime soon. [...] 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. [...] 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.
• Stas/PHP 10.0 blog: there are some serious challenges to consider: plugins, modularity, portability, thread-safety, debugging. [...] Danger primary being that the performance is very important in the web world, and it can give an incentive to the PHP community to change PHP in ways that may be better for performance, but would make PHP into being an entirely different language.
• Stefan Priebsch wrote another excellent summary about what to expect: as there’s a functional gap between PHP and HipHop, HipHop will always lag a little behind. You’ll need to adapt strict coding guidelines and more automated tests to make sure your HipHop’d code work as expected. On the server side you may need to compile code for different processor architectures or unify your servers, and also take care of web server features currently handled by Apache or LightTPD (URL rewriting, load balancing, proxying, etc.). You also need to scale your infrastructure together with HipHop to keep up with the increased throughput.