Sun fires UltraSparc V people, AMD & Fujitsu to blame?

  • Thread starter Thread starter Black Jack
  • Start date Start date
B

Black Jack

This article talks about Sun firing some portion of its employees
working on the upcoming UltraSparc V program. They talk about all
kinds of things in this article, but they don't mention the two things
which I think are really the reason -- Sun's new partnerships with AMD
(Opteron) and Fujitsu (Sparc64).

http://news.com.com/2100-1006_3-5189458.html?tag=nefd.top

The US5 would've required new interfaces and motherboards and would've
been incompatible with existing US3 & US4 servers. They also talk
about a bunch of other Sparc'ish stuff like Gemini, Niagara, and Rock;
some of them are also canned, some are continuing. Anyways it looks as
if UltraSparc isn't entirely safe at Sun, neither from the low-end
with Opteron, nor from the high-end from the alternative Sparc64.

Yousuf Khan
 
This article talks about Sun firing some portion of its employees
working on the upcoming UltraSparc V program. They talk about all
kinds of things in this article, but they don't mention the two things
which I think are really the reason -- Sun's new partnerships with AMD
(Opteron) and Fujitsu (Sparc64).
Click to expand...

Shouldnt this article be subtitled:

Sun shoots from the hip and blows both feet off?

This is surely the finely death-knell for a company that was once
respectable.
At one point, Sparcs and SunOS/Solaris were the opensource developers
maternity clinic.

But what they did on X86 was criminal - they stuck two fingers up to
the development community. Eventually they retracted but by then x86
cpus were sooo much better than Sparcs. (The only thing I like about
Sparcs nowadays is the fact that they dont supported unaligned memory
access - great for debugging portable C code).

