From: MenTaLguY <mental@...>
Date: 2007-10-04T06:09:02+09:00
Subject: Re: Recent Criticism about Ruby (Scalability, etc.)

On Thu, 4 Oct 2007 04:40:52 +0900, Chad Perrin <perrin@apotheon.com> wrote:
> Maybe not "entirely", but certainly close enough for government (or
> corporate) work.  I was under the impression we were talking about
> massive-traffic server-based systems here, where throwing more hardware
> at the problem (in the sense of extra blades, or whatever) is an option.
> I did not think we were talking about something like a desktop app where
> opportunities for parallelism are strictly limited -- in which case I'd
> agree that throwing more hardware at the problem is a non-starter.  Of
> course, I don't know anyone who thinks endlessly adding processors to
> your desktop system is the correct answer to a slow word processor.

I wasn't thinking of only desktop systems, but I think you're right:
many massive-traffic server-based systems _can_ be embarrassingly
parallel, since jobs are often relatively independent (e.g. individual
user sessions/HTTP requests), and in that context adding more work
usually translates into simply adding more jobs.  It's going to depend
a lot on the nature of the problem domain, though:  once the jobs
become sufficiently interdependent, you do start to hit a scalability
wall (often a problem in e.g. simulations or online games).

Anyway, I think I was wrong: Amdahl's law may not be appropriate
here -- we aren't just talking about making a fixed-size job go
faster, but what happens when more work is added.  Unless you're doing
something like n-body simulations, the relative amount of
unparallelizable work can decrease as the absolute amount of work
increases, because the shared stuff that forces serialization can often
be partitioned, allowing more overall parallelism than was practical
with a smaller workload.

> 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.

> 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.

-mental