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.
- Intel Sued Over Atom Power Management Feature
- CryEngine SDK Downloaded 100K Times in 5 Days
- VIDEO: Aliens: Colonial Marines Action Trailer
- Samsung May Be Gearing Up to Purchase HP's PC Division
- Blizzard: Diablo 3 Internet Requirement Prevents Hacking
- Deals August 23: Logitech Illuminated Keyboard $55
- LG Launches Its First 3D Notebook
- Report: Cedar Trail Delayed Until November
- AMD's Bulldozer: More Design Details Surface
- How The Internet Got Its Hourglass Shape
- Microsoft Details Making USB 3.0 Great in Windows 8
- LG Working on a Mouse/Scanner Hybrid
- Deals for August 24: Just Cause 2 (PC Download) $4.99
- Steve Jobs Resigns From Post as Apple's CEO
- Micron Shows Superfast 128 GBps DRAM Memory
- Hollywood, This is How You Make a Game-Based Movie
- Silicon Power Announces Marvel M01 USB 3.0 Flash Drive
- EA's Origin Sends Personal Data to Third Parties
"Chocolate Raaaaainnnnnn.... Chocolate Rain is raining on my brain"
- Chad Vader, Chocolate Rain Cover
54MB of on die memory. I wish some of my processors had even half that.
And it's name was Poulson
Very few users only ultra high end
Will this be targeted only for servers and interprise clients? Or will there be a version for the common mortal?
54MB of on die cache now that is a lot. More than what most had in ram back during the win 95/98 era in the late 90s!
Technoboner
IRT sounds amazing, assuming it works; if it recovers even one error and prevents downtime, this proc will pay for itself.
Will this be targeted only for servers and interprise clients? Or will there be a version for the common mortal?
The Itanium series was planned from the start to be enterprise-only.
Hyperthreading in Intel's newer processors is no better than the hyperthreading used in the Intel Pentium 4 processor. It doesn't speed things up. It slows things down. Using a bandaid is a horrible way to address a processor's shortcomings.
Umm you guys might want to go check what exactly an Itanium is. It's not x86 nor EMT64, it won't execute any code compiled for x86 (they removed the x86 emulation awhile back). Instead Intel has a software x86 emulator, better then their original hardware implementation but still absolute sh!t performance compared to a real x86 CPU.
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.
Didn't Microsoft already drop Itanium support? I think RedHat did too and I don't imagine there are a whole lot of Unix/Linux systems out there running Itanium.
W2K8 will be the last MS OS running on Itanium.
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.
Umm you guys might want to go check what exactly an Itanium is. It's not x86 nor EMT64, it won't execute any code compiled for x86 (they removed the x86 emulation awhile back). Instead Intel has a software x86 emulator, better then their original hardware implementation but still absolute sh!t performance compared to a real x86 CPU.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.
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).
Jeez I didn't realize the current Itanium was a dinosaur.
Umm you guys might want to go check what exactly an Itanium is. It's not x86 nor EMT64, it won't execute any code compiled for x86 (they removed the x86 emulation awhile back). Instead Intel has a software x86 emulator, better then their original hardware implementation but still absolute sh!t performance compared to a real x86 CPU.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.
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.
The Itanium series was planned from the start to be enterprise-only.
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.
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.
54MB of on die cache now that is a lot. More than what most had in ram back during the win 95/98 era in the late 90s!
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.
TA152H, other then your typical trolling attempts your very incorrect about current VLIW architecture. Heck I don't think I've ever seen you say anything right about micro architecture.
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.