Itanium - any comments?

Quote:

---

Originally posted by Bash:

...When you compile code for the x86, you have to continually load variables from memory because you don't have near enough registers to store all of them. With 128 user accessable registers you'll be able to compile code much more effeciently. Of course, this is a necessity for the Itanium since the compiler is doing all of the instruction scheduling too.

-Bash

[This message has been edited by Bash (edited November 09, 2000).]

---

It gets better. Stack mapping to registers can occur on registers 32-127. This allows you to allocate and call subroutines by passing parameters by register-stack. This results in a unified subroutine calling model but with the speed of passing by register. Let's examine this further:

The typical IA-32 subroutine calling model involves decrementing the ESP and moving the parameters on to the SS:[ESP] memory area. The called subroutine retrieves from SS:[ESP]. The pass and retrieval of subroutine parameters are all load/store instructions. Passing by register is extremely difficult to do because of the few general registers in IA-32, and the difficulty in supporting this is in a precompiled object or library. In summary, passing by register on IA-32 is nearly non-existant.

In IA-64, the "default" passing model is on the register-stack. IA-64 instructions are provided to allocate and free register stack space, which automatically fills/spills to the stack and rotates as needed. Well, if you think that fill/spills are load/stores, you're right. But if you analyze the stack frame level of object-orientated code, in particular, you'll find that the stack frame level a majority of the time stays well within 1-2 levels a high percentage of the time from the current level. And because most methods are not parameter heavy, chances are that spills/fills are infrequent. So effectively, registers 32-127 become a register cache for the run-time stack.

Better still, because this is the only parameter passing model, these benefits are gained across precompiled objects and libraries without special treatment. Big win.

Quote:

---

Originally posted by Arcadian:
jtshaw, I have heard that there are already over 400 apps compiled in native IA-64 already. This includes a lot of scientific apps as well.

One professor from a University (I forget which one) runs scientific programs and said that there was a routine that he used to run on the supercomputers of two years ago that took a day to complete and get data. On a 4 processor Itanium system (he has one of the Pilot release systems), this same task took less than 1/2 hour. Granted that computers have matured over the last two years, but to get a 48x improvement over a supercomputer seemed impressive to me!

I think there will be a lot of software apps available for Itanium by launch (I think I read somewhere that launch was in Q1 2001). I also think Itanium will give Ultrasparc III a run for its money.

Also, this comment is for jaywallen. What parts of the architecture do you forward to the most?

---

I know a Prof (more of research ph.d)that is running the "pilot" release now. It is with some PHAST technology via P&G. Personally, I would say the computers are unbelievable when doing projects that can actually utilize the multi-processor IA-64. I have used the computer for different apps, and running a program developed for rendering the images for the consortium runs probably 10 times as fast as what is took before. Now the bottleneck problem is the hardware that the program is rendering for. The inability to run the old apps is going to be the downfall for the near future, but scrapping the old and starting anew can only be a good thing.

Now if that weakest link in hardware could be taken care of....

Quote:

---

Originally posted by mosier:
I know a Prof (more of research ph.d)that is running the "pilot" release now. It is with some PHAST technology via P&G. Personally, I would say the computers are unbelievable when doing projects that can actually utilize the multi-processor IA-64. I have used the computer for different apps, and running a program developed for rendering the images for the consortium runs probably 10 times as fast as what is took before. Now the bottleneck problem is the hardware that the program is rendering for. The inability to run the old apps is going to be the downfall for the near future, but scrapping the old and starting anew can only be a good thing.

Now if that weakest link in hardware could be taken care of....

---

Wow, thanks for the info, Mosier. It's nice to hear that rendering software gets so much of an improvement. I have several questions, though.

1) What system were you using previously that ran 10 times slower?

2) Which bottleneck in hardware were you refering to?

3) What rendering program were you using before, and which are you using now? I am curious what Itanium does and does not support.

4) What is PHAST from P&G?

5) How many Itanium processors is this professor running?

Thanks again... I appreciate any comments. https://www.sharkyforums.com/images/.../2005/06/5.gif

Quote:

---

Originally posted by Humus:
[B] There are a lot of instructions in flight in the Athlon too, and from what I understand there's no gain of having more than 17 renaming register, and I doubt the situation is significantly different on the P3 ...
But it's not an important issue ...

B]

---

The number of rename registers is directly related to the number of pipeline stages. The more stages the more rename registers you need. The Athlon has 72 and the P4 has 128. I don’t know *** many the PIII has but I suspect it is about the same as the Athlon since the working parts of the pipelines are about the same length.

Quote:

---

Originally posted by Conrad Song:
http://developer.intel.com/design/ia..._ovw/index.htm

Somehow I don't know of any server microprocessor out there today that ISN'T excessively complex. Itanium is a beast. Not the same animal as POWER4, but a beast still the same.

---

The only reason I am concerned with Itanium complexity is that EPIC should have resulted in a simpler design, not a more complex one. Rumors are that McKinley is half the size of Itanium and has more on chip cache as well. So most likely this is the result of a poor first design for IA-64, but I want to see something more definite before I decide.

No kidding the Power 4 is a beast. I bet each Power 4 module consumes 1500 W or more. A fully configured 64 processor Power 4 could consume 10 kW or more.

