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