[rescue] SMP on intel wasteful?

[Dave McGuire]

  If you knew half of what you were talking about, you might be
dangerous.  I will *not* be hiring you anytime soon.  If that doesn't
bother you, then we'll both be happy.  I've tried to teach you a
little bit about how this stuff works here, tried to help you out, but
it's clear you're either incapable of learning or you're just not
ready.  Oh, and yes...I'm arrogantly condescending to you...because
you're an idiot.

  Oh, and Bill...I left the excessive quoted material here for
reference...I feel it was relevant in this case.

  Have a flowery, sing-songy, fuck-me-up-the-ass-and-call-me-Peanut day.

       -Dave

On June 24, Chris Hedemark wrote:
> On Mon, 2002-06-24 at 14:01, Dave McGuire wrote:
> 
> >   I'm not here to give you an education in computer architecture, 
> 
> And now you're condescending to me?  How arrogant.  I'm not some PFY.
> 
> > I've referred you to various
> > repositories of information.  
> 
> You've referred me to nothing.  You've made nebulous statements.  OK in
> a later post (later than the one that I was replying to before) you made
> some meek effort to point to someone else's book on parallel computing
> theory when it had no relevance to the discussion at hand.
> 
> > Learning it is YOUR responsibility, I
> > don't want to spoon-feed it to you.
> 
> We're not talking about learning here.  We're talking about real world
> applications of technology to solve problems.  Or at least I am anyway.
> 
> >   But I'll throw you a bone, since I'm such a nice guy...first, take a
> > look at IDE/ATA disks.  Don't make the argument that "but I can put
> > SCSI on a PeeCee!" because then your "but it's cheaper!" argument gets
> > blown even further out of the water than it already is.  
> 
> My example $2000 machine used SCSI disks.  We can move past the IDE vs.
> SCSI argument because it is not one that I am making.
> 
> > Then look at
> > ROM monitor ("BIOS" for you PeeCee guys) support.  Four partitions?
> > No diag capabilities?  No analog of "environment variable" support to
> > pass defaults to the booting OS?  Come ON, the VAX had that in 1978.
> 
> And how is this relevant to the examples that I gave of solving real
> world problems with the application of technology?
> 
> > Then take a look at segmented addressing, then tiny caches. 
> 
> Tiny caches are rendered irrelevant by brute force CPU horsepower. 
> Sure, my Sun box has a 2MB cache.  But my 800MHz duron kicks the crap
> out of it with any real world test that you throw at it.
> 
> > If you're
> > still hungry for more, 
> 
> I'm hungry for anything relevant.  And I haven't gotten a crumb yet.
> 
> > take a look at the number of available
> > registers.  
> 
> Again, how is this relevant to the argument that a $2,000 PC routinely
> kicks the crap out of RISC machines many times that price in the real
> world application of technology?
> 
> I'm not counting registers.  I'm not counting cache.  I'm counting how
> productive an end user can be given the equipment that you provide for
> them.  It matters very little if a programmer has a more difficult time
> economizing the use of registers.
> 
> > How well does that mesh with modern compiler technology?
> 
> Out of all of the users in the world, very few give a wet fart about how
> many registers the host processor has.  Any argument you have is within
> a very tiny niche of users (nay, programmers) who would ever know the
> difference.
> 
> Most people care about how long it takes for a job to finish after
> hitting the Enter key.  Time is money.  How long are you going to take
> to take my input, apply a process, and provide me with output?  That's
> really computing in a nutshell.
> 
> > And if you're STILL not convinced, go try to actually *program* an
> > x86-architecture processor.  
> 
> Working with Assembler there are indeed some real world shortcomings.
> 
> Not many of us care to program in Assembler anymore.
> 
> With the overabundance of available horsepower, increasingly sysadmins
> like me are turning to perl.
> 
> Which, while nowhere near as fast in execution as well written C or
> assembler, still soundly trounces RISC hardware dollar for dollar when
> running on PC hardware.
> 
> > When you're ready to commit suicide, drop
> > me an email and I'll hook you up with a decent price on a real
> > computer.
> 
> Oh I love playing with my non-x86 hardware.  It's pretty interesting
> stuff.  But it's just that, playing.  Sure, maybe I'll use sparc boxen
> for DNS or DHCP servers, or larger RISC hardware for giant databases
> that would benefit from 16+ processors and 64 bit pointers, but those
> are increasingly niche applications.  More and more every day, for the
> applications that real users run (the ones that pay the wages for us
> geeks), RISC hardware is falling by the wayside.
> 
> The real moment of clarity was when our Sun guy came in talking about
> the EDA simulation farm we were going to build, and he (nor his
> engineer) had any answers as to why our $2,000 PeeCees were kicking the
> crap out of his $100,000 Suns.  The support from Sun had been great, and
> more of the EDA software at the time ran on Sun than on Linux (a
> disparity which has changed much in the last 2 years in favor of Linux)
> and they had no explanation.  They didn't even try to compete for that
> project, because $200,000 spent on Sun hardware couldn't even get in the
> same building let alone the same level of productivity as $200,000 of
> PeeCee hardware.
> 
> >   Processor architecture isn't a business decision.  
> 
> Thanks for helping to make my point.
> 
> > The notion that
> > real computers are more expensive than PeeCees simply wrong.  For THAT
> > "substance" go check some price lists.  And no, "mega hurts" isn't the
> > way to match up systems for which to compare prices.
> 
> Of course not.  I learned long ago that a 400MHz Pentium II machine
> could often run the same jobs more quickly than a 400MHz UltraSPARC box.
> 
> Again, the real test boils down to how long is it going to take for a
> system to take my input, apply a process, and provide me with useful
> output.
> 
> >   And again, it's not a CISC vs. RISC thing any longer...it hasn't
> > been for years.
> 
> Let me ask you again (since you're finally starting to say a little more
> than stuff like "x86 is repulsive):  For real world work, what can you
> show me in the RISC world that compares to my $2,000 x86 box in terms of
> productivity?
> 
> I've checked Sun's price list and really they don't have a single
> processor available that is in the same class as the lower end PeeCee
> stuff being made today.   They just aren't able to keep up.  Sun cannot
> compete until you start getting into massively multiprocessor systems.
> 
> Granted, Alphas are spiffy processors but Alpha is the unloved stepchild
> of HP and Compaq, an unwanted remnant of Compaq's past lover DEC (may he
> rest in peace).  The alpha architecture is kind of like IBM's OS/2. 
> It's dead, but they'll never really come out and say it.  HP also seems
> to be poised to ditch their own PARISC in favor of (gasp) an Intel
> architecture.  I used to work at IBM and had access to some really sexy
> RS/6000 hardware.  But again, dollar for dollar the PeeCee hardware is
> now at a point where it is running circles around all of these
> architectures.
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue
> 

-- 
Dave McGuire                  "Needing a calculator indicates that
St. Petersburg, FL              your .emacs file is incomplete." -Joshua Boyd