🚀 go-pugleaf

In article <3560@cit-vax.Caltech.Edu> newton@cit-vax.Caltech.Edu (Mike Newton) writes:

> Hi --
> ... 
> Probably like a lot of Mac II buyers, when I saw the latest issue of Byte,
> I was very disappointed.  The article causing this disapointment was the
> one comparing the Mac II vs. the 80386 based PS2/80. 

I, too, have read the byte benchmark articles, and am of the opinion that
the Byte people are biased towards the 386.  I guess that's to be expected;
since they have a history of belittling the 68k (remember the 68k special
issue that was SUPPOSED to be a separate issue?  Or how about the IBM Piece
of Crap special issue that comes out every year?)

Anyway, here is what I find hard to swallow about the two articles I've
seen (Mac SE/68020 acc. board vs. a Compaq 386, and Mac II against Piece
of Shit 2/80 [that's a lot of shit! :-]):

	First, the article cautions that the benchmarks test compilers
as well as the hardware.  But their cover screams: Benchmarking the 386
and the 020!  If I were totally unfamiliar with microprocessors, or if
I simply looked at the table of results without reading the article, I
would have concluded that the 386 beats the 020 hands down, and run out
to buy a Compaq the next day.

	Next, note how sly they are.  They claim that the code
has not been optimized for any processor, and they have not used
register variables.  The reason was that doing so would not be fair to
any particular processor.  But in not using register variables, are they
not actually putting the 020 at a disadvantage?  Would the fact that 
the 386 has only 2 (two! despite Intel claims otherwise) general purpose
registers and the 68k has 8D+7A=15 general purpose regs have made a
difference?  Why the hell did the 68k designers put those regs there?
So they can be not used for benchmarks?

	I also question their using such a strange configuration (a
Mac SE with an accelerator board) for comparison.  The Compaq is the
top of the line 386 machine available today, so why not get a top of
the line 68020 machine?  Why not a Sun/3, Apollo, or even an NCR Tower!
Never mind the cost difference, if you want to compare processors,
compare processors. (I hope Mac fans don't feel too bad about this.)

	There are other subtle things that people may not notice. E.g.
the benchmarks were compiled using MacC from Consulair (I believe.  I'm
thinking of the first article.)  I don't know how that compiler works,
but if it is half decent, it would produce a double-clickable appl. and
print the results in a window.  Now, if they started timing at the double
click, they would have timed the initialization of ROM and the creation
of a window before getting to the benchmark itself.  I doubt they are
that stupid, but you never know.  Or how about the fact that the 68k in
the Mac has stop whatever it's doing and read out the screen buffer 
60 times a second.  On the Compaq they probably did something like:
	C>sieve
	  10000000 primes
	C>
(They sure know how to exaggerate, don't they?) The point is, due to
its inherent operating mode, the Mac (and almost all 68k based machines)
has to take care of many other things (mostly maintaining the graphics
on the screen) while running a benchmark.  The 386 does not.  It doesn't
have to, it can't even handle graphics.

	After degrading the 68k to their hearts content, the benchmarkers
sit back and inform us the the only conclusion that can be drawn from
their results is that the Compaq runs these benchmarks faster than the
Mac SE with a 020 accelerator.  They had to say that, because they know
those 386 machines aren't good for anything else.  Intel probably built
them so the can give 10000000 primes on a sieve benchmark.

	You can probably tell that I'm eagerly awaiting Byte's next
enlightening article with a critical and objective analysis of the 68k
and the 386, in which they will probably match the PS2/80 against a
Mac 128K, because its only fair to do such a comparision, in order to avoid
being unfair to any particular processor.  In the mean time, I will
go play Uninvited on the Mac.

(This article was written without the Byte articles for reference.  I only
used my memory, so there may be factual inaccuracies.  I deeply regret
any such errors.  I also disclaim any responsibility for them.)

Also, why don't one of you technical fellows out there who, unlike me, really
knows what he is talking about write a fuming letter to Byte and blast
the shit out of them?

-Rob

------------------------------------------------------------------------
Robert Hsu		  DISCLAIMER: I disclaim any responsibility for 
rhsu@topaz.rutgers.edu 	  inaccuracies, misinformation, and fabrications
RPO 6768  CN 5063	  that appeared in the preceding article.
New Brunswick, NJ 08903   {...!rutgers!topaz.rutgers.edu!rhsu}
------------------------------------------------------------------------
"Vidi, Vici, Veni"					"Coito ergo sum"
-- 
------------------------------------------------------------------------
Robert Hsu		  DISCLAIMER: I disclaim any responsibility for 
rhsu@topaz.rutgers.edu 	  inaccuracies, misinformation, and fabrications
RPO 6768  CN 5063	  that appeared in the preceding article.
New Brunswick, NJ 08903
------------------------------------------------------------------------
"Vidi, Vici, Veni"					"Coito ergo sum"