Re: Ruby vs. PHP

On Sun, Oct 07, 2007 at 07:50:50AM +0900, M. Edward (Ed) Borasky wrote:
> Chad Perrin wrote:
> >No, I'm not assuming that.  I'm pointing out that objections to using
> >those micro-benchmarks to choose a language to use for general purpose
> >programming are common, and that I find them agreeable.  Micro-benchmarks
> >are *very* useful for determining problem areas in execution performance,
> >if you happen to be on the core implementation maitenance team, but
> >that's not what I was talking about when I said that as an overall
> >performance measure for purposes of choosing a language they aren't so
> >useful.
> 
> Well ... OK ... you agree with me that they are useful for core 
> implementation. And I *still* think they're useful when comparing 
> performance of languages for general purpose programming, provided the 
> benchmark suite is comprehensive and the statistical comparison 
> methodology is correct.

I still think you're missing my main point -- which is that, in general,
comparing languages within a few points of standard deviation (that is to
say *not necessarily* within standard deviation, but at least close) is
almost fruitless for most purposes.  The reason I think it's pretty much
irrelevant to good decision-making is that other factors will far
outweigh the miniscule performance benefits you might achieve by
examining benchmarks you hope will be representative of your application
design needs -- factors like syntactic construct support for the
architecture you'll implement, general readability, metaprogramming
capabilities, library support, an agreeable inheritance model,
availability in your deployment environment, et cetera.

Would you rather implement a complex object oriented application
architecture in Ruby or Perl, knowing Perl's obtuse OOP syntax and with a
benchmark-suggested 1.1% performance improvement for Perl, all else being
equal?  I'd look at the 1.1% performance improvement and say "So f-ing
what?  It's OOP.  Use Ruby."

On the other hand, if we were comparing Ruby and OCaml, I'd have to
reconsider if performance is a concern, because the performance
improvement would be more like an order of magnitude rather than a
percentage point or two.


> 
> >What I suggested is that "my interpreter is faster than
> >yours" competition based on micro-benchmarks is pointless for languages
> >in the same general neighborhood of execution performance, and that
> >usually other concerns are *far* more important within a given
> >neighborhood of performance than execution speed.  If you want faster
> >execution speed, you should be in a completely different performance
> >neighborhood, not quibbling over whether Ruby or Python is faster for an
> >arbitrary set of micro-benchmarks, in other words.
> 
> Of course. I'm still in the process of crunching the numbers, but what 
> I've seen so far is that MRI Ruby is *not* in the general neighborhood 
> of Perl, Python or PHP, but YARV *is* in that neighborhood. I do need to 
> tighten up the calculations slightly and get rid of some bogus points, 
> but I'm not expecting a major change in that.

I'll have a look at the document you provided in your next email (which
I've only skimmed very briefly so far) to see what you consider a
"neighborhood", then.


> 
> As for things in the "fast lane", I started with gcc, and there are only 
> a few things faster than gcc. The one that jumped out and bit me on the 
> nose was a *functional* language called "clean". I'm just about to 
> download it and see what makes it tick (or to stretch the analogy, how 
> tightly it's wound). And the slow lane has such snails as "groovy" and 
> "rebol" lumbering away.

I've heard incredibly good things about Clean.  I've also witnessed
something like a meltdown on a mailing list because someone reached a
frustration saturation point dealing with the language.  I don't know if
that was more the language's fault, or the fault of the programmer's
background in something like Java.  I'm interested in giving it a look at
some point, but I have other stuff in the queue first.  It's probably way
back there around the level of Erlang and Forth for me -- both of which
are languages about which I've heard great things, but are well outside
the range of my aims right now.


> 
> >Yes, we can -- but the margin for error is so great that, again, petty
> >microsecond disputes between Perl, Python, and Ruby are just that: petty.
> >I say this despite the fact that, overall, Perl kicks the tuckus of both
> >these other close competitors -- and Perl is one of my favorite
> >languages.  I would have said roughly the same thing even before I
> >started using Ruby.
> 
> Well ... let me finish with the numbers, but I think you'll be surprised 
> at how close Perl and Python are to each other and how far away MRI is 
> from the two of them. It's not a "petty microsecond dispute" for MRI.

Okay, fair enough.


> 
> >Who said anything about "significantly faster"?  I'm just talking about
> >the fact that Perl consistently kicking Ruby's tail in performance
> >benchmarks doesn't mean a whole lot when choosing languages for projects,
> >generally speaking, since if performance is enough of a concern to
> >override the other factors involved you should be using something like C,
> >Objective Caml, or at least compiled Lisp instead.
> 
> Of course. But if the choice is between "dynamic languages with a 
> sufficient supply of competent developers available", for example, Perl, 
> Python, PHP and Ruby, and the assumption is that they are equally 
> productive -- you're just trying to assess how much hardware you're 
> going to have to throw at it if your customer growth takes off -- you're 
> going to want the fastest one. Or, more to the point, you're probably 
> going to dismiss the slowest one and move on to the other decision factors.

They're *not* equally productive in many cases, however.  For OOP, I'd
choose Ruby or Python over PHP or Perl any day of the week, because OOP
in Perl is painful, and in PHP is downright suicidal.  I'd also choose
Ruby over Python just as quickly, because I find Python just generally
painful -- but that's more personal taste than anything else, and
wouldn't necessarily dictate my suggestion for someone else that likes
Python.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Rudy Giuliani: "You have free speech so I can be heard."