|> I have a problem. I am convinced that the memory bandwidth results
|> that alex@think.com sent me are bogus. The optimizer is obviously
|> removing all the work and so just a timer latency is being reported.
|> I am certain of this because Alex sent me the code that he used and the
|> MB/s rates do not include the factor of 100 that he put in to get a
|> timeable interval! If his timings are correct, then the bandwidth is
|> actually 160 times the machine maximum, rather than just the 1.6 times
|> faster that he reports.
I assume this is the same issue that I screwed up over in early November
or whenever. I remember you saying Alex reported bandwidth gt speedoflight then.
Obviously, a factor of 160 in excess, when he alleges a timer loop of 100,
smells like either the optimizer issue or just bad reporting ; i.e., he
didn't do the arithmetic right. Note on a MPP you can also screw up the
arithmetic easily be applying the number of processors wrong.
|>
|> The code that I have to outsmart the optimizer probably will not work
|> very well on a CM-2, since it involves doing some scalar stuff to
|> selected array elements to confuse the optimizer.
I never have much problem with the optimizer being too clever ...
|> ...I can prepare a test
|> code that does "real" work, and so cannot be optimized, but I need a
|> good estimate of the precision and latency of the clock. TMC would
|> probably also prefer that I run the test cases on a machine that is
|> less loaded than the CMNS machine -- the front ends there are pretty
|> busy, and will probably bias the results downward.
I did some mini-tests on a Sun4 of 25 MHz and a CM-2 at 8 MHz.
Results :
- cm_timer_start plus cm_timer_stop take around 5 msec
(this is presumably FE time)
- for:
do (n) times
a=a+1
enddo
do loop overhead around 0.5 msec on unoptimized code,
around 7 microseconds on optimized code.
This last is around the time you get out of the tables for a 64-bit add.
|> I would like to get this correction out soon. The people at CRI
|> are (quite reasonably) upset at the impossible number that I posted,
|> and I would like to set the record straight....
Give me a simple code and I'll run it for you. Have to be tomorrow, though.
I'm in Tlh now, typing away at a Zenith with all workstations down.
Email to this address as SCRI machines are down.
Daan Sandee sandee@think.com
Thinking Machines Corporation
Cambridge, Mass 02142
This archive was generated by hypermail 2b29 : Tue Apr 18 2000 - 05:23:02 CDT