Path: utzoo!attcan!uunet!parcplace!khaw
From: khaw@parcplace.com (Mike Khaw)
Newsgroups: comp.lang.eiffel
Subject: Re: Benchmark article - Eiffel vs. C++ vs. Smalltalk-80
Keywords: benchmark, Eiffel, C++, performance
Message-ID: <681@parcplace.com>
Date: 26 Mar 90 19:13:27 GMT
References: <274@eiffel.UUCP>
Organization: ParcPlace Systems, Mt. View, CA
Lines: 64

I'm posting this for Peter Deutsch, ParcPlace Systems' Chief Scientist:

----------

In <274@eiffel.UUCP> of comp.lang.eiffel, Kim and Roxanna Rochat of ISE
(formerly Tektronix) posted some numbers regarding the performance of a
simple integer and array manipulation program in C++, Eiffel, and
Smalltalk-80.  They point out that the choice of C compiler can have as
much as a 30% influence on the measured time for the Eiffel
implementation.  Taking their observation to heart, I measured the
performance of their program on a different Smalltalk-80
implementation: Objectworks for Smalltalk-80, version 2.5, from
ParcPlace Systems.  I used the same hardware (diskless Sun-3/60 with 12
Mb of RAM, running SunOS 4.0.3) as they reported.  The result was:

Sun     Smalltalk  Ow/ST-80,v2.5                240

[Just to confirm that our numbers are comparable to those posted by
the Rochats, I compiled mosaic.c using ATT's 2.0 C++ cfront and Sun's
cc, with "-O -Bstatic" flags, and matched their 41 sec. time on the
same machine that we ran the Smalltalk version on. -- Mike Khaw]

This is approximately a factor of 6 slower than the fastest, and a
factor of about 4 slower than the slowest, of the C++ and Eiffel
results, and a factor of about 12 faster than the Tek Smalltalk figure
(correcting for the roughly 25% difference in machine speed).  Not bad
for a language that is often (inaccurately) slandered as being
"interpretive" and too slow to use for real work.

After reading Andrew Koenig's posting, it seemed reasonable to us that if
he could modify the program in ways that any reasonably experienced C++
programmer would, we could modify it in ways that a reasonably experienced
Smalltalk programmer would.  Most of the time goes into the random number
calculation, and most of that time goes into the floating point arithmetic,
which is very slow in Smalltalk.  So we modified the program by adding a
new message to Random that returns a random boolean, avoiding the floating
point.  We replaced the two uses of 'Rand next < 0.5' in the Mosaic program
by 'Rand nextBoolean'.  Here is the new method, and the revised timing
results:

	Random methodsFor: 'accessing'

		nextBoolean
			"Answer the next random Boolean."

			^self step < (modulus bitShift: -1)

This change cut the measured time from 240 seconds to 175.

Some may argue that adding code to a library class is not a legitimate way
to improve the performance of a program.  We take the view that given the
"all source code available" culture promoted by the Smalltalk-80 system,
adding methods to library classes is natural and appropriate; we believe
that extending this culture to other languages would benefit the user
community greatly.

I would like to thank the authors for posting their test code in the
article.

----------
-- 
Mike Khaw
ParcPlace Systems, Inc., 1550 Plymouth St., Mountain View, CA 94043
Domain=khaw@parcplace.com, UUCP=...!{uunet,sun,decwrl}!parcplace!khaw