Re: Why is SUN falling so far behind IBM?

From: Arthur Corliss (acorliss_at_bifrost.nevaeh-linux.org)
Date: 08/16/04 

Date: Mon, 16 Aug 2004 21:24:12 -0000

On 2004-08-08, Benjamin Gawert <bgawert@gmx.de> wrote:
>
> Right. But the current compilers from intel are quite good at
> optimization...

I would hope so, it's their chip. But I can't help but think that there's
going to be a lot of real-world apps whose logic won't fit well in the
templates, wasting a good chunk of Itanium's theoretical throughput. I have
a bit more faith in branch prediction logic in eeking a bit more out of
unexpected tasks than a predefined template system.

> Maybe. But at least our software angineers have no problem with wasted
> bandwith on Itanium. And from what I know most other ISV don't have that
> problem, too.

Have they even done statistcal modeling to see what they should be getting
compared to what they are getting? Most engineers seem to be just ducky
out-performing the last code base, without really understanding just what
they should be getting out of the hardware.

> Right. So what? Of course when comparing performance/clock cycle MIPS still
> is good. But MHz as a performance criteria is more something for the PC
> Kiddies. The CPU clock is quite irrelevant. Who cares when MIPS does more
> instructions per clock cycle when the architecture limits the achievable max
> performance way below what other modern processors do. Of course the
> performance/clock ratio is better than on the R14k-600 than on the POWER4
> 1.7, but in the end the POWER4 offers much more overall performance than the
> R14k...

It matters a great deal when you consider that for all the nice benchmarks
these processors get they still spend a considerable chunk of thier time
idle due to data starvation. This is the key difference between SGI and
and other vendors: they spend a hell of a lot of time ignoring external
bottlenecks while SGI works on resolving those instead.

I would put forth that it's reasons like this why customers like
Wright-Patterson AFB still put out the bucks for Origins. The pipeline to
the processor is kept a hell of a lot fuller in them.

> Yes, historically. For sure it's efficient (that's btw the reason why MIPS
> is so widespread in the embedded market), but it's not fast. The
> architecture simply can't keep up with other CPUs when it comes to absolute
> performance. And we don't buy a platform because it is so good at doing lots
> of instructions per clock cycle (that's more interesting for discussions in
> comp.sys.arch), we buy it because of its absolute application performance.
> And that's where MIPS simply is behind all competition...

Yes and no. I agree that MIPS hasn't pursued the "easy" optimisations like
they could have (when SGI had direct control), but by the same token, as I
mentioned above, they did compensate by trying to ensure nothing external
to the processor was going to slow things down as well. That may have not
compensated fully for the lack of clock rate, but it does make a huge
difference.

And at the same time I will put forth my assertion that if MIPS had been
pushed like the other RISC architectures that it could be a superior
computing architecture, even today. The processors would use a fraction
of the die size and power for equivalent performance.

Don't get me wrong: my shop is primarily an IBM shop (p & iSeries), so I
like IBM's hardware. But let's face it: the Power-n processor is to
hardware what modern applications (dare I say it? C++ code ;-) are to
software -- extremely fat and bloated. The only saving grace is that
processors, for all their bloat, do appear to gain us some performance
improvements, while the latest software merely serves to make those new
processors feel as snappy as our old Z80s.

> Yes, because SGI sold most of it's assets like Cray, Softimage, and also
> including parts of their round hq building in San Jose), and their
> increasing success with their Linux-based ALTIX systems. MIPS/IRIX is
> something that costs SGI more than what it brings as renevue. The few
> MIPS/IRIX sales are almost all just upgrade sales to the remaining existing
> MIPS/IRIX customers. During the last years SGI wasn't able to aquire new
> customers with MIPS/IRIX, instead of this they lost a big bunch of
> traditional customers to other system vendors which offered a better
> performance...

