dam@mtgzz.att.com (d.a.morano) (05/26/89)
In article <199100003@inmet>, rich@inmet writes: > > > Hal Hardenbergh [incl std dsclmr] ames!vsi1!hal hal@vicom.com > > surely nobody here remembers the newsletter DTACK Grounded ? > > As a matter of fact, I do! Please stop doing whatever job you have now and > republish DTACK Ground. Life has been so booorrring without it. > DTACK Grounded, if I remember correctly. Compelling high performance title. Yes, I found it quite enjoyable, but I don't think that the company is willing to have to pay for it if necessary. Maybe you could get some advertisers to defray costs and publish it free. Dave Morano AT&T Bell Laboratories
nather@ut-emx.UUCP (Ed Nather) (05/26/89)
In article <5164@mtgzz.att.com>, dam@mtgzz.att.com (d.a.morano) writes: > In article <199100003@inmet>, rich@inmet writes: > > > > > Hal Hardenbergh [incl std dsclmr] ames!vsi1!hal hal@vicom.com > > > surely nobody here remembers the newsletter DTACK Grounded ? > > > > As a matter of fact, I do! Please stop doing whatever job you have now and > > republish DTACK Ground. Life has been so booorrring without it. > > > DTACK Grounded, if I remember correctly. Compelling high performance title. > Yes, I found it quite enjoyable, but I don't think that the company is > willing to have to pay for it if necessary. Maybe you could get some > advertisers to defray costs and publish it free. You remember correctly. At its height, it was the best-informed journal on the computer industry, the most fun to read, and by far the most irreverent. It was supported (in part) by subscription fees, which readers gladly payed to get the (monthly) newsletter -- it was the highlight of *my* month, at least. It carried no advertising, and so was captive to no one --- not that the editor, Hal Hardenbergh, would have allowed that, in any case. It was a one man show: Hardenbergh did the whole thing himself. I miss it. Of course, you can't go home again, but should he ever decide to publish it (or a descendant) again, I'd get my checkbook out in a flash ... The title, "DTACK Grounded", was derived from the signal line on the 68000 CPU chip that allowed you to configure the "mighty" 68000, pushed as the "large system" chip by Moto, as a small, fast CPU for personal computers -- Hardenbergh's company made add-in 68000 cards for Apple computers, mostly; his "full gallon" board had 1,000,000 bytes of RAM, unheard-of in the PC world at the time. -- Ed Nather Astronomy Dept, U of Texas @ Austin
thaker@pak.harris-atd.com (Gautam Thaker) (05/27/89)
We have recently worried about performance comparison
between the new Sun Workstations (Sun 4/330 and Sparcstation 1)
and MIPS R-2000 based Workstations (DEC3100 or MIPS RC2030). It
is often said that potential buyers should run the programs of
interest to them rather than using the standard MIPS/MFLOPS
numbers published. We ran three different benchmarks that we have
been running a good deal of in the last few months. The programs
are:
Integer Benchmark:
Essentially a generate and test application. In brief, look
for 2000 vectors of 32 items permuated 20 at a time with pair wise
mutual distance of at least 10.
Floating Point Benchmark:
Simulate a channel, a demodulator and a decoder. Heavily floating
point intensive. Lots of logs, exps and sqrts.
Simulation Benchmark:
Simulating a 19 node communications network on a process oriented
simulation model. (Based on CSIM, a simulation package written by Herb
Schwetman of MCC. A total of 16000+ lighweight processes are created and
about 22000+ lightweight context switches are made.) Fair amount of floating
point, but time is dominated by overhead of creating and saving these
lightweight processes. R-2000 version of CSIM is well tuned
while the SPARC version may or may not be tuned. I just don't know.
Machine/OS Integer Floating Pt. Simulation
Benchmark Benchmark Benchmark
VAX 11/750 w/fpa BSD 4.3 832.3u 67.1s
SUN 3/60 w/68881 OS 3.4 227.8u 1.5s 365u 2.3s 38.8u 0.4s
MIPS M-500 (8 Mhz R2000,
1.31 Rev. Compilers,
BSD 2.1) 60.5u 0.1s 81.5u 0.1s 16.3u 1.0s
SUN 4/330 OS 4.0.3Beta 26.6u 0.0s 74.5u 0.1s 16.9u 2.6s
DEC3100 16.xx MHz R2000) 26.3u 0.0s 39.5u 0.1s 6.0u 0.7s
We really wanted to know about the difference in performance
between a Sparcstation 1 and the MIPS RC2030. These two are
comparable in their list prices though the 2030 is slightly
higher. (We get volume discounts from SUN, so Sparcstation prices
would have a winning edge if the performance was comparable or
close. We could not obtain a Sparcstation 1 or a RC2030 to
benchmark. We figured we would use a DEC3100 which is comparable
to the RC2030 and we would use a SUN 4/330 and derate that as per
published Sun numbers. (Sun 4/330 = 16 MIPS, 2.6 Mflops claimed,
Sparcstation 1 = 12.5 Mips, 1.4 Mflops claimed). I see that the
so-called 16 MIPS Sun 4/330 is about as good as a so called 12
MIPS DEC3100 for the integer application of interest to me. On
floating point the MIPS based machines win hands down. Why is the
Sun floating point performance still not up to par? I just used
"cc -O" in all cases. I did not fool with "-O3" or "-O4". When
the vendors see such optimizers are robust they can release them
as "-O".
Gautam H. Thaker Harris Corp; GSS; Advanced Technology Dept.
(407) 729-7099 MS 3A/1912; P. O. Box 37; Melbourne, FL 32902
Internet: thaker@trantor.harris-atd.com
Gautam H. Thaker Harris Corp; GSS; Advanced Technology Dept.
(407) 729-7099 MS 3A/1912; P. O. Box 37; Melbourne, FL 32902
Internet: thaker@trantor.harris-atd.com