Solaris itself has some good features compared to the competition (and
I'm talking desktop models, not enterprise), but they blew it.

Maybe with their Linux offerings they will gain respectability.

I never expected to see DELL a respectable company, or IBM. But they
both managed to dig themselves out of the gutter of peer-respect.
Maybe Sun can do the same.

Intel pulled off a coup when they asked every company to commit
commercial suicide and be the same as every other c.o.m.p.a.n.y.

Good on Fujitsu who have also come from a point of obscurity (again in
the desktop arena) and outlive the company that gave them a living.
 
This article talks about Sun firing some portion of its employees
working on the upcoming UltraSparc V program. They talk about all
kinds of things in this article, but they don't mention the two things
which I think are really the reason -- Sun's new partnerships with AMD
(Opteron) and Fujitsu (Sparc64).
Click to expand...

The "blame" for this rests squarely in the hands of one company: Sun.

First off, the UltraSparc V project started 7 years ago and was still
a year or two away from being complete. That is as bad as the
original Itanium, and it would have yielded much less performance in
the end. US V wasn't going to be a class-leading processor by any
stretch, and while they had actually taped out the chips, they still
had a lot of work to do.
http://news.com.com/2100-1006_3-5189458.html?tag=nefd.top

The US5 would've required new interfaces and motherboards and would've
been incompatible with existing US3 & US4 servers. They also talk
about a bunch of other Sparc'ish stuff like Gemini, Niagara, and Rock;
some of them are also canned, some are continuing. Anyways it looks as
if UltraSparc isn't entirely safe at Sun, neither from the low-end
with Opteron, nor from the high-end from the alternative Sparc64.
Click to expand...

Well, there are a few things to think of first here.

1. Sun has (err, had) the second largest CPU development team in the
world (presumably behind Intel). They were spending a LOT of money
developing new processors.

2. Sun hasn't been at all competitive on single-threaded performance
with their chips for at least 10 years.

3. The UltraSparc V was in development for about 7 years now and while
it had taped out it was still a good 2 years away being ready.

4. Once the US V was done it STILL wasn't going to be competitive in
terms of single-threaded performance.


You also have to look at Sun's markets. Right now Sun competes in two
main markets, the 64-bit workstation market and servers. Workstations
need high single-threaded performance, and Sun kind of stinks here
(and would continue to stink with the US V). The only reason why this
market exists is because x86 had no 64-bit support and couldn't handle
large memory. Ever since the Opteron was released last year, Sun's
entire reason d'etre in the workstation market has disappeared.
High-end workstation software is QUICKLY moving towards x86-64 and
they will be dumping support for Sparc/Solaris ASAP. This was going
to happen regardless of whether the US V made it to market or not.

For the network server market, high single-threaded performance really
doesn't matter much, since it's all about multithreaded performance,
ie exactly what Niagara is designed for. This is a market that Sun
does very well in now and Niagara should fit into this market VERY
well. The US V was not really going to help much here.


So, in the end the UltraSparc V was a very expensive and complicated
processor that would offer fairly poor performance. It's main market,
64-bit workstations, is dead for Sparc. Niagara was a much better
solution for the network server processors and it's a much simpler
(cheaper) design. In fact, it's likely that it wouldn't really have
been all that worthwhile to develop all new hardware and support
infrastructure for the US V when it would have ended up being a more
expensive but slower platform for network servers.


Long story short, the only dumb thing about this is that it took Sun
so long to cancel the project. Really the US V should have been
canned about 2 or 3 years ago when AMD announced x86-64. However I
guess Sun didn't know for sure if the Opteron would take off like it
did and whether or not Intel would follow along or continue to push
IA-64. Now that both of those things have come to happen, the US V
was never going to sell anything and it was still costing a LOT of
money.

Now, if Sun (no guarantees there) is smart they will do a few things
going forward:

1. Quickly de-emphasize Sparc/Solaris for workstations in favor of
Opteron x86-64/Solaris and/or x86-64/Linux. This is going to happen
whether Sun wants it or not, but if they push the Opteron here they
can ride the wave and actually make some money out of all this.

2. Move all their network servers to the US IV and Niagara (that's
already their plan).

3. Buy some Fujitsu SPARC64-V processors for future workstations to
support those legacy Sparc/Solaris workstation users who have software
that can not easily be upgraded. This gives Sun faster chips for MUCH
less money than developing their own.
 
Tony Hill said:
4. Once the US V was done it STILL wasn't going to be competitive in
terms of single-threaded performance.
Click to expand...

What's your source for this claim? Has Sun ever published any
performance estimates for the US-V?

I know it was supposed to be some kind of MT (SMT?), but presumably
they would have optimized for single thread performance too.

Also they have the option to switch to the Fujitsu SPARC64V for their
workstation line. While that CPU is also a bit behind compared to the
leaders of the pack (highest SpecInt published: 905, while Opteron is
at 1429 right now, but the 1.7Ghz POWER4+ also has only 1158) it could
be most likely tuned up a bit with more cache and more frequency to be
halfway competive. Disadvantage for Sun is that they will need to
design new chipsets for the different bus. I presume they figured out
that the SPARC64V is not that much worse than the US-V, but a lot
cheaper for them.

-Andi
 
What's your source for this claim? Has Sun ever published any
performance estimates for the US-V?
Click to expand...

They gave a nice fuzzy estimate of "5 times the performance of a
1.2GHz UltraSparc III". Of course that is 100% PR, so we can probably
figure that it was going to be more like 2-3 times as fast as the US
III, or maybe a bit faster than the best of what's available today.
Of course, the chip was still 2 years away from shipping, so by the
time it got here it just wasn't going to be competitive.

If you remember back to when the UltraSparc III was in discussion Sun
made all kinds of claims about it having great performance too, but
when it arrived (late) the performance was quite lackluster.
I know it was supposed to be some kind of MT (SMT?), but presumably
they would have optimized for single thread performance too.
Click to expand...

It was supposed to have two operating modes, one optimized for single
threaded performance and one optimized for multithreaded operation.
Also they have the option to switch to the Fujitsu SPARC64V for their
workstation line. While that CPU is also a bit behind compared to the
leaders of the pack (highest SpecInt published: 905, while Opteron is
at 1429 right now, but the 1.7Ghz POWER4+ also has only 1158) it could
be most likely tuned up a bit with more cache and more frequency to be
halfway competive. Disadvantage for Sun is that they will need to
design new chipsets for the different bus. I presume they figured out
that the SPARC64V is not that much worse than the US-V, but a lot
cheaper for them.
Click to expand...

Yup, Fujitsu is continuing their SPARC64 line and they should make
reasonable workstation processors for Sun to support the legacy
Sparc/Solaris workstation apps. However that is a rapidly dying
market anyway.
 
Tony Hill said:
Ever since the Opteron was released last year, Sun's
entire reason d'etre in the workstation market has disappeared.
Click to expand...

That's "raison d'être", which I keep in my hard_words.txt, along with
some other words that always give me (and spell guessers) trouble -
scenario, exacerbate, thoroughly, and coup d'état.

HTH 8)
 
