Re: SGI files chapter 11 - SGI

This is a discussion on Re: SGI files chapter 11 - SGI ; In article , Eric Belhomme wrote: : Tony 'Nicoya' Mantler wrote in : news:nicoya-0DB257.22262509052006@shawnews.wp.shawcable.net: : : > It's not the end of SGI, it's the end of big UNIX. SGI should be proud : > to have been one of ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: Re: SGI files chapter 11

  1. Re: SGI files chapter 11

    In article ,
    Eric Belhomme <{rico}+no/spam@ricospirit.net> wrote:

    : Tony 'Nicoya' Mantler wrote in
    : news:nicoya-0DB257.22262509052006@shawnews.wp.shawcable.net:
    :
    : > It's not the end of SGI, it's the end of big UNIX. SGI should be proud
    : > to have been one of the last holdouts in a dying market.
    : >
    : No big Unices still alive :
    : - GNU/Linux
    : - OpenBSD
    : - FreeBSD
    : - NetBSD
    :
    : These Unices are massivelly supported on almost all computer architectures
    : that has been or will be !
    :
    : I think the market for _commercial_ unix is ended... Do you fell the
    : difference ?

    I think you misunderstood my post. The "big UNIX" was referring to was the old
    classic UNIX systems like IRIX, AIX, HP-UX, Tru-64, Solaris, etc.

    The open-source UNIX-like systems are a much different market, though they are
    primarily eroding the market that the old UNIX systems once dominated in.

    MacOS X is about as far from UNIX as you can get and still be able to compile
    and run UNIX code. The core of MacOS X isn't UNIX. The APIs, the windowing, the
    workspace, the file hierarchy, pretty much everything that makes an OS an OS is
    done the MacOS X way, not the UNIX way. Most relevant to my argument, Mac
    systems mostly don't occupy the same market space as old UNIX systems did,
    though they have made inroads in places.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler - Master of Code-fu
    -- nicoya@ubb.ca --*http://www.ubb.ca/ --

  2. Re: SGI files chapter 11

    In article ,
    Eric Belhomme <{rico}+no/spam@ricospirit.net> wrote:

    : Intel/AMD competition does not produce new technologies, it just enhance
    : x86 architecture (engraving, frequence, pipeling,...)

    I'd have to disagree with you. The x86 chips have been running RISC-style cores
    since around the PPro, and the instruction translation engines have been refined
    to the point where they're almost free from a performance standpoint. The
    growing gap between core speeds and RAM speeds makes having a compact ISA more
    important than having a simple one, so in fact one could say that CISC has "won
    the war" on technical merit.

    Add to that the transition to AMD64, which cleans up a lot of the ugly corners
    of the ISA and you have a great base to build a world class CPU on.

    AMD brought NUMA to the $500 desktop, Intel fixed up the ISA to allow full
    virtualization, both have worked on adding and refining SIMD extensions. All the
    technologies that used to be the domain of million dollar supercomputers are now
    available for everyone.

    Maybe we won't see a completely ground-up redesign on the ISA any time soon, but
    do we really need one? The ugly duckling is all grown up now.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler - Master of Code-fu
    -- nicoya@ubb.ca --*http://www.ubb.ca/ --

  3. Re: SGI files chapter 11

    Tony 'Nicoya' Mantler writes:

    > I think you misunderstood my post. The "big UNIX" was referring to was the old
    > classic UNIX systems like IRIX, AIX, HP-UX, Tru-64, Solaris, etc.


    You mean "obsolete Unix", not "big Unix".
    Linux is running on 60% of the fastest 500 supercomputers in the
    world, ncluding Blue Gene/L.

    Linux Rules Supercomputers
    http://www.forbes.com/home/enterpris...0315linux.html

    "Meuer reckons Linux powers 301 of the 500 top machines, compared to
    189 on Unix, two on FreeBSD, a Unix variant, and one on Microsoft's
    (nasdaq: MSFT - news - people ) Windows. (Seven machines are
    categorized as "other.")"


  4. Re: SGI files chapter 11

    In article ,
    Tony 'Nicoya' Mantler wrote:
    >The
    >growing gap between core speeds and RAM speeds makes having a compact ISA more
    >important than having a simple one, so in fact one could say that CISC has "won
    >the war" on technical merit.


    I wouldn't say that compact is more important than simple: if you
    have an ISA with -predictable- instruction length, you can go
    parallel on the instruction load.

    If compact was important then a bit-sliced compressed ISA would
    have the advantage; if predictable is important, then VLIW has the
    advantage.

    One could imagine an architecture in which N bits at a time are
    loaded in parallel, with each instruction being either N or N/2 bits
    long, and the N-bit instructions always being N-bit aligned.
    (i.e,, each N-bit boundary has either one N-bit instruction or
    two N/2-bit instructions, or one N/2-bit instruction and a N/2-bit NOP.)

    The alternative is to pull complete fixed-length cache-lines worth
    of instructions out, and have an internal buffer that advances as
    much as is needed according to the CISC instruction length; I suspect
    this would tend to have cache stalls waiting for the rest of the
    instruction to load, unless the cache-line size is big enough that
    the CPU can't process a cache-line's worth of instructions before
    the next cache line is ready...

    Probably someone's already simulated all of these possibilities ;-)

  5. Re: SGI files chapter 11

    In article <1quag.168976$P01.161809@pd7tw3no>,
    roberson@hushmail.com (Walter Roberson) wrote:

    : In article ,
    : Tony 'Nicoya' Mantler wrote:
    : >The
    : >growing gap between core speeds and RAM speeds makes having a compact ISA more
    : >important than having a simple one, so in fact one could say that CISC has "won
    : >the war" on technical merit.
    :
    : I wouldn't say that compact is more important than simple: if you
    : have an ISA with -predictable- instruction length, you can go
    : parallel on the instruction load.

    Well, there's two steps you need to undertake to decode a CISC instruction.
    First you need to determine the length of the instruction, then you need to
    split it into RISC sub-instructions.

    Only the first step is affected by a lumpier instruction set, and it's a very
    small step that doesn't have to be performance limiting.


    : If compact was important then a bit-sliced compressed ISA would
    : have the advantage; if predictable is important, then VLIW has the
    : advantage.

    The failure of VLIW is actually kind of unfortunate. It's a fairly good chip
    design to use if you want to emulate other ISAs or bytecodes, but for some
    reason people have a strange attraction to trying to static-compile code
    directly for VLIW ISAs, which leads to miserable failure.

    There isn't enough data available at compile time to optimize to the level
    required to make VLIW dance, but there is enough data at run time to hot-spot
    optimize during execution.

    I wouldn't be surprised if you could emulate IA64 faster than you could run it
    native on the same chip.


    : One could imagine an architecture in which N bits at a time are
    : loaded in parallel, with each instruction being either N or N/2 bits
    : long, and the N-bit instructions always being N-bit aligned.
    : (i.e,, each N-bit boundary has either one N-bit instruction or
    : two N/2-bit instructions, or one N/2-bit instruction and a N/2-bit NOP.)
    :
    : The alternative is to pull complete fixed-length cache-lines worth
    : of instructions out, and have an internal buffer that advances as
    : much as is needed according to the CISC instruction length; I suspect
    : this would tend to have cache stalls waiting for the rest of the
    : instruction to load, unless the cache-line size is big enough that
    : the CPU can't process a cache-line's worth of instructions before
    : the next cache line is ready...
    :
    : Probably someone's already simulated all of these possibilities ;-)

    Most of the lumpiness in the x86 instruction set has been ironed out over the
    years, so that it's trivial to determine the length of the common subset of
    instructions. The uglier instructions still exist, but only outside the critical
    path so handling them isn't a performance concern.

    Making cache loads more predictable by filling half of it with nulls isn't a net
    gain.


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler - Master of Code-fu
    -- nicoya@ubb.ca --*http://www.ubb.ca/ --

  6. Re: SGI files chapter 11

    rambam@bigpond.net.au wrote:


    >
    > "Meuer reckons Linux powers 301 of the 500 top machines, compared to
    > 189 on Unix, two on FreeBSD, a Unix variant, and one on Microsoft's
    > (nasdaq: MSFT - news - people ) Windows. (Seven machines are
    > categorized as "other.")"


    There's a supercomputer that runs Windows? This I have to see with my own
    eyes to believe! Hmmm, there are no supercomputers that run OS X?
    Possibly in the "other" category, huh?
    --
    --
    People Against Corruption * Right Always Triumphs
    Website: http://sarnia.selfip.org

  7. Re: SGI files chapter 11

    Walter Roberson wrote:

    > In article ,
    > Tony 'Nicoya' Mantler wrote:
    >>The
    >>growing gap between core speeds and RAM speeds makes having a compact ISA
    >>more important than having a simple one, so in fact one could say that
    >>CISC has "won the war" on technical merit.

    >
    > I wouldn't say that compact is more important than simple: if you
    > have an ISA with -predictable- instruction length, you can go
    > parallel on the instruction load.
    >
    > If compact was important then a bit-sliced compressed ISA would
    > have the advantage; if predictable is important, then VLIW has the
    > advantage.
    >
    > One could imagine an architecture in which N bits at a time are
    > loaded in parallel, with each instruction being either N or N/2 bits
    > long, and the N-bit instructions always being N-bit aligned.
    > (i.e,, each N-bit boundary has either one N-bit instruction or
    > two N/2-bit instructions, or one N/2-bit instruction and a N/2-bit NOP.)
    >
    > The alternative is to pull complete fixed-length cache-lines worth
    > of instructions out, and have an internal buffer that advances as
    > much as is needed according to the CISC instruction length; I suspect
    > this would tend to have cache stalls waiting for the rest of the
    > instruction to load, unless the cache-line size is big enough that
    > the CPU can't process a cache-line's worth of instructions before
    > the next cache line is ready...
    >
    > Probably someone's already simulated all of these possibilities ;-)


    Wow, don't I feel stupid!

    --
    --
    People Against Corruption * Right Always Triumphs
    Website: http://sarnia.selfip.org

  8. Re: SGI files chapter 11

    AlbaClause writes:

    >> "Meuer reckons Linux powers 301 of the 500 top machines, compared to
    >> 189 on Unix, two on FreeBSD, a Unix variant, and one on Microsoft's
    >> (nasdaq: MSFT - news - people ) Windows. (Seven machines are
    >> categorized as "other.")"

    >
    > There's a supercomputer that runs Windows? This I have to see with my own
    > eyes to believe!


    It might be the cluster at St Jude Hospital.

    Alternatively, it might be Bill Gates' personal notebook.:-)



  9. Re: SGI files chapter 11

    In article ,
    AlbaClause wrote:

    : Hmmm, there are no supercomputers that run OS X?

    Number 15, Mach 5 at COLSA, runs OS X, as does Number 20, System X at Virginia
    Tech (which made the headlines a few years ago). There's a total of 4 in the
    current Top-500 list (#303 "Dawson" at UCLA, #308 "Xseed" at Bowie State
    University).


    Cheers - Tony 'Nicoya' Mantler

    --
    Tony 'Nicoya' Mantler - Master of Code-fu
    -- nicoya@ubb.ca -- http://www.ubb.ca/ --

  10. Re: SGI files chapter 11

    AlbaClause wrote in
    news:GCkag.73685$fd.21312@read2.cgocable.net:

    > I wouldn't even say that the market for commercial unix is dead. Mac
    > OS X seems to be doing quite well. And several of the heavyweight
    > computer vendors are betting their chips on operating systems like
    > Linux. What about companies like Red Hat? They're pushing open
    > source operating systems like Linux, with so many changes that Linux
    > is almost becoming a commercial OS.


    OS X is atypical because the UNIX flavor is totally hidden to end user.
    The geek/hacker can play with it if he want, but it is absolutely not a
    necessity to work woth the system most users have not idea what is UNIX,
    or BSD indeed !

    About Red Hat, they don't commercialize an OS but A _flavour_ of a
    GNU/Linux distribution. Let me remember you what is a GNU/Linux distrib :
    it's a collection of open-source softwares composing the OS :
    - packages from the GNU project
    - Linux kernel
    both are under GPL license, so a GNU/Linux OS can't be commercial in any
    cases !
    Red Hat commercialize services, and certain products based on the free
    GNU/Linux OS, not the OS itself !

    Moreover, one of the most appreciated GNU/Linux distribution is Debian,
    witch is _totally_ GPL...

    --
    Rico

  11. Re: SGI files chapter 11

    Eric Belhomme wrote:

    > AlbaClause wrote in
    > news:GCkag.73685$fd.21312@read2.cgocable.net:
    >
    >> I wouldn't even say that the market for commercial unix is dead. Mac
    >> OS X seems to be doing quite well. And several of the heavyweight
    >> computer vendors are betting their chips on operating systems like
    >> Linux. What about companies like Red Hat? They're pushing open
    >> source operating systems like Linux, with so many changes that Linux
    >> is almost becoming a commercial OS.

    >
    > OS X is atypical because the UNIX flavor is totally hidden to end user.
    > The geek/hacker can play with it if he want, but it is absolutely not a
    > necessity to work woth the system most users have not idea what is UNIX,
    > or BSD indeed !
    >
    > About Red Hat, they don't commercialize an OS but A _flavour_ of a
    > GNU/Linux distribution. Let me remember you what is a GNU/Linux distrib :
    > it's a collection of open-source softwares composing the OS :
    > - packages from the GNU project
    > - Linux kernel
    > both are under GPL license, so a GNU/Linux OS can't be commercial in any
    > cases !
    > Red Hat commercialize services, and certain products based on the free
    > GNU/Linux OS, not the OS itself !
    >
    > Moreover, one of the most appreciated GNU/Linux distribution is Debian,
    > witch is _totally_ GPL...
    >


    What I meant was that Unix is not as dead as one might be lead to believe.
    Irrespective of whether or not Red Hat Linux is a "flavour" of the
    GNU/Linux distribution, the company is incorporated, the stock is publicly
    traded and listed on a stock exchange, the products and services offered by
    Red Hat, are for profit. Using the most base definition of "commercial"
    to mean "offered for profit", I assert that Red Hat Linux is in fact a
    commercial unix distribution -- if only in the most basest of terms.

    As for Mac OS X, does it really matter if the Unix base is unused by most
    users? Really, the fact remains that Mac OS X _is_ built on Unix, and
    that Unix really is the heart and soul of the modern Mac OS X. The Unix
    portion of the system is available for users to tinker with, and there can
    be no question as to whether or not Mac OS X is a commercial product.

    --
    --
    People Against Corruption * Right Always Triumphs
    Website: http://sarnia.selfip.org

  12. Re: SGI files chapter 11


    Tony 'Nicoya' Mantler wrote:
    > Add to that the transition to AMD64, which cleans up a lot of the ugly corners
    > of the ISA and you have a great base to build a world class CPU on.


    Already been done. Russia made a very nice EPIC type core, bought out
    by SUN, and buried. Much faster than IA64. Maybe SUN have based
    their latest stuff on it? Just a pity it didn't come out as a rival to
    Intel.


    > Maybe we won't see a completely ground-up redesign on the ISA any time soon, but
    > do we really need one? The ugly duckling is all grown up now.


    Grown up & still dreadfully ineffiicent.

    Ian.


  13. Re: SGI files chapter 11


    rambam@bigpond.net.au wrote:
    > Alternatively, it might be Bill Gates' personal notebook.:-)


    Probably needs to have lots of CPUs in order to be able to
    boot Windows fast enough and run Office without feeling like a dog.

    Ian.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2