joe@petsd.UUCP (Joe Orost) (01/05/90)
I have seen lots of benchmark figures that say that RISC machines
can go real fast, but how about the code size? Is the old notion
that the code on a RISC will be about twice the size of that on a
CISC true? Does anyone have information on this subject, especially
for large programs?
regards,
joe
--
Full-Name: Joseph M. Orost
UUCP: rutgers!petsd!joe
ARPA: petsd!joe@RUTGERS.EDU, joe@PETSD.CCUR.COM
Phone: (201) 758-7284
US Mail: MS 322; Concurrent Computer Corporation; 106 Apple St
Tinton Falls, NJ 07724tim@nucleus.amd.com (Tim Olson) (01/05/90)
In article <1734@petsd.UUCP> joe@petsd.UUCP (Joseph M. Orost) writes: | I have seen lots of benchmark figures that say that RISC machines | can go real fast, but how about the code size? Is the old notion | that the code on a RISC will be about twice the size of that on a | CISC true? Does anyone have information on this subject, especially | for large programs? This has been discussed here, before, but this is typically what we see: 68020 .text Am29000 .text Program (Sun 3/260) MetaWare C ratio ----------------------------------------------------- compress 6600 8792 1.33 dhrystone 1.1 1608 1892 1.17 dhrystone 2.0 2984 3056 1.02 diff 10448 14492 1.39 grep 2640 4288 1.62 nroff 35328 59708 1.69 sipasm 52032 71528 1.37 stanford 9064 9752 1.08 ------------------------------------------------------------ 120704 173508 1.44 -- Tim Olson Advanced Micro Devices (tim@amd.com)
kmont@hpindda.HP.COM (Kevin Montgomery) (01/06/90)
Gee, I'd heard numbers like 30% larger. There are probably ways to even get this number down a bit... -k
igp@torch.co.uk (Ian Phillipps) (01/12/90)
joe@petsd.UUCP (Joe Orost) writes: >I have seen lots of benchmark figures that say that RISC machines >can go real fast, but how about the code size? In my experience, ratio of sparc size to 68K is about 1.25 to 1.3 (estimate)
joe@petsd.UUCP (Joe Orost) (01/18/90)
In article <1734@petsd.UUCP> I wrote: >I have seen lots of benchmark figures that say that RISC machines >can go real fast, but how about the code size? Is the old notion >that the code on a RISC will be about twice the size of that on a >CISC true? Does anyone have information on this subject, especially >for large programs? Here is a summary of the responses I received. The average seems to be about 40% larger. ----------------------------------------------------- From: psuvax1.cs.psu.edu!schwartz Organization: Penn State University Computer Science Yes they are bigger, but only by a little... in real programs it basically doesn't matter at all, and gets swamped by other factors. For example, GNU emacs on a Sun4 (Sparc) is about 1.6M, and is 1.3M on a Sun3 (68000). (There is a lot of data in there... the code segment is actually bigger on the Sun3 version I'm using, which may mean that one version got optimized and the other didn't, or something.) To take another example, Perl is about 200K (sun3) verses 230K (sun4). That's a small price to pay for 3 or 4 times the performance. -- Scott Schwartz ----------------------------------------------------- From: wimsey.bc.ca!seac!jtc Organization: SEAC Software Engineering, Vancouver, B.C. RISC executables are larger than CISC, but I don't think that the factor of two is accurate. For example emacs on the MIPS R2000 is about 750K while it is about 590K on the intel 80386. -- J.T. Conklin jtc@wimsey.bc.ca, ...!{van-bc, uunet, ubc-cs}!wimsey.bc.ca!jtc ----------------------------------------------------- This has been discussed here, before, but this is typically what we see: 68020 .text Am29000 .text Program (Sun 3/260) MetaWare C ratio ----------------------------------------------------- compress 6600 8792 1.33 dhrystone 1.1 1608 1892 1.17 dhrystone 2.0 2984 3056 1.02 diff 10448 14492 1.39 grep 2640 4288 1.62 nroff 35328 59708 1.69 sipasm 52032 71528 1.37 stanford 9064 9752 1.08 ------------------------------------------------------------ 120704 173508 1.44 -- Tim Olson Advanced Micro Devices (tim@amd.com) ----------------------------------------------------- Gee, I'd heard numbers like 30% larger. There are probably ways to even get this number down a bit... -k ----------------------------------------------------- From: june.cs.washington.edu!noah We found that the Ultrix kernel on our DECStation 3100s is almost three times bigger than on our MicroVAX IIIs. ----------------------------------------------------- regards, joe -- Full-Name: Joseph M. Orost UUCP: rutgers!petsd!joe ARPA: petsd!joe@RUTGERS.EDU, joe@PETSD.CCUR.COM Phone: (201) 758-7284 US Mail: MS 322; Concurrent Computer Corporation; 106 Apple St Tinton Falls, NJ 07724
chris@mimsy.umd.edu (Chris Torek) (01/19/90)
In article <1747@petsd.UUCP> joe@petsd.UUCP (Joe Orost) quotes june.cs.washington.edu!noah: >We found that the Ultrix kernel on our DECStation 3100s is almost three >times bigger than on our MicroVAX IIIs. On my 3100 the kernel is ~1 MB. The Ultrix kernel on cmvax (a 6210 here) is also ~1 MB. The 6210 kernel is compiled with larger tables; a smaller machine might have a .8 or .9 MB Ultrix kernel. Do not be fooled by `ls -l /vmunix': the MIPS binaries have an incredible amount of data stored in symbol tables, for debugging. (Among other things, the MIPS does not use a frame pointer, so in order to do stack tracing, the symbol table includes a `virtual frame pointer' as an offset from the stack pointer, along with `virtual register save masks' so that the debugger can figure out which registers to `restore' when moving up through the call stack.) The Ultrix kernel is ~1 MB mainly through sloppiness: I rewrote one driver (the QDSS driver), maintaining complete backwards compatibility, and cut it down to about 1/3 its original compiled size. Most of the code is not that bad, but I would guess that it could be reduced at least 30% by rewrites. (But which would DEC rather have: a `same' kernel, with the bugs moved around a bit, that was 30% smaller, or a `more functional' kernel, with new bugs, that was larger? Smaller does not sell well. VMS compatibility sells.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@cs.umd.edu Path: uunet!mimsy!chris