From: Chad Perrin <perrin@...>
Date: 2007-10-04T06:19:19+09:00
Subject: Re: Recent Criticism about Ruby (Scalability, etc.)

On Thu, Oct 04, 2007 at 06:09:02AM +0900, MenTaLguY wrote:
> On Thu, 4 Oct 2007 04:40:52 +0900, Chad Perrin <perrin@apotheon.com> wrote:
> 
> > It's close enough (again), for many purposes, to "realistic".  When you
> > can get roughly linear scaling up to 100 times as much scaling needs, as
> > opposed to trying to get similar scaling capabilities out of throwing
> > programmers (or programmer time) at the problem, that's certainly
> > "realistic" in my estimation.
> 
> I'd submit that while you're still able to get a two-orders-magnitude
> increase in performance from simply improving your algorithms, you're
> probably not to the point where you could scale linearly.  On the other
> hand, by the time you're scaling linearly, there's probably not much
> else to squeeze out of the thing, aside from micro-optimizations which
> may get you some fractions of an order of magnitude improvement.

Algorithms are important to performance, of course, and there's a minimal
amount of attention you should always want to employ in writing quality
code.  My point is that ultimately, as things continue to scale upward,
you tend to pass a point where algorithm tweaking helps sufficiently any
longer to bother with it very much at about the same time you notice that
no matter what else you do you're going to have to add more hardware
resources.


> 
> > Obviously I'm not saying that you should write crap code and throw
> > hardware at it.  On the other hand, there's a sweet spot for effort spent
> > in developing good, performant code -- and beyond that point, you should
> > consider throwing hardware at the problem.  In such circumstances, one of
> > the primary measures of quality code is "Does it scale in a roughly
> > linear manner when you add compute resources?"
> 
> Yes, agreed.

It seems that on one hand I've been advocating writing code so you can
scale upward in hardware resources, and that throwing hardware at the
problem is eventually the only likely option you have left, while on the
other hand you're advocating for people writing good code in the first
place because crap code of sufficiently bad quality won't scale very well
no matter how much hardware you throw at it.  In other words, I was
assuming reasonably good code as a baseline, and you were assuming
reasonably bad code as a baseline.  These incompatible assumptions may be
influenced by our respective work environments.

I'll expand on my position, then:

  1. Hire good programmers.

  2. Have them write good code.

  3. Throw hardware at the scaling problem, because your good code
  written by good programmers can handle it.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Larry Wall: "A script is what you give the actors.  A program is what you
give the audience."