Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!tektronix!tekcrl!tekchips!jans
From: jans@tekchips.TEK.COM (Jan Steinman)
Newsgroups: comp.sys.mac,comp.sys.ibm.pc,comp.sys.m68k,comp.sys.intel
Subject: Re: Re: 386 vs. '020, BYTE Benchmarks, Smalltalk
Message-ID: <1714@tekchips.TEK.COM>
Date: Mon, 21-Sep-87 13:03:05 EDT
Article-I.D.: tekchips.1714
Posted: Mon Sep 21 13:03:05 1987
Date-Received: Wed, 23-Sep-87 04:36:45 EDT
Organization: Tektronix Inc., Beaverton, Or.
Lines: 20
Xref: mnetor comp.sys.mac:7069 comp.sys.ibm.pc:8091 comp.sys.m68k:569 comp.sys.intel:353

<<<I will quote some figures from Byte magazine, July 1987 issue. I personally 
do not doubt the Intel benchmarks at all....>>>

<<<BYTE likes to do benchmarks using interpreted BASIC.  Very well, let's look 
at some benchmarks using an interpreted language:  Smalltalk...  Now, which 
architecture is faster?>>>

One problem with most benchmarks is that they are easily twisted to suit some 
purpose.  The Smalltalk Benchmarks are now considered invalid because one 
implementation caches compiled code.  This means that the first time a method 
is executed, it will run slower than a non-cached implementation, because it is 
doing extra stuff to store the native code.  On subsequent executions of the 
same method, however, the cached method will run at native code speed.

The Smalltalk Benchmarks are all tightly looped, causing cached implementations 
to show good results that are not necessarily reflected by user experience.

:::::: Software Productivity Technologies    ---    Smalltalk   Project ::::::
:::::: Jan Steinman N7JDB	Box 500, MS 50-470	(w)503/627-5881 ::::::
:::::: jans@tekcrl.TEK.COM	Beaverton, OR 97077	(h)503/657-7703 ::::::