Cray is much better off without SGI's mishandling (completely two different
philosophies of scaled computing), but selling off non-core business units
is hardly the only way SGI has stayed in business (though it has helped).

To refute your assertions that Altix/Linux is the only thing bringing in
new revenue I would point out only one of their publically listed "customer
successes" in servers mentions the Altix, each of the others mention the
Origin. And look at successes under visualization systems, that, too, is
dominated by Onyxs and Origins. If the Altix was that vital to their revenue
stream I'd think they'd do a hell of a lot more press releases on it,
wouldn't you?

> MIPS/IRIX is certainly not the _reason_ they are still in business. It's
> more a fact that _despite_ MIPS/IRIX SGI is still in business...

I wholeheartedly disagree. See above.

> Yes, but on the other side the Itanium CPUs are much faster than the fastest
> MIPS offerings, so for having the same performance You need less CPUs than
> on MIPS...

Did you not read my post? I think I was pretty clear in saying that in the
real world clock rate means nothing if you're just sitting, waiting for data
to work on. Which is why the Origin is so effective, even at the slower
rates.

> Internal is definite that IRIX/MIPS is going to die. And You see SGI putting
> most of their ressources in Linux/ALTIX, while the MIPS series is somewhat
> stagnating for some years now. IRIX of course gets its maintenance and
> improvements, but it's very unlikely that we'll ever see a new IRIX
> version...

<G> Compare the original 6.5 to 6.5.13, and that to 6.5.23. The versions
lie, my friend, there's been major enhancements within the 6.5 stream. SGI
just doesn't feel the need to pull a Sun-like move to pretend to advance the
platform. How big a jump was 2.7 to Solaris 8? I don't believe for a minute
that they've improved Solaris from 2.7 to 9 as must as IRIX has improved
within the 6.5 series.

> Well, at least DEC had technology that was performing very good. That's not
> the case for SGI MIPS...

I disagree. The Alpha is a great chip, but I wouldn't rate MIPS too far
behind. I'd take a MIPS box over a Sparc box anyday, that's for sure. And
there's a good reason why my Octane sees more use than the Athlon-based box
next to it, even though the Athlon is several multiples faster than my R12k... 

-- 
	--Arthur Corliss
	  Bolverk's Lair -- http://arthur.corlissfamily.org/
	  Digital Mages -- http://www.digitalmages.com/
	  "Live Free or Die, the Only Way to Live" -- NH State Motto

Relevant Pages

  • Re: Why is SUN falling so far behind IBM?
    ... Of course when comparing performance/clock cycle MIPS still ... The CPU clock is quite irrelevant. ... Yes, because SGI sold most of it's assets like Cray, Softimage, and also ... MIPS/IRIX sales are almost all just upgrade sales to the remaining existing ...
    (comp.unix.aix)
  • Re: Solaris to Itanium...
    ... > Fujutsu is developping what will be the replacement for the cancelled sparc-5. ... SGI purchased MIPS, and SGI's stated future direction is with Itanium. ...
    (comp.os.vms)
  • Re: Another one bites the dust
    ... > Can I have a 2048-CPU Itanium machine then? ... > No problem with MIPS. ... Ask SGI, they'll do you won if you have the dosh. ... > For scalability, SGI MIPS/IRIX is way ahead of everyone, by an order ...
    (comp.sys.sgi.misc)
  • Re: Why is SUN falling so far behind IBM?
    ... > something that costs SGI more than what it brings as renevue. ... > MIPS/IRIX sales are almost all just upgrade sales to the remaining existing ... > MIPS/IRIX customers. ... > most of their ressources in Linux/ALTIX, while the MIPS series is somewhat ...
    (comp.unix.aix)
  • Re: [OT] The Ramifications of Little-Endian Packed Decimal
    ... >> changing the bit while executing code whose interpretation is affected by ... I think MIPS R2000 was the first microprocessor to do this; ... would be customers. ... The feature was certainly worthwhile for MIPS, ...
    (sci.crypt)