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

[David Kessner]

In article <94 at hdwr1.medar.com> jseymour at medar.com (James Seymour) writes:
>
>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).

Yes, but there are several other UNIX options.  Interactive, ESIX, UHC, BSD,
and Microport are just several.

BTW, at last check, Microsoft owned 20% of SCO.


>>                                        ...  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.

Fine!  SO well use something like GCC as a benchmark?  It doesnt matter to me.

I dont hear you suggesting something better...  We gotta start somewhere.


>[flame on - donning fire-retardant suit]

Yea.  You and me buddy!  :)


>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."

Well am I wrong?

>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, ..."

You mis-read me, please refer to the original artical for the exact context.

Here, I take an assumption that the 386 is faster than the 030.  For the
sake of that paragraph IT DOESNT MATTER.  What I am saying here is that the
030 is a cleaner design than the 386.  Given the age of the Motorola line
of CPU's (in comparison to the age of Intel's _32_bit_ CPU's) I'm suprised
that the 030 doesnt blow the socks off the 386 (by that I mean 2-3 times
faster, which it is clearly not).

In different words:  because of the 386's hodge-podge nature, I'm supprised
it gets any performance at all-- much less performance that is comparable
with the 030.


>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:

Again.  Can you offer something better?


>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?

There are many things that can influence the disk performance of a Unix/Xenix
system.  Some ESDI controllers do 35 to 17 sector translation for ST-506 
compatability-- and this takes time.  The ESDI drive could have been formatted
at the wrong interleave.  The XENIX ESDI drivers could be bad.  

In the case with the same binaries on equivalent machines (sans drives) there
is no reason the benchmark would not be valid.  It is my experience to look
further and see exactly why the results were the way they were.  With a little
investigation, it can be quite easy to find the reasons for the results.

The results of a benchmark should not be taken at blind faith.  Unless you
know WHY those results were generated, it is almost useless.  With the
Dhrystone 1.1 restults, we theorize several reasons.  Lack of cache, 386 
tends to run 'string based' programs faster, compiler optimized for dhrystone,
need Dhrystone 2.x, the 386 is just faster, etc.  I personally tend to believe
the lack of cache, and 'string based 386' myself.  The other reasons could be
valid, so I am keeping my options open.


>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.).

Here again, you could have investigated a little more.  Because you said,
"Yet the users...had the very strong perception that the UNIX system was 
slower...", I tend to think several things.

Did you check to see WHY they thought it was faster?  Was their terminals at
a higher baud rate, to make aplications appear 'snappy'?  Was the UNIX machine
doing a larger number of background tasks (news, gateways, network stuff)?
Were there more users on the XENIX system.

All of these affect the 'apperent' performance of a machine.  Since if a
machine is processing news, everything else would be slower.  A benchmark 
can measure only the actual CPU time used rather than the real time required,
and they are usually ran under minimal system load (when there is not several
people are logged in or news is not being processed).

Additionaly, you were probably running the AT&T compiler on the UNIX macine
and the Microsoft compiler on the XENIX machine.  The Microsoft compiler
is not known for speed.

If you think compiles are slower then MEASURE IT.  Do you remember the 'time'
and 'timex' commands?  While you are at it, learn the 'sar' command (not
available on all machines.  it reports CPU utilization).


>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.

That is why I'm all for using a different benchmark.  I never claimed that
the Dhrystone results were conclusive.


>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.

Benchmarks ran under MS-DOS are misleading at best.  Often the results are
half the speed as what is achieved under UNIX.  My machine runs Dhrystones
at 7500 under MS-DOS/Turbo-C++, but 11,900 under UNIX/GCC.  This is due to
the lack of 32 bit regesters/optimization, having to deal with 64K segments,
and the early (pre-387) FPU's required the use of the FWAIT before each 
FPU instruction (it pauses the CPU till the FPU is done) and this slows
things down dramatically.  In addition, the 387 has trig instructions while
MSC (microsoft C for those slow folks) does not utilize this.

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

No.  From that you can surmise that:

	Because MS-DOS cannot deal with the advanced features of the 386/387,
	and that MSC produces code that runs under MS-DOS, the
	program was severly handicaped because it could not utilize the
	386/387 to it's full extent.

To take that a step further:

	MS-DOS is a dog.

I dont think that anyone will dispute that.


>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???

I never clamed that my results were conclusive.  And I never said any blanket 
statement like, "The 030 is always slower than the 386".  Every time I said
something to the effect of "the 386 is faster", I mentioned the SOURCE of
my facts and hope we are all men (women) enough to take it at face value.

Since I have spent more time defending what I said, I can assume that we
are not all men here.  C'mon.  Lets get back on the REAL ISSUE of:

		Why Should I Buy An A3000UXD?

Every response to that question I have gotten HAVE NOT BEEN ON THE MERITS
OF THE MACHINE ITSELF.  It's always been "C= Support", "Setup Time", etc.

Because of the $7000 price tag (back to the original topic posted by
Chris Hanson) I expect more than C= is delivering with Amigs UNIX.  Color
X, and faster CPU speed are the top on the list.  Better X resolutions, 
Motif, and an FIFO'd serial port are a little further down.  

Other machines in this price range do have these features are:

	386/33 with 34010 board for about $6000.
	486/33 for about $7000
	486/33 EISA for about $8000
	SPARC Clones for about $8000 <-- includes 16" color monitor.
	and the Color NeXT <-- 17" monitor, 16 bits/pixel

While each of these machines have their plus's and minus's it is clear
that the A3000UXD has some stiff competition.

>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).

While I read Byte (and PC Mag for that matter), I do not put a lot of weight
on their benchmarks-- since they are often wrong.  In addition, they know
nothing about testing UNIX computers.

I am perfectly willing to say that the 030 is roughly equal to the 386 at
the same clock speed.  All of my results have shown that they are within 20-30%
and that is not worth fighting over.  It still doesnot take away any
signifigance from the A3000UX's lackings...


>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.

Yes!  Yes!  That's it exactly!  Damn.  It took you 100+ lines to figure that
out!

Please take the benchmarks at face value, and dont read into them any more
information than what is shown.  Just because my machine weighs in at 11,900
dhrystones/sec and the A3000UX gets 6,500 does not mean that the 386 is 
faster.  As I have said before, the only thing that this proves without a 
doubt is that the 386 runs dhrystones faster than the 030 (using GCC).

If everyone would say exactly what you just said in the above paragraph (rather
than the whole text), then we could get past the dhrystone thing and focus on
the REAL, more relavent, issue of:  How does the A3000UX stack up to it's 
competition.


>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 have never made any 'implacations about the relative performance...[of the
A3000UX]'.  I stated what I found, and everyone else read their own 
interpretation of it.  I've spent a whole lot of net-bandwidth trying to 
say that tactfully, now I have to do it in a less than ideal way.  As in:

	Damn folks.  It's not like I'm questioning your manhood.  It's not
	the end of the world or something.  etc, etc, etc...


>I apologize for the bandwidth...

Me too.  I apologize.

I would have replied to this via mail, but I took this particular artical
rather personally.  I felt that since the original artical is readable by
all, the response should do likewise.  Besides, I hope that some of what
I said here will clear up exactly what was meant by the posted dhrystone
results.


>>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.

Well...  It is a reasonable statement since EXXON obviously has a problem with
_FLOW_CONTROL_...

 
>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


				- David Kessner
				david at kessner.denver.co.us

-- 
David Kessner - david at kessner.denver.co.us            | do {
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) |    . . .
If you cant flame MS-DOS, who can you flame?          |    } while( jones);