Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!ll-xn!ames!oliveb!sun!vatican!pope
From: pope@vatican.Sun.COM (John Pope)
Newsgroups: comp.arch
Subject: Re: RISC bashing at USENIX
Summary: use bcopy()
Message-ID: <59798@sun.uucp>
Date: 14 Jul 88 03:41:32 GMT
References: <6965@ico.ISC.COM> <936@garth.UUCP> <202@baka.stan.UUCP>
Sender: news@sun.uucp
Reply-To: pope@sun.UUCP (John Pope)
Organization: Sun Microsystems, Mountain View
Lines: 45

In article <202@baka.stan.UUCP> stan!landru@boulder.edu writes:
>
>When I first brought up X on our color sun 4/260, recently converted from
>a sun 3/260, I was amazed that the X server performance for simple things
>like scrolling and moving windows around was no better.
> [...]
>The loop which does most of the work for a bit blt looks like this for the
>common copy case:
>
>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.

>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...

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

John Pope
	Sun Microsystems, Inc. 
		pope@sun.COM

John Pope
	Sun Microsystems, Inc. 
		pope@sun.COM