RE: Over 4-way systems considered harmful :-)

[M. Edward Borasky]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Martin J. Bligh
> Sent: Tuesday, December 04, 2001 9:41 AM
> To: M. Edward Borasky; [e-mail]
> Subject: Re: Over 4-way systems considered harmful :-)
>
> Two things.
>
> 1) If a company (say, IBM) pays people to work on 8 / 16 way scalability
> because that's what they want out of Linux, then stopping development
> on that isn't going to get effort redirected to fixing your
> soundcard (yes,
> I realise you were being flippant, but the point's the same), the
> headcount
> is just going to disappear. AKA your choice isn't "patches for 8 way
> scalablilty, or patches for subsystem X that you're more interested in",
> your choice is "patches for 8-way scalabity, or no patches". Provided that
> those patches don't break anything else, you still win overall by
> getting them.

I don't see how this is a win for me. And it is a win for IBM only if it
gives them some advantage in serving their customers. I can certainly
*conceive* of workloads bursty enough to justify an 8-processor server, but
do they exist in the real world? And if they do, is a single 8-processor
server better than a pair of 4-processor servers when you take graceful
handling of faults into account? IBM has been building high-availability
systems for *decades*, preferring to field *slightly* slower but
*significantly* more reliable gear, which, legend has it, no one has ever
been fired for purchasing. :-)

> 2) Working on scalability for 8 / 16 way machines will show up races,
> performance problems et al that exist on 2 / 4 way machines but don't
> show up as often, or as obviously. I have a 16 way box that shows up
> races in the Linux kernel that might take you years to find on a 2 way.

Perhaps effort should be placed into software development processes and
tools that deny race conditions the right to be born, rather than depending
on testing on a 16-processor system to find them expeditiously :-). And
there is a whole discipline of software performance engineering to build
performance in from the start. Advances like that would be a *huge* win for
the Linux community, given our (relative) freedom from corporate-world
limitations like deadlines, sales quotas, programmer salaries, and
full-color brochures.

> What I'm trying to say is that you still win. Not as much as maybe you'd
> like, but, hey, it's work you're getting for free, so don't complain too
> much about it. The maintainers are very good at beating the message
> into us that we can't make small systems any worse performing whilst
> making the big systems better.

No, but we can release partly-baked VM schemes that have a shelf life on the
order of days :-). Seriously, though, I don't like stepping on someone
else's dream, especially since *my* dream -- a GFLOP dedicated to computer
music -- has been fulfilled for about $1500 US. When I bought that machine,
I thought I was going to need two processors -- one to run the OS and
service the keyboard, mouse and monitor and a second dedicated to generating
audio samples in real time. I had no idea how powerful these chips were
until I started shopping around. And when I loaded the Atlas linear algebra
library up on my Athlon and saw the speeds it was getting, I was in shock
for almost a week!

However, as I said in another post: "Moore's Law: good. Amdahl's Law: bad."
I guess the new generation has to discover Amdahl's Law for itself, and
*this* distinguished but elderly scientist is eager to be proven wrong :-).
--
Take Your Trading to the Next Level!
M. Edward Borasky, Meta-Trading Coach

[e-mail]
http://www.meta-trading-coach.com
http://groups.yahoo.com/group/meta-trading-coach