Mind also: With a CGI process for each request the process has to be created, program loaded, runtime linked and executed. With any semi-modern PHP setup the PHP process is running already (be it mod_php, fastcgi, fpm, ...) and the "compiled" version of the script is in memory ready to be executed (opcode caching) thus PHP can win in startup time.
If you then out the heavy calculation in a C extension module you get simple templating around it in quite fast.
Future versions of PHP might also receive some form of a JIT (experiments are well progressing) an ideal JIT might even beat a C program (as it can compile to the specific CPU and can analyse and optimize the hotpath; see also hotspot and similar Java runtimes) PHP won't be there (as the jit has to call too often into PHP runtime) but there's room for future iterations.
> Mind also: With a CGI process for each request the process has to be created, program loaded, runtime linked and executed.
Yeah, that's CGI though, FCGI alleviates this by persistently running a single process/service/application that listens to the port and acts according to the received HTTP headers.
Whatever PHP can optimize can thus be done directly with FCGI as well. You can load everything the webpage needs into memory and just pipe that through to the user, and it would only need to read disk once at startup (or if you update the sources, but that's another issue).
The downside is of course the increased development time and complexity you'd have to invest...
EDIT2: Another downside specific to FCGI is that it is OS-dependent, because it needs to interact with the host in order to listen to a port, something that doesn't affect normal CGI because all you need there is stdout.
And and if you scrap it and build some custom webserver or nginx plugin or Apache module it can be even faster or maybe something like IncludeOS which makes your application logic part of a minimal kernel ... If that's your aim. In most cases development time however is more valuable than pure execution time. (Even Facebook survived quite long in PHP, till it was wothwhile for them to move to their own thing)
Anyways comparison by GP was between a custom CGI program and PHP and not other things.
On Facebook: I'm willing to bet a switch to binary from PHP is one magnitude less of processing power required, and an early switch would've cut their server requirements by 90%. Not sure which would've been cheaper, the C devs or all those extra servers burning electricity to interpret a language during runtime.
EDIT: And that's just an economic incentive. From an ecological perspective, it's borderline criminal for a website as massive as Facebook to be running PHP.
By switching to HipHop for PHP and later HHVM they saved lots of servers. 90% is a bit too much (consider: they went "services" first, where different tasks were done in different languages in independent services) And yes, for the ecological argument that is true (even more ecological it would be to shut down Facebook ... )
However using PHP allowed them to hire lots of staff quickly and adapt to changed requirements quickly. Which is economical valuable. Finding the right time for a switch is simpler in a retrospective though ;-)
(I have no insight to Facebook, but was heavily involved in the PHP project and talked to different Facebook engineers privately and professionally)
Essentially, for the same task, PHP could never be as fast as a binary, because of the overhead of processing the language itself.
Creating a binary in place of PHP code is essentially reducing the calculatory load of a webpage to a minimum during runtime.