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