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: Ali Chen who wrote (76025)	4/1/2002 2:12:30 AM
From: Joe NYC	Read Replies (1) \| Respond to of 275872

Ali, There might be a simpler explanation - caches. In true 2-CPU architecture the caches are truly independent, and the OS has certain ideas now to use them. In pseudo two-CPU, it might cause severe cache conflicts, with massive increase in off-chip traffic. To avoid this, I guess, a total OS kernel rework is necessary. Good point about caches. One problem is that it may be impossible to figure out with certainty whether SMT or single thread execution will be more efficient at any given time, in context of everything else that is going in the CPU and OS in general (state and priority of other threads, type of code in those threads). Even a totally reworked OS will not always know whether it is better to switch to another thread, or leave the CPU stalled. A close cooperation with the OS (some reporting back that the CPU is stalled) would be helpful, since the OS is going to switch to other threads at some point, and it would make sense to do so when the CPU is stalled, rather then when it is fully utilized. Another idea (that is probably years away) would be to move thread management to CPU hardware. Anyway, the jury is still out on SMT, and while it seemed to me like a great idea at first, now I am not sure if it is a step forward or sideways. Joe