Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Intel, Unisys Partner On New Range of Servers

Soulskill posted about a year ago | from the RISC-is-our-business dept.

Intel 46

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.'"

cancel ×

46 comments

Itanium is not RISC (3, Informative)

Anonymous Coward | about a year ago | (#44627295)

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

Re:Itanium is not RISC (4, Funny)

Jeremy Erwin (2054) | about a year ago | (#44627359)

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

Re:Itanium is not RISC (0)

Anonymous Coward | about a year ago | (#44627943)

maybe not, research done in itanium has been used in xeons.

Re:Itanium is not RISC (0)

Anonymous Coward | about a year ago | (#44628893)

maybe not, research done in itanium has been used in xeons.

And a research done to find a viable market for Itanium has gone on for eons. Itanium's market seems to be unobtanium.

Re:Itanium is not RISC (1)

unixisc (2429386) | about a year ago | (#44629767)

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?

Unisys and Itanium (2)

unixisc (2429386) | about a year ago | (#44628111)

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.

Re:Unisys and Itanium (1)

saleenS281 (859657) | about a year ago | (#44630749)

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.

Re:Itanium is not RISC (1)

multimediavt (965608) | about a year ago | (#44629583)

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

But, the i960 [intel.com] is and wasn't even mentioned.

Re:Itanium is not RISC (1)

unixisc (2429386) | about a year ago | (#44630389)

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

Re:Itanium is not RISC (0)

Anonymous Coward | about a year ago | (#44632993)

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

A former employer of mine marketed (possibly still markets, depending on whether or not they can source the components) several models of slot machine running on i960 processors. They were just hitting the market when I left (both the company and Nevada), but apparently they were very popular machines.

Re:Itanium is not RISC (0)

Anonymous Coward | about a year ago | (#44629731)

EPIC is marketing-speak for VLIW.

Itanium is more RISC than VLIW (1)

unixisc (2429386) | about a year ago | (#44630067)

From Wiki [wikipedia.org] :

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.

Re:Itanium is more RISC than VLIW (2)

tlhIngan (30335) | about a year ago | (#44631327)

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.

Re:Itanium is not RISC (1)

loufoque (1400831) | about a year ago | (#44629885)

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.

Re:Itanium is not RISC (1)

unixisc (2429386) | about a year ago | (#44632829)

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

We have the way out! (5, Funny)

Billly Gates (198444) | about a year ago | (#44627305)

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.

Re:We have the way out! (0)

Ed Avis (5917) | about a year ago | (#44627321)

If you have an Intel server running Linux is that really any different from a SPARC server running Linux or Solaris?

Re:We have the way out! (0)

Anonymous Coward | about a year ago | (#44627345)

Go search for Unisys we have the way out in slashdot archives?

Old joke and the Foss response of we have the way in? An epic marketing disaster for Unisys the last time they tried this with crappy 32 cpu windows system that didnt scale

Re:We have the way out! (2)

phantomfive (622387) | about a year ago | (#44627349)

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......

Re:We have the way out! (1)

unixisc (2429386) | about a year ago | (#44630841)

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'

Re:We have the way out! (1)

phantomfive (622387) | about a year ago | (#44631607)

I have no idea

Re:We have the way out! (-1)

Anonymous Coward | about a year ago | (#44627599)

North-Korean company partners with former East-Germany company on new range of servers. Would I buy such a server?

I'm not American, and only idiots would now buy such American brands. It is the most nasty country in history in total-control and spying, more nasty than anything combined before. Fuck those fascists, hard and deep.

Re:We have the way out! (0)

Anonymous Coward | about a year ago | (#44630391)

This just in! Unisys has outsourced the cpus in their new Intel line of servers to AMD.

Unisys has history as a system house (2, Interesting)

cold fjord (826450) | about a year ago | (#44627357)

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

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

Re:Unisys has history as a system house (4, Interesting)

Anonymous Coward | about a year ago | (#44627401)

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.

Re:Unisys has history as a system house (4, Informative)

stox (131684) | about a year ago | (#44627579)

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

Re:Unisys has history as a system house (1)

wiredlogic (135348) | about a year ago | (#44630711)

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.

Re:Unisys has history as a system house (2)

BrokenHalo (565198) | about a year ago | (#44628783)

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.

Re:Unisys has history as a system house (0)

Anonymous Coward | about a year ago | (#44652353)

So, in short, Unisys was two of the original mainframe companies.

Re:Unisys has history as a system house (1)

TheRealMindChild (743925) | about a year ago | (#44627557)

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

Re:Unisys has history as a system house (0)

Anonymous Coward | about a year ago | (#44627903)

the also have a history as patent trolls.

Re:Unisys has history as a system house (0)

Anonymous Coward | about a year ago | (#44628391)

This at a time when AIX and Solaris are struggling to support more than 1024 cores or 64 CPUs.

Wait, what?

Back in the day ... (4, Interesting)

DERoss (1919496) | about a year ago | (#44627441)

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.

Re:Back in the day ... (0)

Anonymous Coward | about a year ago | (#44628427)

Actually by the time of the Burroughs takeover, Univac had already changed it's name to Sperry, I think.

Re:Back in the day ... (1)

bill_mcgonigle (4333) | about a year ago | (#44629817)

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?

Just Marketing (3, Interesting)

Anonymous Coward | about a year ago | (#44627485)

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.

Re:Just Marketing (2)

Guy Harris (3803) | about a year ago | (#44627815)

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" [unisys.com] 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).

It's interesting that IBM is on top (1)

PolygamousRanchKid (1290638) | about a year ago | (#44627899)

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.

switch to x86 and cheap Unix (1)

jbolden (176878) | about a year ago | (#44628523)

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.

CPU tech (1)

Funk_dat69 (215898) | about a year ago | (#44631135)

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.

Re:It's interesting that IBM is on top (0)

Anonymous Coward | about a year ago | (#44631191)

Stable leadership helps.

What's left (0)

Anonymous Coward | about a year ago | (#44628619)

what's left of the Sun installed base

Who was foolish enough to try to install a base on the Sun? I doubt there's anything left of it, it's all been vaporized and burned up.

In other news, Unisys still alive (1)

Cid Highwind (9258) | about a year ago | (#44629073)

Well ... sort of.

Re:In other news, Unisys still alive (1)

ISoldat53 (977164) | about a year ago | (#44630549)

God help us.

GIF patent (1)

HuguesT (84078) | about a year ago | (#44640045)

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 [wikipedia.org] 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.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...