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: fyodor_ who wrote (87765)	8/30/2002 11:28:23 AM
From: Joe NYC	Read Replies (1) \| Respond to of 275872

Fyo, But the poor software that you mention should benefit, if it is really poor, it is not even written to be multi-threaded. Can non-multi-threaded software benefit, if it itself is the bottleneck? Joe

To: fyodor_ who wrote (87765)	8/30/2002 12:10:24 PM
From: Gopher Broke	Respond to of 275872

Surely this is just because the benchmarks are measuring performance of the foreground task, not the overall system throughput. (There was a lot of discussion recently about whether measuring end-user responsiveness was the best approach.) Windows boosts the priority of the foreground thread to improve responsiveness. Unfortunately hyperthreading can only impair the performance of the highest priority thread. Remember that the OS sees two physical CPUs. It chooses the two top threads to load into each pseudo-processor. The lower priority thread will doubtless run a bit faster since it can get some execution time whenever the higher priority thread stalls without having to wait for thread switches all the time, but the high priority thread will presumably have to wait some additional time after a stall is over until the second pseudo-CPU yields.