🚀 go-pugleaf

In article <1992Aug13.125001.25563@bmw.mayo.edu>, agl@mayo.edu (Al Larson, 1-159 Med Sci, 4-4147) writes:
> In article 92Aug13120523@vulcan.essex.ac.uk, alien@essex.ac.uk ("Adrian F Clark") writes:
> >
> >In article <1992Aug10.221247.8016@cfa.harvard.edu> alberto@cfa.harvard.edu (Alberto Accomazzi) writes:
> >
> >
> >  dp = data;
> >  for (y = 0; y < ysize; y++)
> >    for (x = 0; x < xsize; x++)
> >      *dp++ = ...
> 
> ... If its speed your after, and who isn't.
> 
> dp = data;
> xy = ysize*xsize;
> while(xy--) *dp++ = ...

	That was true on some piece of gear that I benchmarked
	in the past -- maybe a 68K-based workstation -- but it pays
	to check your particular hardware & software.  On a Sun IPC
	tests based on the two code fragments below produced the
	results shown on the right in three trials (1 million iterations
	each of 3 similar loops):...

				Using cc:
i = MAX;			1.6u 0.4s 0:02 95% 0+1368k 0+0io 0pf+0w
while ( i-- )			1.6u 0.4s 0:02 95% 0+1368k 0+0io 0pf+0w
    *bp++ = *ap++;		1.6u 0.4s 0:02 96% 0+1376k 0+0io 0pf+0w

				Using gcc:
				1.5u 0.4s 0:01 101% 0+1400k 0+0io 0pf+0w
				1.4u 0.4s 0:01 98% 0+1400k 0+0io 0pf+0w
				1.4u 0.4s 0:01 100% 0+1400k 0+0io 0pf+0w

				Using cc:
for ( i=0; i < MAX; ++i )	1.3u 0.5s 0:02 76% 0+1340k 0+0io 10pf+0w
    *bp++ = *ap++;		1.2u 0.4s 0:01 100% 0+1316k 0+0io 0pf+0
				1.3u 0.4s 0:01 98% 0+1320k 0+0io 0pf+0w

				Using gcc:
				1.5u 0.5s 0:02 79% 0+1404k 0+0io 3pf+0w
				1.4u 0.4s 0:01 100% 0+1396k 0+0io 0pf+0w
				1.4u 0.5s 0:02 95% 0+1384k 0+0io 0pf+0w

	So finding the absolute optimum even on a single piece of
	hardware is an exercise in exploring both code and compiler.
	Allowing the compiler to change between versions, and adding
	the variable of different types of hardware, and it's not
	very practical to look for an absolutely optimal choice.


------------------
Paul Raveling
Raveling@Unify.com