Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!tut.cis.ohio-state.edu!accelerator.eng.ohio-state.edu!baloo.eng.ohio-state.edu!mills
From: mills@baloo.eng.ohio-state.edu (Christopher Mills)
Newsgroups: comp.misc
Subject: Re: R.I.P. BYTE:  Open Letter to The Editor
Keywords: BYTE, subscription, letter, fed up, Small C, Benchmarks
Message-ID: <429@accelerator.eng.ohio-state.edu>
Date: 2 Aug 88 20:57:57 GMT
References: <6646@well.UUCP> <5479@ecsvax.uncecs.edu> <717@mcrware.UUCP>
Sender: news@accelerator.eng.ohio-state.edu
Reply-To: mills@baloo.eng.ohio-state.edu (Christopher Mills)
Organization: Ohio State Univ, College of Engineering
Lines: 51

In article <717@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes:
>
>They do run a certain amount of Mac-oriented articles, but I really think that
>their main bias is toward IBM/Intel.  When the new ballyhooed BYTE benchmarks
>show times for the infamous sieve program such that my CoCo 3, with its 1.8 MHz
>6809, can run the sieve faster than all the 680x0 computers BYTE lists but the
>Mac II, I am driven to the conclusion that their 68K Small C compiler has to
>be truly horrible.  What is the reason for this?  I don't know, but the al-
>ternatives that come to mind don't speak well for BYTE.
>
>		James Jones
>

	Well, Small C is not horrible, as long as you run it on an 8085.

	I would imagine that all they did is change the code generation
sections.  This is a real drag for the 680x0, because the Small C compiler
assumes two general-purpose registers (HL and DE on the 8085).
The 680x0 has 16 registers, 8 address and 8 data, so I imagine there is a
lot of unneccessarry stack movement and register motion going on.  The
680x0 is at its best only when you keep lots of operands in registers.
Not to mention all the neet 680x0 addressing modes that aren't being used.
They also used int == 32 bits, which roughly doubles the time on the 68000
(I believe the 8086 version used 16-bit ints).  I don't know that much
about the 80x86 architecture, but I would imagine it maps onto the 8085
much better than the 680x0 does...

	Anyone out there actually download the code of the thing (Small
C 68K) and look at it?  I'd be curious know what they did.

	My home-brew C-like language (STAPL), which has less optimizations
than Small C (I've got to write that peephole optimiser some day...)
did the same benchmark on my Amiga FASTER than the Mac-II did it with
Small C.  What a crock!

	I can't imagine how they thought that using Small C would make
the benchmarks fair.  I don't want to know how fast a Mac II or PS/2
can execute bad code.  Let them use the best compiler they can find.

				Oh, well - back to my thesis...

_________________________________________________________________________
| Christopher Mills              | "There are lies, damn lies, and      |
| mills@baloo.eng.ohio-state.edu |          benchmarks."                |
====== My thoughts are not my own--I'm posessed by mailer daemons. ======


-=-

_________________________________________________________________________
| Christopher Mills              | "If you see someone without a smile, |
| mills@baloo.eng.ohio-state.edu |  give them mine - I'm not using it." |