7 ms·

I find it interesting that the economics of inertia work out in favor of Facebook expending so much effort in improving the performance of a historically techno

by nupark2 15y ago

I find it interesting that the economics of inertia work out in favor of Facebook expending so much effort in improving the performance of a historically technologically poor language like PHP. Jason Evans is the author of jemalloc (and more). Given all the things he would be capable of applying himself to, it's surprising to see him working on PHP runtime performance (though, the problems are interesting).

hvs 15y ago
I'm not sure that I'd refer to PHP as a "historically technologically poor language". I'm not even quite sure what that means, exactly, but PHP has proven itself over and over again to be more than capable of working in environments with heavy load and numerous simultaneous users. In fact, in comparison to something like Ruby, it historically destroys it. Now, if you want to get into the details of syntax, naming conventions, etc.. sure, PHP is not everyone's favorite language to work with, but it is far from "technologically poor".
- nupark2 15y ago
  I'm referring to the quality of the implementation, its performance profile, the soundness of the type system and syntax, and -- like the original post -- measuring relative to the state of the art in JITs, including the JVM.
  - j_col 15y ago
    If the JVM is state of the art, how many applications of the scale of Facebook are using it? A serious question, as I don't know of any.
    - nupark2 15y ago
      The JVM is one of the most advanced production-quality JITs available. As for who is using it, everyone from Google to Twitter to Apple, as well a huge number of high-transaction business systems. The JVM is something that tends to get used quietly and widely.
      - j_col 15y ago
        It's also in my experience a massive memory hog, makes deploying your web application a pain (restarts anyone?), and is much more complex to develop for. If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)?
        nupark2 15y ago
        > It's also in my experience a massive memory hog It's not that Java is memory hog per se, but rather that the total VM memory allocation must be specified at launch, and the VM will not (rarely?) give that memory back to the OS. This is largely an artifact of Sun's generational GC design+implementation, and has some interesting performance wins; namely, object allocation and deallocation are incredibly cheap, because in the fast case, all allocation requires is updating a single pointer. The last time I profiled java object allocation, creating short-live objects turned out to be insanely cheap compared to other allocators/runtimes. > Makes deploying your web application a pain (restarts anyone?) This largely depends on how you structure your web application. > If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)? That depends largely on how much they're spending on hardware and JIT/language engineers, versus how much a rewrite would cost, amortized over the reasonable lifetime of their code base. You have to factor in the fact that they've built an entire organization around PHP, and it's not just a technological migration problem; they might also have to retrain or outright replace a large number of existing engineers. I'm inclined to say that it was a mistake to choose PHP, and moreover, to continue to use PHP as they scale. However, funding the implementation of better PHP runtime implementation may be the most fiscally conservative decision left available to them.
- maratd 15y ago
  Absolutely. PHP just works and it's easy to make it work. That's the most important thing when choosing a platform. Asthetics are always secondary. It's certainly a pain to deal with inconsistent syntax, but fighting your toolchain is a far worse fate and with PHP, that's rarely an issue.
  - laconian 15y ago
    For a hack, maybe. Fighting your toolchain is an upfront penalty. Once things start moving smoothly, they tend to continue to work smoothly. And that's a problem that can be solved by further development of the toolchain. Poor aesthetics/readability? You pay that price every second you work on the code.
    - maratd 15y ago
      > Once things start moving smoothly, they tend to continue to work smoothly. This is flat out wrong. If you're on a language all the cool kids are using, you'll find those cool kids have an obsession with perfection. To the point where they deprecate things instantly and break everything that worked before. See NodeJS and Python for examples. If you have 10K lines of code, not so bad. So you do a rewrite every year. When you have 100K lines of code or more, their obsession with perfection will destroy your business. A rewrite becomes an immense undertaking. You end up running old versions. Those old versions require dependencies which require you to run old operating systems. Eventually the entire ecosystem implodes. But guess what? Code that was written in PHP3 over 10 years ago works just as well today under PHP5. You can even mix and match. Does that make the syntax of the language ugly? Sure. It even encourages bad practices. So what? You're running a business, not an art gallery. Code should be beautiful, but not at the expensive of having a successful business and a working product.
      - laconian 15y ago
        But, I don't use the languages those cool kids are using. :) I imagine I would have to formulate a very defensive strategy to deal with breaking changes that would gobble up my productivity gains from using said cool language, just like the people that use Mongo have to DIY the checks that RDBMSes get for free. I use Java and C++, and I don't rush update the second new libraries become available. My team has a large regression suite, too, so it's been less painful (can't say painless) to detect breakage when our dependencies need to be updated.
