Need 286 "C" benchmark

Gordon Letwin gordonl at microsoft.UUCP
Mon May 20 11:20:52 AEST 1985


I just love the contact sport of "combative benchmarking".  I note how
the source code for the Hofstader (sp?) benchmark just accidentally
happens to declare its register variables from the least-used to the
most used, the opposite of normal C convention.  And by coincidence,
there are three of those little hummers... and we're comparing a
68K with >3 regvars against a 286 with only 2!
This means that the single most heavily used register variable will
be in a reg on the 68K and on the frame for a 286.  My my, what a
terrible accident.

Those who assume that I'm somehow "defending" the 286 architecture should
practice their reasoning, logic, and debate a bit more.  My points are
simple, and two-fold:

	1) Many or most of these benchmarks are done with folks with
	   an axe to grind.  There are very clever ways to grind axes.
	   This is an equal-oportunity sport: I've seen
	   some very "clever" and highly misleading benchmarks
	   perpetrated by all the majors.

	2) None of this has any meaning, within the realm of the religious
	   battle being fought here.  There is no tricky little benchmark
	   that will cause IBM to drop the 286.  There is no tricky little
	   benchmark that will cause SUN to drop the 68K, etc.  By definition,
	   if there is someone who might choose their machine on the
	   basis of such benchmarks, that company is very late and will
	   have a very small impact on the world.  Machine performance
	   as a religion - convince the other guy you're right using all
	   means, fair and foul - is a dead issue.  Machine performance
	   as a science - don't decree what's right, FIND OUT what's
	   right - could still be of interest, from a theoretical standpoint.
	   I've seen very little of this on the net, though.

gordon letwin
microsoft

personal opinions, of course, not company.  MS doesn't "like" or "dislike"
chips, we just work with 'em, for good or bad, always some of each.
	   



More information about the Comp.lang.c mailing list