Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!medar!jseymour From: jseymour@medar.com (James Seymour) 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: <94@hdwr1.medar.com> Date: 29 Mar 91 21:25:40 GMT References: <1991Mar22.053324.8867@kessner.denver.co.us> <20073@cbmvax.commodore.com> <1991Mar24.212902.18281@kessner.denver.co.us> Organization: Medar, Inc. Farmington Hills, MI Lines: 157 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). 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 david@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@cbmvax.commodore.com> jesup@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 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. -- 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