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

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

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
11 answers Last reply
More about fires ultrasparc people fujitsu blame
  1. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    news.yaya.bbbl67@spamgourmet.com (Black Jack) wrote in message news:<d8bc87ef.0404102132.893e53e@posting.google.com>...
    > 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).
    >

    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.
  2. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    On 10 Apr 2004 22:32:08 -0700, news.yaya.bbbl67@spamgourmet.com (Black
    Jack) wrote:
    >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).

    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.

    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
    hilla <underscore> 20 <at> yahoo <dot> ca
  3. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    Tony Hill <hilla_nospam_20@yahoo.ca> writes:
    >
    > 4. Once the US V was done it STILL wasn't going to be competitive in
    > terms of single-threaded performance.

    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
  4. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    On Sun, 11 Apr 2004 23:40:04 +0200, Andi Kleen
    <freitag@alancoxonachip.com> wrote:
    >Tony Hill <hilla_nospam_20@yahoo.ca> writes:
    >>
    >> 4. Once the US V was done it STILL wasn't going to be competitive in
    >> terms of single-threaded performance.
    >
    >What's your source for this claim? Has Sun ever published any
    >performance estimates for the US-V?

    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.

    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.

    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
    hilla <underscore> 20 <at> yahoo <dot> ca
  5. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    Tony Hill <hilla_nospam_20@yahoo.ca> wrote:

    >Ever since the Opteron was released last year, Sun's
    >entire reason d'etre in the workstation market has disappeared.

    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)
  6. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    GoogleFox wrote:

    > The only thing I like about Sparcs nowadays is the fact that they
    > dont supported unaligned memory access - great for debugging
    > portable C code.

    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.
  7. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    Nudge <devnull@kma.eu.org> writes:
    >> The only thing I like about Sparcs nowadays is the fact that they
    >> dont supported unaligned memory access - great for debugging
    >> portable C code.
    >
    >Even IA-32 supports alignment checks.
    >
    > Alignment check (bit 18).

    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
    --
    M. Anton Ertl Some things have to be seen to be believed
    anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
    http://www.complang.tuwien.ac.at/anton/home.html
  8. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    On Mon, 12 Apr 2004 08:23:13 -0500, chrisv <chrisv@nospam.invalid>
    wrote:
    >Tony Hill <hilla_nospam_20@yahoo.ca> wrote:
    >
    >>Ever since the Opteron was released last year, Sun's
    >>entire reason d'etre in the workstation market has disappeared.
    >
    >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.

    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!

    -------------
    Tony Hill
    hilla <underscore> 20 <at> yahoo <dot> ca
  9. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    On Mon, 12 Apr 2004 23:41:06 -0400, Tony Hill <hilla_nospam_20@yahoo.ca>
    wrote:

    >On Mon, 12 Apr 2004 08:23:13 -0500, chrisv <chrisv@nospam.invalid>
    >wrote:
    >>Tony Hill <hilla_nospam_20@yahoo.ca> wrote:
    >>
    >>>Ever since the Opteron was released last year, Sun's
    >>>entire reason d'etre in the workstation market has disappeared.
    >>
    >>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.
    >
    >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!

    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??
  10. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    Nudge <devnull@kma.eu.org> wrote in message news:
    > 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,

    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.
  11. Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips (More info?)

    GoogleFox wrote:

    > Nudge <devnull@kma.eu.org> wrote in message news:
    >
    >>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,
    >
    >
    > Thats interesting. What CPU introduced that? (Ages since I felt the
    > need to bone up on the Pentia internals).

    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

    --
    - <Terje.Mathisen@hda.hydro.com>
    "almost all programming can be viewed as an exercise in caching"
Ask a new question

Read More

CPUs Fujitsu