Path: utzoo!attcan!uunet!husc6!think!ames!oliveb!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: m88000 benchmarks (and C vs ASM)
Message-ID: <2434@winchester.mips.COM>
Date: 17 Jun 88 21:37:14 GMT
References: <1941@pt.cs.cmu.edu> <3208@ubc-cs.UUCP> <12112@ut-sally.UUCP> <23406@bu-cs.BU.EDU>
Reply-To: mash@winchester.UUCP (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 63

In article <23406@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes:

>>Gosh!  Does this mean that careful hand-coding can yield a factor of 2
>>faster code even on a RISC machine?  I know it means that on a CISC machine
>>because I've done better than that myself. (Current record: a factor of 22
>>on a Nova computer, me vs. Fortran, with the sieve benchmark).

1) Remember that by now we have a whole collection of things labeled
RISC machines, whose architectures varied quite a lot.

2) At least one flavor of RISC design style [i.e., as practiced by,
at least, IBM, HP, and MIPS] selects instructions and features as seen
in their effects upon compiled code, using optimizing compiler statistics
to drive the design, i.e., the COMPILERS EXIST (at least substantially)
BEFORE THE INSTRUCTION SET ARCHITECTURE.

>>But where does this leave all the CS statements that assembly-language
>>coding is no longer needed?  Are factors of 2 really unimportant?
>
>Um, Ed, before you jump (or is that JRST) to all sorts of conclusions
>note that the 88000 is a very new architecture, I doubt they have the
>compilers up to snuff yet nor would be disappointed if they were still
>working on it.

>It might be interesting to see what the case is on RISC systems with
>more mature compilers (which generally means "working for a year
>now".)
>
>	-Barry Shein, Boston University

3) Just because something is labeled a RISC doesn't mean that even a
good compiler can always do almost as well as assembler; it depends on:
	a) Was the instruction set REALLY designed from compilation
	statistics?
	b) What is the current state of the compilers? (see Barry's note)
	c) Who's writing the asembler code? 
For example, if a) is true, and the compilers are good, then c) matters a
little less, i.e., the oppurtunities for usefully writing assembler
go down.  As an example, now that we have experience of several years
in running systems:
	a) We wrote low-level interrupt code, block-copy, machine-dependent
	code (like tlb-flushing), and floating-point-emulation code
	in assembler.
	b) We wrote heavily-tuned math libraries in assembler.
	c) We wrote a couple of the C string routines in assembler.
	(actually, at one point, I wrote ALL of the string routines in
	assembler, but the compiled C code was close enough that I threw
	away most of the assmebler routines in disgust at the time I'd wasted.)
As another example, in our case FORTRAN Linpack and Coded Linpack are usually
within 10%.

There is almost always some use for assembler.  From past experience, I'd
say that compiler-driven RISC designs + good compilers reduce the
temptation considerably.

Since this started with 88000 numbers, does anybody have any Double
Precision 88000 numbers (like FORTRAN Linpack, or DP Doduc, or Spice)?
The only DP number I've seen is DP Whetstones @ around 3Mwhets.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
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