SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Advanced Micro Devices - Moderated (AMD) -- Ignore unavailable to you. Want to Upgrade?


To: pgerassi who wrote (63150)11/9/2001 2:16:11 AM
From: PetzRead Replies (1) | Respond to of 275872
 
Thanks, Pete, I thought Tench's response was incorrect, but didn't have the time to dig up that Aceshardware article explaining register renaming and another article explaining SMT. Re-ordering can't always unblock execution, sometimes a register reassignment can.

Suppose two variables in memory are to be incremented by loading into the AX register, incrementing the register and then storing the result. I see no reason why the AX register coded by the programmer could not instead be the extra 32 bits of some other register on an x86-64 CPU. The second reference to the AX register can be "remapped" by the CPU to a register that the programmer knew nothing about.

Petz



To: pgerassi who wrote (63150)11/9/2001 10:35:46 AM
From: fyodor_Read Replies (1) | Respond to of 275872
 
Pete: That there are two virtual sets of registers only exists as map onto the register rename pool. Since that is how these are truly implemented, SMT could in fact slow down a CPU for any given thread and in some cases even both threads would be slower than just one fast thread. This is probably a factor due to the length of the P4 pipeline. Thus, any P4 with SMT will require additional reorder registers in the pool to prevent this bottleneck from showing up.

What if the P4 only switched thread when there was a cache miss (L2)? This normally results in a 100+ cycle stall, but if you had a second thread waiting to take over...

-fyo