Xref: utzoo comp.arch:8662 comp.sys.intel:740 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!vsi1!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch,comp.sys.intel Subject: Re: i860 overview (long) Message-ID: <14855@winchester.mips.COM> Date: 8 Mar 89 05:29:50 GMT References: <807@microsoft.UUCP> <92634@sun.uucp> <13322@steinmetz.ge.com> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 30 In article <13322@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >One problem with any chip which requires alligned data is that >performance suffers when addressing bytes, to the point that a program >may become impractical. One of the people here checked his Sun-30 >(68020) against his Sun-4 (SPARC). The three ran troff about 5x faster. >This doesn't mean RISC is bad in a workstation, but it can have >performance problems in software we take for granted. > >A question: has anyone benchmarked nroff/troff on the VAXstation 3100 >(VAX) and DECstation 3100 (MIPS)? Would some of the MIPS readers like to >comment on performance in this area vs. 68020 or 80386? Something's wrong somewhere: I'd expect a Sun4/200 to be 2X or so faster than a Sun3/200; I've never seen anything where a Sun-3 would be 5X faster. The MIPS-based things run them at the rates you'd expect; there's an nroff benchmark that's been in the Performance Brief forever; and it also has Sun3/4 numbers. I do NOT think there's a penalty for addressing bytes: both of these machines have full support for storing and [signed/unsigned] loading bytes. There is a penalty for accessing unaligned words, in both cases, although R2000s have special instructions to mitigate the penalty. Anyway, please get your friend to supply some data, because it sounds wrong. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086