Intel Discloses New Itanium Poulson Features

[Guest]

Intel is providing new information about Poulson, its next Itanium processor by the slice.

Intel Discloses New Itanium Poulson Features : Read more

 

[anonymous32111]

"Chocolate Raaaaainnnnnn.... Chocolate Rain is raining on my brain"
- Chad Vader, Chocolate Rain Cover

 

[Darkerson]

54MB of on die memory. I wish some of my processors had even half that.

 

[tuch92]

And it's name was Poulson

 

[leon2006]

Very few users only ultra high end

 

[steelbox]

Will this be targeted only for servers and interprise clients? Or will there be a version for the common mortal?

 

[nforce4max]

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!

 

[mavroxur]

Technoboner

 

[jackbling]

IRT sounds amazing, assuming it works; if it recovers even one error and prevents downtime, this proc will pay for itself.

 

[Zagen30]

[citation][nom]steelbox[/nom]Will this be targeted only for servers and interprise clients? Or will there be a version for the common mortal?[/citation]

The Itanium series was planned from the start to be enterprise-only.

 

[techguy378]

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.

 

[palladin9479]

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.

 

[jblack]

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.

 

[palladin9479]

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.

 

[ct001]

[citation][nom]palladin9479[/nom]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.[/citation]


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

 

[eddieroolz]

Jeez I didn't realize the current Itanium was a dinosaur.

 

[ta152h]

[citation][nom]palladin9479[/nom]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.[/citation]

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.

 

[ta152h]

[citation][nom]Zagen30[/nom]The Itanium series was planned from the start to be enterprise-only.[/citation]

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.

 

[Thunderfox]

[citation][nom]TA152H[/nom]That's why Intel didn't come out with 64-bit extensions to x86; they wanted Itanium to replace x86 in all segments.[/citation]

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.

 

[QEFX]

[citation][nom]nforce4max[/nom]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![/citation]

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.

 

[palladin9479]

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.