- phillmv 15y ago
  It's always hard to talk about these differences because 90% of the time we're actually just chest beating and comparing the length of our respective community's e-penises. When people complain about PHP they often mean that in an aesthetic, and in an academic sense, the designers of PHP have, arguably, made a lot of poor choices. What they usually mean is, due to the low barrier of entry coupled with poor aesthetic design choices the PHP community at large seems to have poor engineering standards. These all being Turing machines though don't prevent it from having quality engineering being applied to it, as is the case of Facebook. So, the corollary to "only a poor craftsman blames his tools" is "when you only have a hammer everything starts looking like a nail". I wonder how many people are paid to directly hack on a Ruby implementation vs Python (yay Google) or PHP (yay Facebook).
  - umjames 15y ago
    Isn't that what Matz is doing now at Heroku?
  - jackowayed 15y ago
    I think Engine Yard pays 3 people to be fulltime on the JRuby core team and 2 (not sure on that, certainly one) to be fulltime on Rubinius. Microsoft was supporting IronRuby until a couple years ago.
streptomycin 15y ago
> the performance of a historically technologically poor language like PHP One of the biggest reasons PHP supplanted Perl as the de facto web programming language ~10 years ago was that Perl running through CGI was incredibly slower than PHP.
- rscale 15y ago
  mod_perl also had serious performance and memory leak issues. PHP sucked at the time too, but it sucked in ways that were easier to track down and fix.
- dspillett 15y ago
  Perl had a reputation for being more complex for a beginner too and leading to code that was difficult to maintain.
- dmooney1 15y ago
  I always thought it was because basic PHP was so intuitive for anyone familiar with a C-like language.
  - pbiggar 15y ago
    There's a ton of reasons PHP took off, including off the top of my head - cruftyness of perl - good timing, few alternatives (C and Perl basically) at a key point in the growth of the internet and web developers. - very easy migration from a static only site - easy to deploy, leading to... - wide availability of PHP shared hosting - in depth docs - commenting on docs (cut-and-paste programming ;)) - thousands of builtin functions: first real batteries-included language - recognizable syntax (esp vs Perl) for Java/C programmers - not awful performance - builtin MySQL support from an early stage - oh, it was free (and also Free) - dynamic typing - weak typing (as in, values coerced to other types easily, I know this isn't a real term)
    - nir 15y ago
      > - commenting on docs (cut-and-paste programming ;)) Very true and rarely mentioned. PHP docs never had the fancy wiki/social/javadoc features you see in many languages, just a primitive comments system - and it was perfect. When you were picking it up back when "PHP3" yielded 0 results in Amazon (and we had to change the oil on our desktops every week) the docs were your bible, not merely in the sense of occasionally contradicted themselves but also in having examples, Q&A and recipes for common tasks posted by your peers in the comments, much faster than doc writers could catch up with the language's growth.
deleted 15y ago
[deleted]
- phillmv 15y ago
  Since they're hiring so many Googlers one presumes Python would be a top choice, but if you need an opportunity to whine about Ruby/Rails go for it.
preinheimer 15y ago
They've spoken to this directly. Facebook has tried to migrate to something else (generally with a small team leading the charge) a few times. Let's say that there's 1M lines of PHP code right now handling Facebook's site. In the time it takes the team to re-write those million lines of code, another million have been written. So they can never catch up. Almost like Zeno's paradox, except the turtle moves faster :). All that aside, you can teach PHP to pretty much anyone, and it's rather effective at solving web problems. For quite a while they had some really smart people working on APC to help with performance, they've since switched horses to work on HipHop and the like to get the performance they need.

