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: pgerassi who wrote (27143)	2/1/2001 1:07:49 PM
From: Win Smith	Read Replies (1) \| Respond to of 275872

What probably happened is that the working set of the compile process is less than the cache available in one CPU but, when i/o tasks and other OS tasks interrupt the compile process, the working set becomes greater than the cache in the single CPU. In a typical dual system, one CPU spends all of the time handling OS tasks with some left over for compiles. I disagree with that analysis of this particular test. The test that was actually run was comparing a kernel compile running three compiler executions in parallel versus a kernel compile running only one compilation at a time. Both tests were run on a dual processor system. So the cache working set analysis doesn't really apply, the single task version also has the benefit of both processor caches.. See Message 15281465 for more details. The most straightforward explanation I see is that the comparison was running 3 compiles in parallel versus running 1 compile at a time, all on a dual processor system. The 2.5x speedup is not really as obscure as everybody is making it out to be, if the compilation tasks are not totally cpu bound. It would be more understandable if the tester gave the cpu utilization times instead of just the elapsed times, though. -Win. Edit: some followup in a similar vein, from the feedback board at the site that posted the bench. newsforge.com