3 ms·

Isn’t modern PHP much faster though?

pgcj_poster 7y ago
Not for "heavy calculation loads."
chasil 7y ago
For many purposes, it is not, and some of these use cases will be addressed in PHP 8. https://news.ycombinator.com/item?id=19535564 https://news.ycombinator.com/item?id=19535564
klingonopera 7y ago
Correct me if I'm wrong, but PHP is interpreted at runtime, whereas a binary file... is directly executed? 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.
- johannes1234321 7y ago
  It won't be faster, but could be fast enough™. 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.
  - klingonopera 7y ago
    > 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.
    - johannes1234321 7y ago
      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.
      - klingonopera 7y ago
        Thanks for IncludeOS, that sounds interesting... 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.
        johannes1234321 7y ago

Not for "heavy calculation loads."

For many purposes, it is not, and some of these use cases will be addressed in PHP 8. https://news.ycombinator.com/item?id=19535564 https://news.ycombinator.com/item?id=19535564

klingonopera 7y ago

Correct me if I'm wrong, but PHP is interpreted at runtime, whereas a binary file... is directly executed? 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.

johannes1234321 7y ago
It won't be faster, but could be fast enough™. 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.
- klingonopera 7y ago
  > 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.
  - johannes1234321 7y ago
    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.
    - klingonopera 7y ago
      Thanks for IncludeOS, that sounds interesting... 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.
      - johannes1234321 7y ago