Slashdot Mirror
Intel, Unisys Partner On New Range of Servers
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.'"
Itanium is not a RISC or CISC CPU. It is EPIC (Explicity Parallel Instruction Computing). Sheesh.
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/
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
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.
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.
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.
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.