Re: commstime not scaling

[Alan Grover <alan.grover@xxxxxxxxx>]

Thanks for all your responses!

Tom pointed out in a private thread that I got the units wrong for the python commstime.  Should be microseconds, not milliseconds. (It is wretched, but not *that* wretched.  :o)


Sorry for confusion about paging: I had disabled some services on the slow machine to prevent paging during other uses, and I mentioned that only because I think it helped lead to the slow machine beating the fast one.  It was *not* paging during the test.

I have a small (2k) psudeo-commstime (4 classes that have similar roles
to the processes in the commstime benchmark, the idea being to see how
much overhead there is for parallel vs single-threaded code) that
scales almost perfectly with CPU speed on these two machines.  It is
not unreasonable to think that the whole thing can fit in cache.  It
uses the same wall-clock method as the kroc commstime, and neither of
them seem affected (more than a couple of percent) by top (which might
serve as a reasonable model of many of the background processes). 
Since none of the commstime benchmarks print in the loop being timed,
that doesn't seem to be a factor either.

Something I should have checked earlier: both machines have 256 KB L2 cache, and the commstime binary is over 300k.  It seems reasonable that if most of that binary is needed for each loop the chances of caching everything needed for the loop are small, and so it is not suprising that slow main memory times become the dominating factor in each loop.

Once that happens, the situation is exactly as Eric describes: complicated, because of the many small variations possible in memory and memory bus performance.

Naturally, this severely limits the usefulness of the psudeo-commstime...  :o)

Thanks again for all of your comments.

Alan