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: bruce rogers who wrote (27061)	1/31/2001 10:25:57 PM
From: Jim McMannis	Read Replies (1) \| Respond to of 275872

Shoot, I'm just thrilled someone besides AMD got a SMP system running.

To: bruce rogers who wrote (27061)	1/31/2001 11:08:29 PM
From: TechieGuy-alt	Read Replies (2) \| Respond to of 275872

When you see a difference like this, either the single processor version was starved for resources, or something was different between the runs. I agree, my hypothesis is the single processor is quite starved for data (core stalled). See discussion with JC on this issue a few posts ago. I'm pretty sure what happened is that the first run all the files were on disk, and part of the compile time was disk access. Immediately after that, he timed the 2 thread version, and all the files were read out of the cache. What cache? Do you know that the average linux kernel source runs greater than 15-20 megabytes (depending what you include in the make config and the newer ones are even greater than that)? Once you include the amount of object files written back to disk (>50 megs!) and the amount of libs read in for the compile (not counting the gcc and friends themselves), there is no way anything could be cached from the disk, between two consecutive compiles. I've compiled the linux kernel myself more than 200 times at least and I have never noticed any compile time changes from one compile to the next. I doubt that this is the explanation, but something else could be. TG

To: bruce rogers who wrote (27061)	1/31/2001 11:52:34 PM
From: L. Adam Latham	Read Replies (1) \| Respond to of 275872

bruce: Re: I'm pretty sure what happened is that the first run all the files were on disk, and part of the compile time was disk access. Immediately after that, he timed the 2 thread version, and all the files were read out of the cache. He should have run the first benchmark twice to check for that. When benchmarking, it's SOP to reboot the system between runs. So there shouldn't be an issue with data left in any caches, if the guy was testing correctly. Adam