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: jcholewa who wrote (27047)	1/31/2001 7:47:55 PM
From: TechieGuy-alt	Read Replies (2) \| Respond to of 275872

I should point out that the fact that the total cache of the system is now 768KB instead of 384KB could easily account for a greater than linear performance increase. If I understand what you are implying (greater cache = lower miss rates etc.), then that is not true. Each processor still has 128+256K cache. The hit rate of each processor is still limited by its own cache size. I would guess that the performance improvement is from the lower total processor stalls as compared to a single Athlon processor system processor stalls * 2. This is of course due to better utilization of the memory bus (while one processor is crunching data the other is accessing the memory- which otherwise would have been sitting idle in a 1P system). TG

To: jcholewa who wrote (27047)	1/31/2001 9:51:45 PM
From: bruce rogers	Read Replies (3) \| Respond to of 275872

> Well, the meat of the article was that a single 266 DDR 1.2GHz Athlon compiled the kernel in 4min 51secs > and the dual system compiled it in 2 min 00 secs!, more than a 100% performance improvement. > (Normally one expects somewhat < 100% performance improvement). When you see a difference like this, either the single processor version was starved for resources, or something was different between the runs. When you run gcc in parallel, it simply compiles a separate .c file in each thread, so the resource allocation problem doesn't happen - unless the guy figured out some way to disable one cpu, and still run two compile threads. 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.