Quote:

---

Originally posted by Moridin:
The number of rename registers is directly related to the number of pipeline stages. The more stages the more rename registers you need. The Athlon has 72 and the P4 has 128. I don’t know *** many the PIII has but I suspect it is about the same as the Athlon since the working parts of the pipelines are about the same length.

---

Where did you get that information from?
I was unable to find any information about how many renaming register there are on the Athlon on AMD site.

Quote:

---

Originally posted by Humus:
Where did you get that information from?
I was unable to find any information about how many renaming register there are on the Athlon on AMD site.

---

Whoops, I may have been thinking of the number of instructions in the Instruction control unit/reservation satiation. (That will teach me to post when I am drinking.) Sorry about that.

I have seen numbers in this range before for the number of rename registers though, but I can’t remember where just now. I know you need a lot more then 10 to 20 registers, 10 to 20 sets of registers (80 to 160) makes more sense to me. You may need up to 1 set of registers for each instruction currently in one of the pipelines.

I'll start with admitting that I'm not sure how the renamning actually work and I don't have any Athlon pipeline scheme in front of me now, but I don't believe in 100 renaming register.
Register renaming is only used to avoid pipeline stalls with false dependencies. First of all those aren't too many (ok, not uncommon but they are below perhaps 15% (wild guess) of the code). Anyway, we may want to avoid stalling the pipeline even in the worst case scenario which would be something like this:

ADD EAX, EXB
ADD EBX, ECX
ADD ECX, EDX
ADD EDX, ESI
ADD ESI, EDI
ADD EDI, ESP
ADD ESP, EBP
ADD EBP, EAX
...
etc.

My feeling is that you have a bunch of renaming registers, and when a write after read occurs you need to assign the register to a new renaming register for the write operation so that reading and writing to that register can occure at the same time. Now that a register is renamed the old register is free to be used for subsequent renaming operations. The worst case scenario is that all register would need to be renamed, like in my example above with a cpu that could execute 7 instructions in parallel (the last instruction has a true dependency of the first). In this case you need 15 renaming registers. Add to that the flags register + 1 for renaming for it and you have 17 registers.

[This message has been edited by Humus (edited November 12, 2000).]

I'm guessing the IA64 transition will be a lot like the Mac PPC transition way back when. Personally, I think if Intel can do a decent job of the IA64 as opposed to the early days of the P3 it will be an awesome setup that blows the doors off AMD in the high end server market.

On the other hand, this is Intel, and so I'd take everything surrounding IA64 with a hefty helping of salt.

Also, Intel does tend to overcharge for their chips and I'm confident that AMD will retain its price/performance leadership. Clawhammer looks way more feasible for the average high end user, and Sledgehammer should do well in the high end market as well because it won't have the transition problems of IA64.

------------------
"It is better to keep your mouth closed and look stupid, than to open it and remove all doubt."

~Famous Dead Guy

Quote:

---

Originally posted by nukefault:
Also, Intel does tend to overcharge for their chips and I'm confident that AMD will retain its price/performance leadership. Clawhammer looks way more feasible for the average high end user, and Sledgehammer should do well in the high end market as well because it won't have the transition problems of IA64.

---

No transition? Sledgehammer will have 10x the transition that Itanium will have. First, ask yourself what Itanium needs. The first answer I expect you to say is software. Now think about the transition Seldghammer needs. If you stare back at me with a blank look, I'm going to assume you don't know, so let's talk infrastructure.

* Will AMD have rack optimized servers ready from OEMs?
* Will motherboard manufacturers include 64bit or 66MHz PCI in their 760MP motherboards?
* Will AMD push forward with power and disk redundancies, as well as hot-plug?
* Will AMD's systems scale well, and include ample memory upgradability?
* Will AMD have support from major server OEM's like IBM, HP, NEC, or Compaq?
* Will AMD include ECC support for memories and caches?
* Will AMD be able to guarentee stability to increase uptime and reliability?
* Will AMD include server management features to increase servicability?

These are all transition items necessary for Sledgehammer's acceptance. AMD is not known for being a good supplier of any of them, so I have a feeling Sledgehammer will have a tough time breaking through the low end.

But, I'm glad you mentioned this, since it gave me a chance to explain about server infrastucture. Thanks for the post, nukefault. https://www.sharkyforums.com/images/.../2005/06/5.gif

I think the sledgehammer may have a hard time in the server area, but I think it may actually be rather popular in desktops if the price is compititive.

Quote:

---

Originally posted by Humus:
I think the sledgehammer may have a hard time in the server area, but I think it may actually be rather popular in desktops if the price is compititive.

---

Clawhammer will be the processor for desktop systems, and I can safely say that you will definately NOT see Sledgehammer for desktops. AMD plans on using a ccNUMA architecture for the Sledgehammer platform, and their 4-way and 8-way systems will be very expensive. I figure $10,000-$20,000 for an entry level system (this is still higher price/performance than Intel's 4-way systems, which go from $20,000-$40,000 for "light" configurations). Clawhammer will probably go for the $2,000-$3,000 systems (performance desktop segment), so if you are looking for a K8, that should be the one you choose.