rcm@tropix.UUCP (07/16/83)
ical to remove the users
from it, the Sel, the Amdahl, and the Data General MV8000, so they are not
quiescent, as the others were.
The objective was to compare the turn-around time when programming
each of the machines, and includes the effect of additional complexity
in the compiler due to different instruction sets.
main(){printf("Hello world!\n");}
cc hello.c sorted by real time
booth system CPU clock real user sys %
Amdahl own 470 2 .2 .2 20
Masscomp own 68k 10Mhz 5 1.1 2.2 13
Gould Sel own 10 1.6 3.1 47
Fortune own 68k 5Mhz 13 8.2
tropix own 68k 8Mhz 14 2.8 5.3 58
Codata Unisoft 68k 8Mhz 17 5.5 5.1 62
HP own custom 18Mhz 18 2.4 5.4 43
intel xenix 286 5Mhz 20 6.7 3.1 49
wycat Unisoft 68k 8mHz 21 2.0 5.8 37
Spectrix xenix 68k 10Mhz 22 2.7 3.4 28
NCR Unisoft 68k 10Mhz 25 3.9 6.1 40
Nat'l Semi own 16k 6Mhz 26 4.8 12.4 66
Callahan Unisoft 68k 27 7.4 4.2 43
Cosmos Unisoft 68k 10Mhz 28 6.2 4.4 38
Zilog zeus z8000 5Mhz 28 2.0 4.3 23
CRDS unos 68k 12Mhz 32 3.2 5.0 26
Venturcom IBM PC 8088 40 8.2 8.4
Pixel Unisoft 68k 41 2.9 3.0 14
Unipress Unisoft 68k Lisa 41 4.8 5.7 26
DGeneral own MV8000 63
HCR lmc 16k 4Mhz 78 40.6 17.0 74
cc hello.c sorted by user time
booth system CPU clock real user sys %
Amdahl own 470 2 .2 .2 20
Masscomp own 68k 10Mhz 5 1.1 2.2 13
Gould Sel own 10 1.6 3.1 47
Zilog zeus z8000 5Mhz 28 2.0 4.3 23
wycat Unisoft 68k 8mHz 21 2.0 5.8 37
HP own custom 18Mhz 18 2.4 5.4 43
Spectrix xenix 68k 10Mhz 22 2.7 3.4 28
tropix own 68k 8Mhz 14 2.8 5.3 58
Pixel Unisoft 68k 41 2.9 3.0 14
CRDS unos 68k 12Mhz 32 3.2 5.0 26
NCR Unisoft 68k 10Mhz 25 3.9 6.1 40
Nat'l Semi own 16k 6Mhz 26 4.8 12.4 66
Unipress Unisoft 68k Lisa 41 4.8 5.7 26
Codata Unisoft 68k 8Mhz 17 5.5 5.1 62
Cosmos Unisoft 68k 10Mhz 28 6.2 4.4 38
intel xenix 286 5Mhz 20 6.7 3.1 49
Callahan Unisoft 68k 27 7.4 4.2 43
Venturcom IBM PC 8088 40 8.2 8.4
HCR lmc 16k 4Mhz 78 40.6 17.0 74
DGeneral own MV8000 63
Fortune own 68k 5Mhz 13 8.2
Details:
Masscomp has 2 68k cpu's in their system and a 4k block size in their
filesystem. It is also possible to make contiguous files in their system,
speeding loading as if all such files were "sticky" bitted. Their disk is
an ampex capricorn 30ms 160Mb.
Spectrix was using a CDC wren and 1 1/8 Mb of ram.
The 286 was using a 35Mb 8" priam (35ms avg seek time.)
Cosmos was the only 68k which used the 68451 memory management chip
from Motorola, although Motorola was talking about a VME10 unit with that
memory manager out with system V in October.
The HCR port on the 16k was the only system observed with job control
at the show. Lmc had slowed down the cpu to deal with rug static at the show.
Please try this trivial benchmark on your system if it is not one of
the ones mentioned and mail the results to me. I'm especially interested in
a selection of vaxen running Berkley 4.1, 4.1c, and 4.2 and System III and V,
and Eunice. I'll summarize to the net all the results in two or three weeks.
Bob Moore
GCA/Tropel, Fairport NY
716-377-3200
seismo!rochester!ritcv!tropix!rcmswatt@ittvax.UUCP (Alan S. Watt) (07/18/83)
This is an interesting benchmark. However the comparison as given doesn't quite show the whole picture. If you look at the size of the "a.out" file produced, you will find (at least I find on our UTS system [IBM 4341]), that the \smallest/ a.out file you can get from UTS is ~20K bytes. Once you drag any routine from "stdio" in, it appears that an incredible gob of "in-laws" come with it. This may in fact be a disadvantage to UTS, but it does indicate that that sucker can do I/O \fast/. I think the basic filesystem block size is 4096 bytes, which may help explain it. So just comparing real/user/system times for "cc hello.c" may make UTS/470 look good, but if you compared the time per byte of output produced, it would make it look even better. What a pity you still have to edit using those %$@!^@$$! 3270 tubes! - Alan S. Watt