Slashdot Mirror

← Back to Stories (view on slashdot.org)

Intel, Unisys Partner On New Range of Servers

Posted by Soulskill on from the RISC-is-our-business dept.

itwbennett writes "Unisys is primarily a services and consulting company with just a small amount of revenue coming from hardware, but they may be on to something new that could 'could give them a competitive advantage at a time when the big guns are a mess,' says Andy Patrizio. Unisys and Intel are are set to introduce on September 9 a new kind of secure computing platform designed to as a replacement platform for RISC systems running mission-critical cloud and big data workloads. 'It sounds funny to hear Intel talk about RISC migration since it is in the RISC business with the Itanium,' says Andy Patrizio, 'but at this point, what's left? HP was the driving force behind Itanium and it's in chaos right now. IBM has a healthy RISC business, so the target is obviously what's left of the Sun installed base.'"

32 of 46 comments (clear)

  1. Itanium is not RISC by Anonymous Coward · · Score: 3, Informative

    Itanium is not a RISC or CISC CPU. It is EPIC (Explicity Parallel Instruction Computing). Sheesh.

    1. Re:Itanium is not RISC by Jeremy+Erwin · · Score: 4, Funny

      and in this particular case, it was an EPIC FAIL.

    2. Re:Itanium is not RISC by multimediavt · · Score: 1

      Itanium is not a RISC or CISC CPU. It is EPIC (Explicity Parallel Instruction Computing). Sheesh.

      But, the i960 is and wasn't even mentioned.

    3. Re:Itanium is not RISC by unixisc · · Score: 1

      Why, didn't they target the supercomputing market?? That would have seemed a natural for them. I believe that SGI once had such boxes based on Itanium, and one of India's PARAMs were based on it?

    4. Re:Itanium is not RISC by loufoque · · Score: 1

      It's called VLIW (Very Long Instruction Word), not EPIC.
      EPIC is a buzzword which was used in marketing Itanium.

      VLIW is a long instruction word containing a few (typically 1 to 4) shorter instructions that are to be executed in parallel (usually, they're homogeneous, but that's not necessarily the case).
      Since it has few bits to code each short instruction, and the extra instructions executed in parallel requires having more registers, it is very RISC-like.

    5. Re:Itanium is not RISC by unixisc · · Score: 1

      As was the i860. The i960 ended up being used in printers and other peripherals, but never really materialized as a general purpose CPU. Neither did the i860, which did find itself in a few supercomputers, such as Intel's Paragon. Are those 2 CPUs still made by Intel - I was under the impression that both were EOLed

    6. Re:Itanium is not RISC by unixisc · · Score: 1

      No, for Itanium, it's EPIC. See above the discussion about the differences b/w EPIC and VLIW

  2. We have the way out! by Billly+Gates · · Score: 5, Funny

    Are you tired of freedom? Does using open standards that are flexible and adoptable and freeing you from the chain of locked ecosystems? Is your uptime and performance too high?

    Unisys: We have the way out.

    With cheap plastic servers combined with an inflexible proprietary ecosystem you too can be trapped today! Fulky phb compliant with fancy brochure ware with hot business slang no one completely understands fully included for free.

    --
    http://saveie6.com/
    1. Re:We have the way out! by phantomfive · · Score: 2

      They are going to be running Xeon, not Itanium. When they talk about 'moving away from RISC,' they are talking about migrating Solaris customers over to Linux.

      Why is this news? Because one of the few remaining 'big iron' companies is making a deal with Intel to make custom chips. That's as far as I can tell from the article......

      --
      "First they came for the slanderers and i said nothing."
    2. Re:We have the way out! by bmomjian · · Score: 1

      Did anyone recognize this matches the introduction to the radio show "Escape"?

              http://en.wikipedia.org/wiki/Escape_(radio_program)

    3. Re:We have the way out! by unixisc · · Score: 1

      Okay, I read it. So how would that be different from all the other companies that make Xeon based servers - companies like HP, Dell, IBM, Oracle, Cisco and a whole host of other companies? I mean from Intel's POV, not Unisys'

    4. Re:We have the way out! by phantomfive · · Score: 1

      I have no idea

      --
      "First they came for the slanderers and i said nothing."
  3. Unisys has history as a system house by cold+fjord · · Score: 2, Interesting

    They have had some interesting systems over the years, such as the ES7000 line.

    Enterprise Servers: Unisys ES7000 Model 7600R G3 Enterprise Servers
    Up to 8 sockets and 6 TB of memory with Red Hat and Suse support.

    --
    much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
    1. Re:Unisys has history as a system house by Anonymous Coward · · Score: 4, Interesting

      Unisys's role as a system house goes back further than you think and is much more extensive than you think.

      Unisys were one of the original mainframe companies...

      http://www.unisys.com/unisys/theme/index.jsp?id=16000034 .. they go back to the days of Control Data, Prime, etc, but I suppose young whipper snippers won't know anything about that.

    2. Re:Unisys has history as a system house by TheRealMindChild · · Score: 1

      I ran my Unisys ALR 6x6 (6 ppro's) for years. It was an fun machine and served its master well

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
    3. Re:Unisys has history as a system house by stox · · Score: 4, Informative

      They had mainframes before IBM did: https://en.wikipedia.org/wiki/UNIVAC, well before the days of Control Data, Prime, etc.

      --
      "To those who are overly cautious, everything is impossible. "
    4. Re:Unisys has history as a system house by BrokenHalo · · Score: 2

      Unisys were one of the original mainframe companies...

      Uhhh, that is factually incorrect. Unisys was a comparatively recently formed entity, as a result of a merger between Burroughs and Sperry/UNIVAC. Burroughs dates back to 1904, and UNIVAC was a product of the corporation formed from the outfit that built ENIAC, which was just a little before my time. ;)

      My first systems programming job was with Burroughs, back in the 1970s, and I got involved with Sperry in 1981. Their systems were totally different from each other (in those days, a contractor like myself would either work solely on IBM boxes or on a range of other systems), but the merger stood me in good stead for a few years in the late '80s.

    5. Re:Unisys has history as a system house by wiredlogic · · Score: 1

      Moreover, they still make the ClearPath IX computers which have an ancestry back to the UNIVAC 1107 from the early 60's. It retains features that are now considered anachronisms like 9-bit chars and a non-zero null address.

      --
      I am becoming gerund, destroyer of verbs.
  4. Back in the day ... by DERoss · · Score: 4, Interesting

    I worked for Unisys and one of its predecessors for 24 years. At the time Unisys was created -- Burroughs did a hostile takeover of Univac -- the combined company had some 130,000 employees; and about half of its business was with the U.S. military. Now the company has about 22,800 employees and seems to have no military business. I stuck with the company even when they started treating salaried software professionals as if they were hourly assembly-line workers. I stuck with them when they imposed an 18-month salary freeze that did not apply to executive bonuses. I left when it was obvious that any manager who brought new work to our site would be fired.

    1. Re:Back in the day ... by bill_mcgonigle · · Score: 1

      I worked for Unisys and one of its predecessors for 24 years

      Ah, you can settle a question for me then ... my daughter is always wondering if a flying horned horse is a Pegacorn or a Unisys.

      Was this ever a part of the Unisys name?

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  5. Just Marketing by Anonymous Coward · · Score: 3, Interesting

    Unisys' existing mainframes already use Intel Xeon chips with FPGA coprocessors implementing their original mainframe ISA. So whatever they're about to unleash upon the world is likely to be a rehash of some current product. This sounds like pure marketing buzz.

    Unisys is actually interesting because they're the last large vendor still selling a sign-magnitude machine and maintaining an accompanying C compiler, albeit they only adhere to the original C89 standard. But then again, so does Microsoft.

    http://public.support.unisys.com/2200/docs/cp13.2/pdf/78310422-010.pdf

    A char is 9 bits, short is 18 bits, int is 36 bits, long is 36 bits, and long long is 72 bits. unsigned has the same range as positive signed values. Addresses are in words, not byte offsets like on Intel.

    Full C conformance actually requires a fair bit of costly emulation, so by default its disabled. For example, conversion from signed to unsigned is well-defined in C, but to get the specified behavior on a signed-magnitude implementation the compiler must emit code to compute the value, whereas on twos-complement the bit value is identical.

    1. Re:Just Marketing by Guy+Harris · · Score: 2

      Unisys is actually interesting because they're the last large vendor still selling a sign-magnitude machine

      No, they're the last large vendor still selling a ones' complement machine, as, for example, their "C Compiler Programming Reference Manual Volume 1: C Language and Library" says:

      6.1.1. Integer Type Conversions

      ...

      UCS C represents an integer in 36-bit ones complement form (or 72-bit ones complement form, if the long long type attribute is specified).

  6. It's interesting that IBM is on top by PolygamousRanchKid+ · · Score: 1

    Back in the 90's, the pecking order was: Sun, HP (DEC/Compaq), IBM. Now it's something like: IBM, Sun (Oracle), HP.

    So I have to wonder . . . is IBM on top, because they have better technology . . . ?

    . . . or . . .are Sun and HP behind, because they have crappy management . . . ?

    I'm expecting the responses will be quite amusing, yet insightful.

    --
    Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
  7. Unisys and Itanium by unixisc · · Score: 2

    True, but for the purposes of discussing the market, this is a valid statement. Just like the general purpose RISC CPUs - now just SPARC and POWER - run either UNIX or proprietary OSs or Linux/BSD, similarly, the only thing that Itanium runs is HP/UX, Debian and FreeBSD. Its standing is even worse than that of SPARC, in that there are other OSs such as OpenBSD that support the SPARC, whereas there is just one Linux and one BSD distro each supporting Itanium.

    It's good that Intel is making an attempt to resurrect the Itanium. Unisys could do one of 2 things - go completely w/ Debian or FreeBSD and in their services, support it as the OS: since their customers are presumably their consulting customers as well, they'd have nothing to lose here. Or they could just pick up the pieces of Xinios, take UnixWare and port it to Itanium if they want a proprietary OS. They are probably best off going w/ FBSD.

    As for Intel, they should simply take Itanium3 and shrink it, and keep adding cores. That way, they don't need to worry about future compilers and support, and can just optimize the best for the Itanium3 over time, and make embarrassingly parallel applications. That way, they can avoid sinking much more cash into Itanic, and let it actually make them some money for a change.

    1. Re:Unisys and Itanium by saleenS281 · · Score: 1

      Except that Windows 2008, Redhat 5, and SUSE all run on Itanium as well. Just because they aren't releasing new code (in the case of Microsoft and Redhat, SUSE will continue to release new code indefinitely) doesn't mean it isn't still supported.

  8. switch to x86 and cheap Unix by jbolden · · Score: 1

    I'd say it came from their speed in switching to x86 and cheap Unixes. Sun had the strongest ties to hardware so they had the most difficulty staying with Solaris and Sparc. IBM was already focused on consulting so they had the least difficulty. HP had different divisions with different interests so on average they were in the middle somewhere.

  9. In other news, Unisys still alive by Cid+Highwind · · Score: 1

    Well ... sort of.

    --
    0 1 - just my two bits
    1. Re:In other news, Unisys still alive by ISoldat53 · · Score: 1

      God help us.

  10. Itanium is more RISC than VLIW by unixisc · · Score: 1
    From Wiki:

    EPIC architectures add several features to get around the deficiencies of VLIW:

    • - Each group of multiple software instructions is called a bundle. Each of the bundles has a stop bit indicating if this set of operations is depended upon by the subsequent bundle. With this capability, future implementations can be built to issue multiple bundles in parallel. The dependency information is calculated by the compiler, so the hardware does not have to perform operand dependency checking.
    • - A software prefetch instruction is used as a type of data prefetch. This prefetch increases the chances for a cache hit for loads, and can indicate the degree of temporal locality needed in various levels of the cache.
    • - A speculative load instruction is used to speculatively load data before it is known whether it will be used (bypassing control dependencies), or whether it will be modified before it is used (bypassing data dependencies).
    • - A check load instruction aids speculative loads by checking whether a speculative load was dependent on a later store, and thus must be reloaded.

    The EPIC architecture also includes a grab-bag of architectural concepts to increase ILP:

    - Predicated execution is used to decrease the occurrence of branches and to increase the speculative execution of instructions. In this feature, branch conditions are converted to predicate registers which are used to kill results of executed instructions from the side of the branch which is not taken.

    - Delayed exceptions, using a not a thing bit within the general purpose registers, allow speculative execution past possible exceptions.

    - Very large architectural register files avoid the need for register renaming.

    - Multi-way branch instructions improve branch prediction by combining many alternative branches into one bundle.

    The Itanium architecture also added register renaming and rotating register files, a tool useful for software pipelining since it avoids having to manually unroll and rename registers.

    Actually, the last item above - introducing register renaming and rotating register files - makes Itanium squarely a RISC CPU. Some of the VLIW techniques, such as long instruction words and enhanced MIMD techniques were also adapted by some RISC CPUs, such as the Alpha 21264, as well as POWER (don't remember which generation). The whole idea of VLIW was to dump things to the compiler so that the clock speed could be enhanced as a result of the simpler circuitry. In reality, that never materialized, since only a very small percentage of the die was needed for features like register renaming or rotating register files.

    At any rate, the above, if one takes Itanium to be the implementation definition for EPIC, since Intel came up w/ the term, is that EPIC is not VLIW, but something in b/w VLIW and RISC. I do think it's a redundant architecture, and makes the point that RISC was actually the sweet spot on the spectrum between having all the complexity in hardware (CISC) vs having it all in the compiler (VLIW). However, as others have pointed out, Itanium managed to kill 3 architectures - PA-RISC, MIPS V and Alpha - before it turned out to be short of its goals. It would be nice if Intel decided to make several versions of it and try and proliferate it in the market.

    1. Re:Itanium is more RISC than VLIW by tlhIngan · · Score: 2

      At any rate, the above, if one takes Itanium to be the implementation definition for EPIC, since Intel came up w/ the term, is that EPIC is not VLIW, but something in b/w VLIW and RISC. I do think it's a redundant architecture, and makes the point that RISC was actually the sweet spot on the spectrum between having all the complexity in hardware (CISC) vs having it all in the compiler (VLIW). However, as others have pointed out, Itanium managed to kill 3 architectures - PA-RISC, MIPS V and Alpha - before it turned out to be short of its goals. It would be nice if Intel decided to make several versions of it and try and proliferate it in the market.

      Well, EPIC was an interesting experiment at pushing into software was is now done by hardware.

      Remember the front end of a modern CPU (most of them these days, there's still a few that are straight) consists of a instruction buffer, instruction decomposer, and reorder buffers. What happens is the instruction comes to the processor and is decomposed into micro-ops. These micro-ops are then sent to the reorder buffer (where they acquire their register renaming and dependency checks) and then issued to the superscalar execution units as the hardware determines what instructions can be executed when.

      Itanium pushes all that into software - thinking that since most software is compiled and not handwritten, the compiler knows the interdependencies and things that look like dependencies but may not be and is able to do the parallelization to the superscalar execution units, instruction reordering and dependency checking and enforcement and such since it's closer to the actual source code.

      Thus supposedly you had two benefits - as compilers got better, your code sped up as it gets executed more efficiently by the older processors as well. The other benefit was you could get more speedups since the hardware had to be conservative when issuing instructions because missing a dependency (false or otherwise) will result in incorrect operation. But since the compiler knew what the code was doing, it could be very aggressive with its instruction reordering. If the compiler knew it had to load something from memory, it could issue a preload instruction many cycles before so the data would be ready and waiting by the time the need came around (right now the front end decomposes the memory access into a load and stuffs it into the reorder buffer in the hopes the ROB is big enough that the load/store will be executed before the instruction that needs it winds its way through the decode and issue). This can also include precomputing memory addresses if the compiler knows the values ahead of time.

      The problem was - the compilers of the day weren't up to the task - it's a really hard problem. That and the x86 guys were making great strides in their hardware-based approach to the point where the supposed benefits just weren't realized.

  11. CPU tech by Funk_dat69 · · Score: 1

    It's was CPU tech that put IBM on top.

    Sun couldn't get a new design out to save their lives and HP shit-canned PA-RISC to get in bed with Intel on Itanium, which has always been late and slow and difficult.

    IBM on the other hand kept slowly be steadily improving their ppc CPU tech.

    --
    FUNK!
  12. GIF patent by HuguesT · · Score: 1

    Reminding all whipper-snappers here that UNISYS is the nice patent troll society who wanted everyone to pay royalties for using the GIF image format because they claimed a patent on LZW compression. This was after GIF had become popular. This led to the development of the PNG open format. The patents have all expired in 2004 but that doesn't make UNISYS a nice company.