Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!caen!sdd.hp.com!elroy.jpl.nasa.gov!ncar!csn!kessner!david From: david@kessner.denver.co.us (David Kessner) Newsgroups: comp.unix.amiga Subject: Re: Amiga 3000UX, X, OpenLook, Motif, Color, A2410, Etc. (somewhat long) Keywords: Amiga 3000UX, X, OpenLook, Motif, Color, A2410, etc. Message-ID: <1991Mar30.090353.9749@kessner.denver.co.us> Date: 30 Mar 91 09:03:53 GMT References: <20073@cbmvax.commodore.com> <1991Mar24.212902.18281@kessner.denver.co.us> <94@hdwr1.medar.com> Reply-To: david@kessner.denver.co.us (David D. Kessner) Organization: Kessner, Inc Lines: 310 In article <94@hdwr1.medar.com> jseymour@medar.com (James Seymour) writes: > >In article eachus@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 david@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@medar.com | Farmington Hills, MI. 48331 >CIS: 72730,1166 GEnie: jseymour | FAX: (313)477-8897 - David Kessner david@kessner.denver.co.us -- David Kessner - david@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);