Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ames!ncar!boulder!stan!landru
From: landru@stan.UUCP (Mike Rosenlof)
Newsgroups: comp.arch
Subject: Re: RISC bashing at USENIX
Message-ID: <204@baka.stan.UUCP>
Date: 14 Jul 88 16:36:07 GMT
References: <6965@ico.ISC.COM> <936@garth.UUCP> <202@baka.stan.UUCP> <59798@sun.uucp>
Reply-To: stan!landru@boulder.edu
Distribution: na
Organization: SAE Inc., Longmont, Colorado
Lines: 45

In article <59798@sun.uucp> pope@sun.UUCP (John Pope) writes:
>>register long count;
>>register long *src, *dst;
           ^^^^
>>   while( --count )
>>   {
>>      *dst++ = *src++;
>>   }
>*** Warning! Brain damaged software alert! ***
>This should be re-coded to use the bcopy() library routine, which
>does a 32 bit copy instead of a byte at a time. You should see a
>*noticable* improvement. Moral: use your libraries, that's what they're 
>there for.

Last time I looked, 'long' on the sun C compilers was 32 bits, and this
example still holds.  If the library function is optimized C or hand
coded assembler, the machine code is going to come up nearly identical
to my examples. (assembler for 68020 and SPARC not quoted here)

>>My point is that with a reduced instruction set, you're very likely to
>>find some applications that are slowed down by this reduction.  In this
>>case, I find that the sun 4/260 makes a very nice compile or compute
>>server, but it's not a very impressive X server.
>
>Please be careful about making conclusions like this regarding a
>particular machine or architecture. Performance is a combination of a
>lot of factors, most of them not as clear-cut as this case is...


I think I was clear that this is a very specific example, and that in
other areas its performance is "very nice".  I don't know of many
machines that spend large portions of CPU cycles just doing bit blt
(or bcopy).  In this isolated case, SPARC ( or at least this implementation
by Fujitsu ) is not impressive, especially when comparing costs to a
68020 system.  This is one of the difficulties of very simple graphics
like this, lots of data has to be moved around.  One more compute
intensive functions like shaded surfaces, I'm sure the sun/4 would be
a tremendous improvement.


-- 
Mike Rosenlof		SAE			(303)447-2861
2190 Miller Drive			stan!landru@boulder.edu
Longmont Colorado			landru@stan.uucp
80501					...hao!boulder!stan!landru