Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!sun-barr!decwrl!atha!rwa
From: rwa@cs.AthabascaU.CA (Ross Alexander)
Newsgroups: comp.os.minix
Subject: Re: Dhrystone 2.1 sample run
Message-ID: <1146@atha.AthabascaU.CA>
Date: 8 Oct 89 21:47:51 GMT
References: <24988@louie.udel.EDU> <2457@ucsfcca.ucsf.edu> <3545@ast.cs.vu.nl> <2470@ucsfcca.ucsf.edu> <2472@ucsfcca.ucsf.edu> <3593@ast.cs.vu.nl>
Organization: Athabasca University
Lines: 31

ast@cs.vu.nl (Andy Tanenbaum) writes:
[...]
>>Since the output of Dhrystone 2.1 is considerably different from the
>>old version, here is a sample run.
>I tried it and it seemed to work on the Sun at least.  I'll try MINIX
>later.  
[...]
>I think the interface of the first dhrystone version that simply printed
>the answer is much nicer.  Any objections if I delete all the garbage in
>the MINIX version?

Well, at least do exception checking (I know, that's obvious, but
worth mentioning not for your edification but others').  But I agree
most of the stuff coming out of Dhry 2.1 is noise.  The number,
however, is quite a bit better as a test of compiler+hardware
performance.  You need a fairly clever optimizer to defeat some of the
deliberate obstructionism of the code ;-).

	Ross

ps, and on a _completely_ different subject: The fs switch is a fine
idea but not for supporting lazy 1.x --> 2.x minix conversions.  This
weekend I and 2 other staff converted a 1,300 MByte Vax from Ultrix
1.2 to 2.3, in the process changing the partitions around and entirely
rebuilding all the filesystems.  The I/O time was as nothing compared
to the thinking time required.  And this was using dinky little 2400
foot 6250 bpi tapes - we needed a dozen plus some for scratch.  I have
limited sympathy for the "it'll take too much effort to dump/restore"
crowd.

	r