Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!mit-eddie!genrad!decvax!minow
From: minow@decvax.UUCP (Martin Minow)
Newsgroups: comp.sys.atari.st
Subject: Re: Mark Williams C 2.0 benchmark
Message-ID: <75@decvax.UUCP>
Date: Wed, 13-May-87 19:01:32 EDT
Article-I.D.: decvax.75
Posted: Wed May 13 19:01:32 1987
Date-Received: Sat, 16-May-87 07:01:24 EDT
References: <136@xrxns.UUCP> <322@transys.UUCP> <942@batcomputer.tn.cornell.edu> <68@decvax.UUCP> <995@batcomputer.tn.cornell.edu>
Reply-To: minow@decvax.UUCP (Martin Minow)
Organization: Digital Eq. Corp. - Merrimack NH.
Lines: 27

In article <995@batcomputer.tn.cornell.edu>, Moshe Braner, compares
the performance of Megamax and MWC:
>...
>Timings (in seconds):
>...
>	 61	total
>
>Compare with about 220 for MWC compiling a smaller program, as posted.

Moshe noted that everything was kept in RAM.  Persons comparing the
performance of the two systems should note that my timings for MWC
kept sources, objects, #include files, some libraries, and the output
.prg on floppy disk.  Also, I built the program using make, which
would have affected the performance somewhat.  After juggling my
ramdisk a bit, I tried compiling Dumas' UUDECODE.C (5861 bytes) with
everything (source, include, and libraries) in ramdisk.  The total
compile->.prg took 25 seconds.

While it's always fun to play "my computer's faster than your
computer," there are other more important points to note: the
quality of the code, and the accuracy of the translation.  At
times, I've noted that some I/O libraries are very small and fast,
but don't quite handle all the strange error cases.  So, unless
things are *very* far apart, you shouldn't put much weight on raw speed.

Martin Minow
decvax!minow