by nupark2 15y ago

hvs 15y ago

I'm not sure that I'd refer to PHP as a "historically technologically poor language". I'm not even quite sure what that means, exactly, but PHP has proven itself over and over again to be more than capable of working in environments with heavy load and numerous simultaneous users. In fact, in comparison to something like Ruby, it historically destroys it. Now, if you want to get into the details of syntax, naming conventions, etc.. sure, PHP is not everyone's favorite language to work with, but it is far from "technologically poor".

nupark2 15y ago
I'm referring to the quality of the implementation, its performance profile, the soundness of the type system and syntax, and -- like the original post -- measuring relative to the state of the art in JITs, including the JVM.
- j_col 15y ago
  If the JVM is state of the art, how many applications of the scale of Facebook are using it? A serious question, as I don't know of any.
  - nupark2 15y ago
    The JVM is one of the most advanced production-quality JITs available. As for who is using it, everyone from Google to Twitter to Apple, as well a huge number of high-transaction business systems. The JVM is something that tends to get used quietly and widely.
    - j_col 15y ago
      It's also in my experience a massive memory hog, makes deploying your web application a pain (restarts anyone?), and is much more complex to develop for. If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)?
      - nupark2 15y ago
        > It's also in my experience a massive memory hog It's not that Java is memory hog per se, but rather that the total VM memory allocation must be specified at launch, and the VM will not (rarely?) give that memory back to the OS. This is largely an artifact of Sun's generational GC design+implementation, and has some interesting performance wins; namely, object allocation and deallocation are incredibly cheap, because in the fast case, all allocation requires is updating a single pointer. The last time I profiled java object allocation, creating short-live objects turned out to be insanely cheap compared to other allocators/runtimes. > Makes deploying your web application a pain (restarts anyone?) This largely depends on how you structure your web application. > If your Facebook and you're trying to get more bang-for-your-buck from your existing hardware, do you think its a good choice to migrate everything to the JVM (including a full rewrite to Java/JRuby/Scala etc.)? That depends largely on how much they're spending on hardware and JIT/language engineers, versus how much a rewrite would cost, amortized over the reasonable lifetime of their code base. You have to factor in the fact that they've built an entire organization around PHP, and it's not just a technological migration problem; they might also have to retrain or outright replace a large number of existing engineers. I'm inclined to say that it was a mistake to choose PHP, and moreover, to continue to use PHP as they scale. However, funding the implementation of better PHP runtime implementation may be the most fiscally conservative decision left available to them.
maratd 15y ago
Absolutely. PHP just works and it's easy to make it work. That's the most important thing when choosing a platform. Asthetics are always secondary. It's certainly a pain to deal with inconsistent syntax, but fighting your toolchain is a far worse fate and with PHP, that's rarely an issue.
- laconian 15y ago
  For a hack, maybe. Fighting your toolchain is an upfront penalty. Once things start moving smoothly, they tend to continue to work smoothly. And that's a problem that can be solved by further development of the toolchain. Poor aesthetics/readability? You pay that price every second you work on the code.
  - maratd 15y ago
    > Once things start moving smoothly, they tend to continue to work smoothly. This is flat out wrong. If you're on a language all the cool kids are using, you'll find those cool kids have an obsession with perfection. To the point where they deprecate things instantly and break everything that worked before. See NodeJS and Python for examples. If you have 10K lines of code, not so bad. So you do a rewrite every year. When you have 100K lines of code or more, their obsession with perfection will destroy your business. A rewrite becomes an immense undertaking. You end up running old versions. Those old versions require dependencies which require you to run old operating systems. Eventually the entire ecosystem implodes. But guess what? Code that was written in PHP3 over 10 years ago works just as well today under PHP5. You can even mix and match. Does that make the syntax of the language ugly? Sure. It even encourages bad practices. So what? You're running a business, not an art gallery. Code should be beautiful, but not at the expensive of having a successful business and a working product.
    - laconian 15y ago
      But, I don't use the languages those cool kids are using. :) I imagine I would have to formulate a very defensive strategy to deal with breaking changes that would gobble up my productivity gains from using said cool language, just like the people that use Mongo have to DIY the checks that RDBMSes get for free. I use Java and C++, and I don't rush update the second new libraries become available. My team has a large regression suite, too, so it's been less painful (can't say painless) to detect breakage when our dependencies need to be updated.
