Intel Discloses New Itanium Poulson Features
Intel is providing new information about Poulson, its next Itanium processor by the slice.
Tukwila, the current 65nm Itanium 9300 series, is overdue for a replacement in big iron computer systems. We already know that Poulson is still scheduled for a 2012 launch, and that it will be built in 32nm, integrate 3.1 billion transistors, a 12-wide issue architecture, up to 54 MB on-die memory as well as eight CPU cores with support for eight more virtual cores via Hyper Threading.
Adding to the information disclosed early this year at the ISSCC 2011, Intel revealed at the Hot Chips conference that the processor will ship with Instruction Replay Technology (IRT) as an enhancement for RAS - and become Intel's first processor that supports Instruction Replay RAS. The technology uses a new pipeline infrastructure to detect "transient errors in execution." IRT enables Poulson to re-execute instruction and recover or avoid instruction errors.
Poulson also adds dual-domain multi-threading that finds its way into the CPU's Hyper Threading. According to Intel, the new feature will enable independent front and backend pipeline execution, improve the efficiency of multi-threading and squeeze more performance out of the chip. Additionally, Itanium is getting new instructions to enhance integer operations, as well as higher parallelism and multi-threading capabilities with expanded data access hints, expanded software prefetch and thread control.
- Chad Vader, Chocolate Rain Cover
The Itanium series was planned from the start to be enterprise-only.
Next IA-64 is VLIW architecture, meaning it executes multiple instructions per cycle, unfortunately these instructions must be determines during compile time and not during run time. What you end up with is code going through a CPU that has a large (30~50%) portion that is completely useless as the compiler predicts incorrectly. There is a hardware branch prediction unit but it's nothing like what is in the x86 CPU's. It just tries to predict which blocks of VLIW code to push through the CPU and pre-cache as much as possible. It can't actually recode the VLIW code for parallel execution.
What you ultimately get is crap performance in anything that's not DSP / encoding related. Webservers / database servers / application servers all suffer greatly under an IA-64 architecture. There is a reason most of the industry goes with IBM Power or Sun SPARC for their RISC processing needs.
Really you have HP-UX as the only real OS for Itanium (other then some Linux varient). Also HP is the only vender mass producing Itanium systems right now and their not making many of them. No one really wants them.
There are some very good ideas in that architecture though, that I hope work their way down to mainstream processors. The rotating register file would be amazing if moved to x86/x64 (which spends so much time just pushing/popping regs between function calls), just to name one thing (there are many other's).
Your understanding is very, very poor.
Itanium does have very good branch prediction. What you're very, very confused about, and trying to spread confusion about is scheduling of instructions. Itanium has been in order since it has been made, and has no facility to reorder instructions in hardware. Consequently, compilers are expected to handle this load more efficiently than x86 compilers. This is in no way the same as saying it doesn't have effective branch prediction. They are two different things.
Bzzzt, wrong answer. Very wrong answer.
Itanium was originally supposed to finally get rid of the inefficient and horrible x86 instruction set, by moving the world to 64-bit with Itanium. It even ran x86 in hardware, initially, and Intel hoped they would sell, and people would write native software for it, and it would completely replace the x86 processors in all segments. That's why Intel didn't come out with 64-bit extensions to x86; they wanted Itanium to replace x86 in all segments.
And also supposedly why the P4 sucked - Intel wasn't paying attention to x86 any more, so AMD snuck up on them and took advantage of their mistake. That's not going to happen again.
Heck, my first hard drive was only 10MB. The 20MB version was more than a full month's rent more expensive.
For that matter I had a workstation 486-DX50 that had a MB with 16 simm slots. @ 4MB that gave me 64MB to play with, even the server boys were jealous.
Just amazing how far things have come. 8+ cores, 3GHz O/C'd to 5, 3TB HDs, 512+ MB SSD and even crappy computers come with 4GB of ram.
IA-64 originally was purely in-order only with the compiler doing all branch predictions. Current IA-64 is capable of rearranging instruction blocks but not the instructions themselves. Meaning
Block 1 (INSTR 1 / INSTR 2 / INSTR 3)
Block 2 (INSTR 4 / INSTR 5 / INSTR 6)
Block 3 (INSTR 7 / INSTR 8 / INSTR 9)
Could be reordered to execute as
Block 1
Block 3
Block 2,
But the instructions inside the blocks (aka Words) can not be rearranged. This is how Intel as able to get more performance out of a poorly performing architecture, VLIW itself doesn't lend well to executing arbitrary code.
Next while x86 may have some serious flaws, it's neither inefficient nor horrible. Intel did not create IA-64 to "save" us from x86, they created it and tried to force it on OEM's in an attempt to shut AMD down. The courts had ruled that AMD has a perpetual license to develop CPU's that are x86 compatible. Intel therefor wanted to force everyone to switch to a new "Intel Only" architecture that no one else in the world would have rights to. Intel has no plans to license IA-64 to third party venders to create compatible chips. Thus if IA-64 became popular Intel would become the ~only~ producer for consumer processors in the world, and thus effectively create a monopoly. Thankfully it didn't work, and no amount of Intel PR slides can mask the absolute horrible performance of IA-64.
If you want a RISC 64 bit architecture then go with the experts, IBM Power or Sun SPARC. Both have been doing 64bit RISC high performance computing long before Intel designed the Itanium.