GoogleFox said:
The only thing I like about Sparcs nowadays is the fact that they
dont supported unaligned memory access - great for debugging
portable C code.
Click to expand...

Even IA-32 supports alignment checks.

Alignment check (bit 18).

Set this flag and the AM flag in control register CR0
to enable alignment checking of memory references;
clear the AC flag and/or the AM flag to disable
alignment checking. An alignment-check exception is
generated when reference is made to an unaligned
operand, such as a word at an odd byte address or a
doubleword at an address which is not an integral
multiple of four. Alignment-check exceptions are
generated only in user mode (privilege level 3).
Memory references that default to privilege level 0,
such as segment descriptor loads, do not generate
this exception even when caused by instructions
executed in user-mode.

The alignment-check exception can be used to check
alignment of data. This is useful when exchanging data
with processors which require all data to be aligned.
The alignment-check exception can also be used by
interpreters to flag some pointers as special by
misaligning the pointer. This eliminates overhead of
checking each pointer and only handles the special
pointer when used.
 
Nudge said:
Even IA-32 supports alignment checks.

Alignment check (bit 18).
Click to expand...

That's hard to use for two reasons:

1) The IA-32 calling conventions require data layout (e.g., DP FP on
4-byte boundaries) that will cause alignment check exceptions. Let's
hope that they fixed this in the AMD64 calling conventions.

2) Some functions (e.g., I have seen it for memmove) actually make
intentional use of unaligned accesses. This can be worked around by
linking with versions of these instructions that don't do unaligned
accesses.

Followups to comp.arch.

- anton
 
That's "raison d'être", which I keep in my hard_words.txt, along with
some other words that always give me (and spell guessers) trouble -
scenario, exacerbate, thoroughly, and coup d'état.
Click to expand...

That's just my bad "Franglais" as they call it around here, ie mixing
French and English in a single sentence! The end meaning is the same
("raison" is simply French for "reason"). I haven't got a French
keyboard though and can't be bothered with the ASCII alt-codes to get
the accent!
 
That's just my bad "Franglais" as they call it around here, ie mixing
French and English in a single sentence! The end meaning is the same
("raison" is simply French for "reason"). I haven't got a French
keyboard though and can't be bothered with the ASCII alt-codes to get
the accent!
Click to expand...

My favorite is "wallah" - I think they hear it on TV and figure: "oh, I
guess it must be spelt like I think I hear it".:-)

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
 
Nudge said:
Even IA-32 supports alignment checks.

Alignment check (bit 18).

Set this flag and the AM flag in control register CR0
to enable alignment checking of memory references;
clear the AC flag and/or the AM flag to disable
alignment checking. An alignment-check exception is
generated when reference is made to an unaligned
operand,
Click to expand...

Thats interesting. What CPU introduced that? (Ages since I felt the
need to bone up on the Pentia internals).

Wont particularly help me tho - nice as it is. When I run my app on
Sparc
or Alpha, it dies when I didnt follow the rules and I get to know.
With this, I would have to elect to turn the test on and even then the
rules may be suspect (because my app knows on an x86 not to worry
about this).

Could be interesting tho to see if valgrind has been modded to support
this facility.
 
GoogleFox said:
Thats interesting. What CPU introduced that? (Ages since I felt the
need to bone up on the Pentia internals).
Click to expand...

486!

In fact, checking for the ability to set the AC flag bit is/was the
official way to determine that you have a 486 instead of a 386.

From P5 on, CPUID finally gave an official opcode to do all of this.

Terje
 
Back
Top