dual core itanium2 coming

[jhu]

that means price cuts on the rest of the itaniums. hopefully. or not.

 

[Wingznut]

Are you in the market for an Itanium?

 

[jhu]

sure, if and when the prices ever come down. but they probably won't

 

[Wingznut]

Originally posted by: jhu
sure, if and when the prices ever come down. but they probably won't

Come down to what level... The desktop price points?

There's really no reason to expect that, since it's not a desktop processor.

 

[Vee]

Originally posted by: jhu
sure, if and when the prices ever come down. but they probably won't

They will, actually. That is, the overall hardware cost of Itaniums is going down. But it won't be cheap. Intel is converging Xeon(64) and Itanium hardware structure. My main interest in this is that we might see more capable Xeon systems.

As for Itanium, did you consider software costs!? - What do you intend to run on it?

 

[jhu]

you know, if the price of a complete system ever got down to the $2.5k range, i'd seriously consider getting one. since i'll be running linux, all the software's free anyway. also, i'd get to have uber-geek status.

 

[mamisano]

Originally posted by: jhu
you know, if the price of a complete system ever got down to the $2.5k range, i'd seriously consider getting one. since i'll be running linux, all the software's free anyway.

What would be your main use of such a machine? For $2.5K, you can make a mighty nice Dually Opteron box.

 

[clarkey01]

Opteron... Go with that.

Personally while I'm begining to like IA-64 a lot, I still think they made some fundamental flaws at the beginning that they're having to rectify.

Stripping away the re-order logic may have simplified the scheduler but they were probably overly agressive doing it. Sure you can argue compilers will catch up with the hardware, but to have gone out and thrown the complexities of VLIW at the developers might have been a bad call. Instead I think the Itanium II's approach of a partial re-order (5 deep) should have been included from the out. Once the compilers had caught up with the architecture then the scheduler could have been simplified.

Instead we see a processor that suffers huge penalties for poorley ordered code but with architectual features that have the potential to hide them. Speculative loading and load completion instructions are a good solution to hiding load store latency but how many compilers can make proper use of them yet?

The other thing that I don't understand is why Intel didn't implement HT as part of the architecture instead of planning it as an add-on. HT has huge potential for increasing performance of the IA-64 family. Since the the atom molecules used by the Itanium's have a high portion of nop's filling issue ports. A second seperate stream of code could probably fill those ports without huge penalties for the direct port mapping.

Wouldn't the function of the scheduler be close to an exclusive or with a wait if two ports are scheduled for on the same clock. It wouldn't need any reordering just a packing stage and then an unpack on retire. Given the Itanium II has the ability to fetch two molecules per clock then its clear they already have a front end capable of providing two seperate molecules from different threads. If the code were still written for the Itanium II's two molecule window then the processor would still expected to extract the same parrelism, but have potential to extract more