phillmv 15y ago
It's always hard to talk about these differences because 90% of the time we're actually just chest beating and comparing the length of our respective community's e-penises. When people complain about PHP they often mean that in an aesthetic, and in an academic sense, the designers of PHP have, arguably, made a lot of poor choices. What they usually mean is, due to the low barrier of entry coupled with poor aesthetic design choices the PHP community at large seems to have poor engineering standards. These all being Turing machines though don't prevent it from having quality engineering being applied to it, as is the case of Facebook. So, the corollary to "only a poor craftsman blames his tools" is "when you only have a hammer everything starts looking like a nail". I wonder how many people are paid to directly hack on a Ruby implementation vs Python (yay Google) or PHP (yay Facebook).
- umjames 15y ago
  Isn't that what Matz is doing now at Heroku?
- jackowayed 15y ago
  I think Engine Yard pays 3 people to be fulltime on the JRuby core team and 2 (not sure on that, certainly one) to be fulltime on Rubinius. Microsoft was supporting IronRuby until a couple years ago.

streptomycin 15y ago

> the performance of a historically technologically poor language like PHP One of the biggest reasons PHP supplanted Perl as the de facto web programming language ~10 years ago was that Perl running through CGI was incredibly slower than PHP.

rscale 15y ago
mod_perl also had serious performance and memory leak issues. PHP sucked at the time too, but it sucked in ways that were easier to track down and fix.
dspillett 15y ago
Perl had a reputation for being more complex for a beginner too and leading to code that was difficult to maintain.
dmooney1 15y ago
I always thought it was because basic PHP was so intuitive for anyone familiar with a C-like language.
- pbiggar 15y ago
  There's a ton of reasons PHP took off, including off the top of my head - cruftyness of perl - good timing, few alternatives (C and Perl basically) at a key point in the growth of the internet and web developers. - very easy migration from a static only site - easy to deploy, leading to... - wide availability of PHP shared hosting - in depth docs - commenting on docs (cut-and-paste programming ;)) - thousands of builtin functions: first real batteries-included language - recognizable syntax (esp vs Perl) for Java/C programmers - not awful performance - builtin MySQL support from an early stage - oh, it was free (and also Free) - dynamic typing - weak typing (as in, values coerced to other types easily, I know this isn't a real term)
  - nir 15y ago
    > - commenting on docs (cut-and-paste programming ;)) Very true and rarely mentioned. PHP docs never had the fancy wiki/social/javadoc features you see in many languages, just a primitive comments system - and it was perfect. When you were picking it up back when "PHP3" yielded 0 results in Amazon (and we had to change the oil on our desktops every week) the docs were your bible, not merely in the sense of occasionally contradicted themselves but also in having examples, Q&A and recipes for common tasks posted by your peers in the comments, much faster than doc writers could catch up with the language's growth.

deleted 15y ago

[deleted]

phillmv 15y ago
Since they're hiring so many Googlers one presumes Python would be a top choice, but if you need an opportunity to whine about Ruby/Rails go for it.

preinheimer 15y ago

They've spoken to this directly. Facebook has tried to migrate to something else (generally with a small team leading the charge) a few times. Let's say that there's 1M lines of PHP code right now handling Facebook's site. In the time it takes the team to re-write those million lines of code, another million have been written. So they can never catch up. Almost like Zeno's paradox, except the turtle moves faster :). All that aside, you can teach PHP to pretty much anyone, and it's rather effective at solving web problems. For quite a while they had some really smart people working on APC to help with performance, they've since switched horses to work on HipHop and the like to get the performance they need.