6 ms·

Ignoring the fact that these are all running on the standard PHP interpreter, not one of Facebook's creation... The benchmarks linked ran on a 4 core machine w

Ignoring the fact that these are all running on the standard PHP interpreter, not one of Facebook's creation... The benchmarks linked ran on a 4 core machine with varying amounts of parallelism, generally with Java being more parallelized. When running a server farm, as Facebook does, aggregate CPU time is more important than wall time^, since one can easily scale the number of processes to fit the machine. By CPU time the difference is down a factor of two at least, possibly more. Be careful with benchmarks. They distill a comparison into a single value for easy use, but it's not going to be the most appropriate metric in all cases. ^So long as wall time is "sufficiently small", which it generally is.

SomeOtherGuy 15y ago
So check the single core version: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... Oh look, PHP is still 30 times slower than java. A 60% improvement to that still won't get it within an order of magnitude. And PHP is not significantly faster or easier to develop in than java, so you are losing execution speed to gain nothing.
- maratd 15y ago
  Java is a compiled language. PHP is not. If you need to do a benchmark to realize that a compiled language is faster than its dynamic counterpart, then I really don't know what else to say to you.
  - fleitz 15y ago
    Some compiled languages are faster, some aren't. Speed of execution is largely related to the optimizations the interpreter / compiler can do, and in many practical cases the qualities of the default library. The other problem is that many interpreted languages are implemented in C leading to the usual performance implications of inner-platform effect. Another problem is the underlying CPU architecture, the vast majority of CPUs are designed to execute C-like languages.
  - afsina 15y ago
    What is your point? That does not chance the fact that using Php for a huge site like Facebook is a poor choice. A very poor choice indeed. They must be wasting energy on hundreds of servers because of this choice. One can hope that they are using Php only for the very basic front-end operations otherwise they are royaly screwed.
  - SomeOtherGuy 15y ago
    I don't know why you are saying anything to me since you are responding to something I didn't say and that has nothing to do with the post I made. Is "dim witted attempts to respond to poorly thought out strawmen" really the level of discourse here?
    - maratd 15y ago
      What? Who are you responding to?
      - SomeOtherGuy 15y ago
        You. You may want to consider that if there's two replies to your post, and both are "your post is entirely irrelevant", then perhaps your post genuinely is entirely irrelevant. Protip: read the whole thread from the top.
        maratd 15y ago
        Where did I say "dim witted attempts to respond to poorly thought out strawmen" or "your post is entirely irrelevant"? Either you're confusing me with someone else or you don't understand the concept of quotes.
        SomeOtherGuy 15y ago
        Again, read the entire thread. I am not confusing you with anyone else, and I understand the concept of quotes. You are failing to grasp the context of posts, and assuming everything anyone puts in quotes must be a statement you made. There are other people who post, why on earth would you think "your post is entirely irrelevant" is something I claim you said? I very clearly pointed out that two people replied to you saying that your post is irrelevant.
        maratd 15y ago
        > I very clearly pointed out that two people replied to you saying that your post is irrelevant. So you're just repeating what other people said? To make yourself feel better? Still a bit confused.
