Hacker News Reader

Comment by daremon | Hacker News Reader

"...that will increase speed by around 80%..."

I guess this is compared to plain PHP not to accelerators? And what exactly is the difference from a PHP accelerator?

I think it is quite irrelevant to wonder about such details, as the article proceeds to spout nonsense like

   The project is very similar to Google's Unladen Swallow
   project, which rebuilt the Python compiler, boosting the
   speed fivefold [..]

There is not a word to be trusted, as the author clearly doesn't know what he is talking about.

The typical PHP accelerators cache bytecode rather than native code.

Yes but I wonder how much it will really help. Is the bottleneck for Facebook-like sites really in the bytecode dispatching as opposed to e.g. string/regexp operations or database calls?

It seems sensible to assume it helps them for something otherwise why bother developing and releasing it? I also don't think it's a matter of bottleneck - if you make the front-end php run faster you need fewer servers, fewer servers/user, more money. This has come up in discussions about google as well - there are some scales at which even comparatively modest improvements in efficiency count. It probably won't make a world of difference to My Cousin's Personal Basement URL Shortener.

>It seems sensible to assume it helps them for something otherwise why bother developing and releasing it?

Well surely the proof is in the eating - that is, if they've implemented it then it clearly works, they wouldn't be stupid enough to implement it if it's going to cost them money.

To answer your [rhetorical] question: The cost for this has been one developer for a year. That's not much for a speculative shot at increased server efficiencies that could save them big money in the server farm. Once they've developed it, even if it didn't produce the gains they needed then releasing it is sensible as it gains them some PR amongst the OS community and may get more fixes from that same community improving the result (lower costs) for FB.

We don't really know anything about it. One developer, five developers, 10, 20, 9923123% better. Let's just see what they release, if anything.

Sorry I read somewhere else that it was a single dev and that the gains were expected to be 5x improvement in speed for the same processing power. Can't recall where.

As far as I can tell Facebook use memcached so extensively that practically everything is served out of it, so their bottleneck could well be the PHP application code as opposed to the data fetching. In any case, when you're serving potentially millions of page views a second even a small optimisation can save you from buying a ton of extra hardware.

JIT native code compilers do make quite a bit of difference over byte code execution is some situations. E.g. loops over many elements (say loops that concatenate large HTML fragments, ok the string operation are already native, but other bits of the loop will not be (e.g. array access)).

So, I agree that the main 'bottleneck' in most PHP apps is probably not-PHP itself, there is still scope for improvement.

When you're running 1000s of servers, it's not about the one big bottleneck anymore. 5 or 10 or 20% improvements then suddenly become worthwhile.

Could be, in the case that those two have already been optimized or removed as much as possible.

Reply on news.ycombinator.com