Amiga 3000UX, X, OpenLook, Motif, Color, A2410, Etc. (somewhat long)

[James Seymour]

In article <EACHUS.91Mar20111051 at aries.mitre.org> eachus at aries.mitre.org (Robert I. Eachus) writes (in part):
>
>                                    ...  Actually the typical 386/486
>  has two things agenst it: Graphic speed (which can always be solved
>  by a $600 34010 board), and Microsoft.  ...
>                     ...  We can solve the Microsoft problem by not
>  using MS-DOS or OS/2...
>

Bzzzzzt.  Wrong.  Microsoft owns a fairly sizeable chunk of SCO unless I'm
sorely mistaken (has happened before tho).  Indeed, the SCO development
system is basically a port of the Microsoft C compiler package (and it
shows it).

Now, as to benchmarks programs...

>                                        ...  First, Dhrystone 1.1
>should not be used to benchmark anything.  ...
>
>                ...  Dhrystone 2.1 is much better ...

Huh.  May be, but is it any more worthwhile for gleaning anything of any
*real* usefulness?  I'm quickly coming to the opinion that it belongs in
the same category as your statement re: Dhrystone 1.1.  I'll explain why.

>In article <something_or_another> david at kessner.denver.co.us (David D. Kessner) writes (in part):
>>Argh.  Fine!  So mail me the Dhrystone 2.1 code.  Or better yet, the Specmark
>>program.  I'll test the machines and post the results.  I dont think that it'd
>>change things much, but I'll entertain the thought...
>>
>>Also, you missed the point of my message completely!  I'm saying that the 
>>Dhrystone numbers differed by SO MUCH that FURTHER INVESTIGATION IS REQUIRED!
>>And dont give me any "cleverness of the compiler writers" stuff since GCC and
>>the AT&T compiler were used on both machines with similar results.

>>In article <20073 at cbmvax.commodore.com> jesup at cbmvax.commodore.com (Randell Jesup) writes (in part):
>>>
>>>	Note that 80x86's are do better on dhrystone...  [etc...]

This *ought* to have pretty much said it all, but apparently not, so...

[flame on - donning fire-retardant suit]

David, you reply to Randall's statement with several statements that, in
light of previous articles and Randall's statement, I'm surprised at.  Among
them: "The only CONCLUSIVE evidence that the dhrystone has told us is that
the 386 can compute dhrystones faster than the 030 at the same clock speed."
That was bad enough, but then you had to go and say: " ... (assuming that
the 386 is significantly faster than the 030)  It is sad that a less-than-
optimum design [the 386] could be faster than a clener-better-designed cpu
[the 680x0].  I wondered why the 030 was slower, ..."

[Deep, disgusted sigh]

There is ample evidence that these "hobbyist" benchmark programs are, at
best, lots of fun to play with, but of questionable significance in the
real world.  This has been documented time and again in this thread and
elsewhere.  Evidence suggests these benchmark programs are of debatable
value for comparisons even on identical hardware platforms using
identical operating systems and compilers.  This from personal experience,
as follows:

I purchased the SAS/C development system several months ago.  To
familiarize myself with the compiler package and for grins, I got ahold of
several "popular" benchmark programs and played with them.  In turn, again
for grins, I ported this stuff to SCO Xenix, SCO UNIX, MS-DOS (a couple of
flavours on several hardware platforms), Motorola UNIX, and OS/2.  The
results were nonsensical, to say the least.  I'll give you examples of the
most glaring inconsistencies.

How about a disk performance benchmark that insisted that an ST-506 drive
with a 28ms average access time was *significantly* faster than an ESDI
drive with an access time of something like 20ms?  Identical binary,
identical releases of Xenix SysV, identical hardware platforms,  the data
sizes were large enough to defeat caching, it was tested when the systems
were not busy (as well as when they were - same results), and the
filesystems should have been roughly equally fragmented (I know, I know,
bad assumption - but there was *quite* a difference in the times - too
much to be blamed on fragmentation differences IMHO).

>From this I can assume that ST-506 systems are faster than ESDI systems?

Next, the whole series of benchmarks (dhry, floating-point, and disk
performance) were run on the SCO UNIX box as well.  Again, same hardware,
same binaries.  The benchmarks *insisted* that the UNIX system was faster
in all respects.  Yet users that used both the SCO UNIX and Xenix systems
on a regular basis had the very strong perception that the UNIX system
was much slower than the Xenix systems - no matter what you were doing
(i.e.: compiles that took much longer than previously, etc.).

Since it was a fairly comprehensive test suite, from this I guess I can
assume that SCO UNIX is faster overall, in spite of the larger and more
complex kernel and in spite of user experiences.

Lastly, my latest experience (Dave Haynie warned us all about this one -
and he was right.)  Just before upgrading my A3000 to 4mb of SCRAM, I ran
the Dhrystone benchmark.  When I ran it again after the RAM change, the
benchmark indicated only a very minor performance increase, yet the system
is obviously much faster than it had been.  Compiles of even small files
that didn't come close to exhausting RAM when I had only 2mb were even
much faster.

Still not convinced?

Two of the benchmarks are floating-point intensive.  One of them to the
point of absurdity.  My 25Mhz Amiga performs both of them with roughly
the same performance (or better) than a 33Mhz ALR with 80387 and 64k
zero-wait state cache.  Even before the RAM improvement.  Both were
compiled to use the math coprocessor directly (in-line floating point)
with the latest compiler offerings from SAS and Microsoft.

>From this I can surmise that the '386/'387 combination is a dog, right?

I'd be happy to believe that, for what you're doing, a '386 box is the
best solution for *you*.  But the '030 is much slower than the '386???
Dave, you've been reading too much Byte Magazine.  If you'd like, I'd be
happy to dig up a real benchmark comparison between those processors and
FAX it to you.  What it shows is that the '030 is marginally faster than
the '386 with the '030 on-board cache enabled.  Other than that, they're
about equal (and, btw, the National and AT&T 32-bit offerings way slower
than both).

Now, as to what can be said about the benchmark tests you've performed?
You can say that the benchmarks you've run, compiled with the compilers
you've compiled them with, run faster/slower on this machine than on that
machine.  That's it.  If you want to stretch it, you can surmise maybe
that the code produced by the compilers you used is more efficient for
the '386 systems than that produced for the '030 systems.  But implications
about the relative performance of a hardware platform, or even the
operating system running on it, based on these benchmarks is downright
poor scientific method at best and, I suggest, are invalid.  Period.
And since I rarely use my machines to run benchmarks, their results are
of little use to me.

I apologize for the bandwidth, but I've been watching this benchmark thing
go on for *far* too long.  Admittedly, I don't have to read this newsgroup
if I don't want to, but I do want to - I'm intensely interested in how
CBM has done with their first UNIX offering (been curious ever since I saw
the CBM ad for UNIXoid engineers a few years ago).  I'd just like to see
more facts and less misinformation.

[flame off]

>In article <a_subsequent_one> david at kessner.denver.co.us (David D. Kessner) writes (in part):
>>
>>EXXON (EXXOFF?)  dumped oil in Alaska, should TEXACO do the same?
>>

Ha Ha Ha Ha Ha Ha Ha Ha choke gasp heh heh heh...  I just about fell out of
my chair.  Thanks!  And I entirely agree with the point you made.

-- 
Jim Seymour				| Medar, Inc.
...!uunet!medar!jseymour		| 38700 Grand River Ave.
jseymour at medar.com			| Farmington Hills, MI. 48331
CIS: 72730,1166  GEnie: jseymour	| FAX: (313)477-8897