Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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: combjelly who wrote (53571)	9/1/2001 12:38:40 PM
From: fyodor_	Read Replies (1) \| Respond to of 275872

combjelly: HT only comes into play after the uops are being executed and are in the pipeline. An interesting aspect of hyperthreading is that it likely will put more pressure on the trace cache, and expanding it's size without changing it's latency may be a tricky thing to do... It seems to me that unless you use heavy SIMD optimization, the P4 would often be decode-limited. Wouldn't adding a second decoder make HyperThreading much more interesting? -fyo

To: combjelly who wrote (53571)	9/1/2001 3:23:26 PM
From: wanna_bmw	Respond to of 275872

Combjelly, Re: "HT only comes into play after the uops are being executed and are in the pipeline." Actually, it's the other way around. Hyperthreading doubles a lot of the front end engine, like the Program Counter and the Instruction Decoder. The back end is left relatively unchanged. Uops that travel through the core are labeled as to what thread context they belong. I imagine the execution engine benefits on its own, due to less uops being dependant on one another (since different threads are hopefully not accessing the same areas of memory). In this way, more execution resources can be in use, since fewer uops have dependency conflicts. wanna_bmw