[net.micro.amiga] drystones

fnf@unisoft.UUCP (12/21/85)

In article <409@aum.UUCP> freed@aum.UUCP (Erik Freed) writes:
>how do you explain the much better drystone results of the ST?
>(the compiler can not be the only thing responsible)
>

Don't be so sure.  I have seen a beta test version of a compiler
I can't name yet that gives the following results:


				Lattice		"Brand-X"

	with registers		459		1041
	without registers	454		980
	with reg, file size	15680		5648
	without reg, file size	15724		5808
	boink + dry (regs)	112		236
	robocity + dry (regs)	184		403


The file size differences may be due to symbol table sizes or some other
factor.  I didn't investigate.

The "boink + dry" results is with boink running in the top half of the screen
and a cli window in the bottom.  There was no perceptable degradation in 
either the sound or speed of the ball.

The "robocity + dry" was with robocity running in the bottom half of the 
screen and a cli window in the top.  Note that under these conditions
"brand-x" gave almost the same drystone results as the lattice version with
nothing else running!.

One interesting result is that boink is apparently much more of a CPU
hog than robocity.

-Fred

===========================================================================
Fred Fish    UniSoft Systems Inc, 739 Allston Way, Berkeley, CA  94710  USA
{ucbvax,dual}!unisoft!fnf	(415) 644 1230 		TWX 11 910 366-2145
===========================================================================

freed@aum.UUCP (Erik Freed) (12/22/85)

 [stuff about compiler being responsible for bad drystone performance]

> Don't be so sure.  I have seen a beta test version of a compiler
> I can't name yet that gives the following results:
> 				Lattice		"Brand-X"
> 
> 	with registers		459		1041
> 	without registers	454		980
> 	with reg, file size	15680		5648
> 	without reg, file size	15724		5808
> 	boink + dry (regs)	112		236
> 	robocity + dry (regs)	184		403

That lattice compiler must really be awful. The 68000 is not exactly the
most awful architecture to deal with... I stand corrected. This seems to prove
that the hardware is not at fault. Just goes to show that the compiler writers
of america are an uneven bunch and can make or break a product. How did Atari
luck out an get such a seemingly good one right off the bat? (You Amiga owners
must be drooling to get this one)
-- 
-------------------------------------------------------------------------------
                           Erik James Freed
			   Aurora Systems
			   San Francisco, CA
			   {dual,ptsfa}!aum!freed