- j_col 15y ago
  > And PHP is not significantly faster or easier to develop in than java... Yes it is easier and faster to develop in (speaking as someone who has done both commercially). Examples of productivity gains: 1. No need to compile your code. Build cycle vastly improved (no time wasted with Ant/Maven/take your pick). 2. Less verbosity. 3. No need to restart your web server every time you deploy some new feature, just hit F5 on your browser and your done. 4. No classpath/jar file fun to slow your down. 5. You can hack a code fix in situ on a dev/server (or production if your brave/insane, I did say hack!). All you need is SSH. 6. Connecting to a database is trivial, support for most databases build in (no messing about with JDBC). 7. Deployments are a breeze: just drop the source code on your server, and you're done. I could go on. > so you are losing execution speed to gain nothing. I wouldn't call a much faster development cycle "nothing", and if you understand Facebook's culture of "move fast" as laid down by Zuckerburg, they value development time higher than execution time (and rightly so). * Edited to add line returns.
  - blibble 15y ago
    if you've done Java commercially you've used sub-par tools. 1. any decent IDE will compile as you type 2. I'll give you this one 3. Java supports dynamic class reloading, it works out of the box with jetty. 4. you just press "run" in the ide. 5. same applies to java, just requires you take your (automatically built) .class file 6. I'm not sure how difficult you think JDBC is.. you just give it the connection string and the driver name. 7. just drop the war into your servlet directory, and you're done
    - j_col 15y ago
      > if you've done Java commercially you've used sub-par tools. I spent 3 years doing Java on large-scale telco projects using IntellJ, I'm not an amateur Java dev. I now code PHP full-time on a social network. > 1. any decent IDE will compile as you type Fine, but my original point was about building for a production environment. > 2. I'll give you this one Thanks! > 3. Java supports dynamic class reloading, it works out of the box with jetty. You using Jetty with dynamic class loading enabled in production? > 4. you just press "run" in the ide. Once again, your local dev environment has nothing to do with production servers (where you obviously won't have an IDE). > 5. same applies to java, just requires you take your (automatically built) .class file And what if that .class file is buried in a .jar somewhere, which is in turn buried in a .war somewhere else? Not quite as easy as opening a .php file with vi on the terminal, is it? > 6. I'm not sure how difficult you think JDBC is.. you just give it the connection string and the driver name. ...and the driver has to be on the class path, and the driver might have local binary dependencies (depending on the vendor), and you have to be careful to ensure that you are using the correct driver .jar version for your version of the database, and ensure that it is packaged up will all of your other project dependencies when you build your .war/.ear etc. > 7. just drop the war into your servlet directory, and you're done ...after you have built the .war using a build technology like Ant or Maven (I refer you back to my original point 1 about the Java build/deploy cycle being more complex).
igouy 15y ago
> a 4 core machine with varying amounts of parallelism Let's force the programs onto one-core. http://shootout.alioth.debian.org/u32/php.php http://shootout.alioth.debian.org/u32/php.php > aggregate CPU time is more important than wall time Both CPU secs and Elapsed secs were shown. > Be careful with benchmarks. They distill a comparison into a single value for easy use, but it's not going to be the most appropriate metric in all cases. afsina pointed to a program-by-program comparison - not something distilled down to a single value.
- papaf 15y ago
  Meta comment: HN is becoming an incredibly sad place when the developer of the shootout benchmark site makes a technically valid and polite point - and people mark him down simply because they don't agree with it. And the irony is the shootout site is written in PHP - so its not like he is especially biased against it.

SomeOtherGuy 15y ago

So check the single core version: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=php&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... Oh look, PHP is still 30 times slower than java. A 60% improvement to that still won't get it within an order of magnitude. And PHP is not significantly faster or easier to develop in than java, so you are losing execution speed to gain nothing.

maratd 15y ago
Java is a compiled language. PHP is not. If you need to do a benchmark to realize that a compiled language is faster than its dynamic counterpart, then I really don't know what else to say to you.
- fleitz 15y ago
  Some compiled languages are faster, some aren't. Speed of execution is largely related to the optimizations the interpreter / compiler can do, and in many practical cases the qualities of the default library. The other problem is that many interpreted languages are implemented in C leading to the usual performance implications of inner-platform effect. Another problem is the underlying CPU architecture, the vast majority of CPUs are designed to execute C-like languages.
- afsina 15y ago
  What is your point? That does not chance the fact that using Php for a huge site like Facebook is a poor choice. A very poor choice indeed. They must be wasting energy on hundreds of servers because of this choice. One can hope that they are using Php only for the very basic front-end operations otherwise they are royaly screwed.
- SomeOtherGuy 15y ago
  I don't know why you are saying anything to me since you are responding to something I didn't say and that has nothing to do with the post I made. Is "dim witted attempts to respond to poorly thought out strawmen" really the level of discourse here?
  - maratd 15y ago
    What? Who are you responding to?
    - SomeOtherGuy 15y ago
      You. You may want to consider that if there's two replies to your post, and both are "your post is entirely irrelevant", then perhaps your post genuinely is entirely irrelevant. Protip: read the whole thread from the top.
      - maratd 15y ago
        Where did I say "dim witted attempts to respond to poorly thought out strawmen" or "your post is entirely irrelevant"? Either you're confusing me with someone else or you don't understand the concept of quotes.
        SomeOtherGuy 15y ago
        Again, read the entire thread. I am not confusing you with anyone else, and I understand the concept of quotes. You are failing to grasp the context of posts, and assuming everything anyone puts in quotes must be a statement you made. There are other people who post, why on earth would you think "your post is entirely irrelevant" is something I claim you said? I very clearly pointed out that two people replied to you saying that your post is irrelevant.
        maratd 15y ago
        > I very clearly pointed out that two people replied to you saying that your post is irrelevant. So you're just repeating what other people said? To make yourself feel better? Still a bit confused.
j_col 15y ago
> And PHP is not significantly faster or easier to develop in than java... Yes it is easier and faster to develop in (speaking as someone who has done both commercially). Examples of productivity gains: 1. No need to compile your code. Build cycle vastly improved (no time wasted with Ant/Maven/take your pick). 2. Less verbosity. 3. No need to restart your web server every time you deploy some new feature, just hit F5 on your browser and your done. 4. No classpath/jar file fun to slow your down. 5. You can hack a code fix in situ on a dev/server (or production if your brave/insane, I did say hack!). All you need is SSH. 6. Connecting to a database is trivial, support for most databases build in (no messing about with JDBC). 7. Deployments are a breeze: just drop the source code on your server, and you're done. I could go on. > so you are losing execution speed to gain nothing. I wouldn't call a much faster development cycle "nothing", and if you understand Facebook's culture of "move fast" as laid down by Zuckerburg, they value development time higher than execution time (and rightly so). * Edited to add line returns.
- blibble 15y ago
  if you've done Java commercially you've used sub-par tools. 1. any decent IDE will compile as you type 2. I'll give you this one 3. Java supports dynamic class reloading, it works out of the box with jetty. 4. you just press "run" in the ide. 5. same applies to java, just requires you take your (automatically built) .class file 6. I'm not sure how difficult you think JDBC is.. you just give it the connection string and the driver name. 7. just drop the war into your servlet directory, and you're done
  - j_col 15y ago
    > if you've done Java commercially you've used sub-par tools. I spent 3 years doing Java on large-scale telco projects using IntellJ, I'm not an amateur Java dev. I now code PHP full-time on a social network. > 1. any decent IDE will compile as you type Fine, but my original point was about building for a production environment. > 2. I'll give you this one Thanks! > 3. Java supports dynamic class reloading, it works out of the box with jetty. You using Jetty with dynamic class loading enabled in production? > 4. you just press "run" in the ide. Once again, your local dev environment has nothing to do with production servers (where you obviously won't have an IDE). > 5. same applies to java, just requires you take your (automatically built) .class file And what if that .class file is buried in a .jar somewhere, which is in turn buried in a .war somewhere else? Not quite as easy as opening a .php file with vi on the terminal, is it? > 6. I'm not sure how difficult you think JDBC is.. you just give it the connection string and the driver name. ...and the driver has to be on the class path, and the driver might have local binary dependencies (depending on the vendor), and you have to be careful to ensure that you are using the correct driver .jar version for your version of the database, and ensure that it is packaged up will all of your other project dependencies when you build your .war/.ear etc. > 7. just drop the war into your servlet directory, and you're done ...after you have built the .war using a build technology like Ant or Maven (I refer you back to my original point 1 about the Java build/deploy cycle being more complex).

igouy 15y ago

> a 4 core machine with varying amounts of parallelism Let's force the programs onto one-core. http://shootout.alioth.debian.org/u32/php.php http://shootout.alioth.debian.org/u32/php.php > aggregate CPU time is more important than wall time Both CPU secs and Elapsed secs were shown. > Be careful with benchmarks. They distill a comparison into a single value for easy use, but it's not going to be the most appropriate metric in all cases. afsina pointed to a program-by-program comparison - not something distilled down to a single value.

papaf 15y ago
Meta comment: HN is becoming an incredibly sad place when the developer of the shootout benchmark site makes a technically valid and polite point - and people mark him down simply because they don't agree with it. And the irony is the shootout site is written in PHP - so its not like he is especially biased against it.