Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!ptsfa!ihnp4!homxb!mtuxo!mtune!codas!usfvax2!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.sys.m68k,comp.lang.forth
Subject: Re: Forth Inc 68020/80386 benchmark.
Message-ID: <1816@pdn.UUCP>
Date: Mon, 23-Nov-87 10:40:43 EST
Article-I.D.: pdn.1816
Posted: Mon Nov 23 10:40:43 1987
Date-Received: Thu, 26-Nov-87 21:37:44 EST
References: <970@sugar.UUCP> <1289@nrcvax.UUCP> <1087@ucsfcca.ucsf.edu>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 24
Xref: mnetor comp.sys.m68k:661 comp.lang.forth:240

In article <1087@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Computer Center) writes:
/Are we supposed to take seriously the suggestion the Forth would
/not optimize the most critical part of their system for each
/processor? Remember that Forth lets you get down to specifying
/the actual machine instructions for critical code as was probably
/done here so these results presumably give a better measure
/of the chip performance than the typical C or Fortran program
/which is dominated by compiler quality.

Except that most benchmarks I've seen that were done in hand-coded
assembly show that the the 68020 averages about twice the speed of the
80386 using slow memory, and about 30% faster using fast memory.  The
best such benchmark is the one done by Sperry corporation using the
EDN benchmark suite.

There is also the question of the "equivalence" of the bus and memory 
systems in which the two processors were tested, and what sort of
memory management hardware (if any) was used with the 68020 (MMU's 
can slow it down significantly).

Besides, attempts at "optimization" are not guaranteed to be successful (or
equally successful on all systems).

--alan@pdn