6 ms·

Does that mean networks move bits faster and hard drives spin faster for C++ than they do for PHP?

prodigal_erik 17y ago
It gets you closer to the theoretical maximum of your network and memory busses. When a single machine can generate queries and lookups and log and render results faster, you need fewer machines to handle a given load. I know we increased our web front end capacity by 5x when we migrated from PHP to Java that runs backend queries asynchronously, so we reallocated some boxes and now we won't need to light up new hardware for a while. The inefficiency of PHP really adds up when you reach hundreds of cores.
- mechanical_fish 17y ago
  That sounds like an architectural change, not a problem with PHP's runtime. It's quite possible that the solution to your particular problem can be better expressed in another language than PHP, or will run faster under a different language's runtime. This doesn't mean that PHP "is slow". It might mean that your problem is an imperfect fit for a PHP-based architecture at your particular scale.
  - prodigal_erik 17y ago
    We have made architectural changes, but not that day. We literally had a drop-in replacement that did the same work but sustained 5x the request volume before saturating on the same machines, with the rest of the datacenter unchanged. (The async client was merely for latency, not throughput.) I don't believe any PHP runtime can ever be the fastest solution for a problem. The language requires runtime type checks and coercions inside the operators and builtin functions, both keyed and ordered access to every collection, ad hoc creation and destruction of variable bindings by name, and dynamically switching to reference semantics for any existing value. Each of these imposes a cost on passing arguments and evaluating expressions, and I didn't find any of them paid off by making code much simpler.

It gets you closer to the theoretical maximum of your network and memory busses. When a single machine can generate queries and lookups and log and render results faster, you need fewer machines to handle a given load. I know we increased our web front end capacity by 5x when we migrated from PHP to Java that runs backend queries asynchronously, so we reallocated some boxes and now we won't need to light up new hardware for a while. The inefficiency of PHP really adds up when you reach hundreds of cores.

mechanical_fish 17y ago
That sounds like an architectural change, not a problem with PHP's runtime. It's quite possible that the solution to your particular problem can be better expressed in another language than PHP, or will run faster under a different language's runtime. This doesn't mean that PHP "is slow". It might mean that your problem is an imperfect fit for a PHP-based architecture at your particular scale.
- prodigal_erik 17y ago
  We have made architectural changes, but not that day. We literally had a drop-in replacement that did the same work but sustained 5x the request volume before saturating on the same machines, with the rest of the datacenter unchanged. (The async client was merely for latency, not throughput.) I don't believe any PHP runtime can ever be the fastest solution for a problem. The language requires runtime type checks and coercions inside the operators and builtin functions, both keyed and ordered access to every collection, ad hoc creation and destruction of variable bindings by name, and dynamically switching to reference semantics for any existing value. Each of these imposes a cost on passing arguments and evaluating expressions, and I didn't find any of them paid off by making code much simpler.