tsc2597@acf4.UUCP (Sam Chin) (05/28/85)
<>
To put to rest the myth that the Z-100 can ever be faster than the IBM AT.
I ran the benchmark as suggested by the author of the original note. I used
both BASICA as supplied by IBM and generic MSBASIC which you can buy from
Microsoft for generic MS-DOS machines (it has no graphics or
communications). The benchmark was run on an IBM AT with 256K, 1 1.2 Mb
floppy and 1 360K floppy. It was a normal AT with the 6 Mhz clock as
opposed to the owner enhanced AT with a 8-9 Mhz clock.
IBM BASICA 3.0 ---------> 71 seconds
Microsoft MSBASIC --------> 36 seconds
I will also recall my previous benchmark using a 8 Mhz 8086 which came in at
41 seconds. It is very possible that IBM purposely slowed the BASICA
interpreter to make it compatible with the PC. A few more points:
(1) If the Z-100 is pushed to 8 Mhz using a 8088-2, it will still suffer
from the 1 wait state penalty if you still use 150ns rams. Also most of the
Intel support chips such as the 8253, 8250 and 8251 are rated at 300ns
causing 2 wait states on an i/o cycle.
(2) The 8088 has 8 bit address lines which will always make it slower than
the 8086 or 80286 on memory reference instructions. The 8086 also has an
instruction queue of 6 instructions as opposed to the 8088 which has only 4.
I don't know if the 80286 has any form of cache but judging from its
performance, it probably has a larger cache than the 8086.
(3) You cannot compare the Mhz between the 8088/8086 to the 80286 because
its instructions take fewer cycles. An aquaintance who builds S-100 CPU
boards claims that a 6 Mhz 80286 is equivalent to a 13-14 Mhz 8086.
(4) A lot of manufacturers who are claiming that their new AT compatibles
are 30% faster than the AT because they eliminated the 1 memory wait state
may be dead wrong. Although my 8 Mhz 8086 benchmark was done on 100ns static
ram, I have in the past tried to rate my static ram board against my dynamic
ram board with 150ns dynamic rams. I did a test to eliminate the wait state
by interleaving two boards so that the odd and even addresses were on
different boards thus eliminating any wait states. The improvement was
a measly 5%.
Sam Chin
tsc2597.acf4@nyu.ARPA
allegra!cmcl2!acf4!tsc2597jchapman@watcgl.UUCP (john chapman) (05/30/85)
> Sam Chin writes: <> > . . . > > I will also recall my previous benchmark using a 8 Mhz 8086 which came in at > 41 seconds. It is very possible that IBM purposely slowed the BASICA > interpreter to make it compatible with the PC. A few more points: How does slowing something down make it compatible? I can see that a graphics program requiring user interaction might in some sense be "incompatible" on a faster machine (processor speedup is generally seen as a benefit in highly interactive applications though). In addition I think it would be extremely difficult to make a compiler generate code which would overall be slowed down by a certain factor. > > (1) If the Z-100 is pushed to 8 Mhz using a 8088-2, it will still suffer > from the 1 wait state penalty if you still use 150ns rams. Also most of the > Intel support chips such as the 8253, 8250 and 8251 are rated at 300ns > causing 2 wait states on an i/o cycle. Actually, from what I know, a 150ns dram ought to be able to keep up with an 8mhz 8086/8088 (just) with no wait states. It's whatever is used as the dram controlle that introduces the wait states. As an example I have seen an 8203 based board which runs with no wait states with a 5mhz 8086/8088 but requires 2-3 when used with an 8mhz 8086/8088. The extra wait states are all directly attributable to to the peculiar interaction between the 8203 and 8086 (after a certain speed the dram won't know if it can service a request by the time the 86 needs to know if there will be wait states (in T2) so a different signal from the 8203 is used which always puts in the wait states. > > (2) The 8088 has 8 bit address lines which will always make it slower than ^^^^^^^ data lines, the address bus is still full width I believe. . . . > (4) A lot of manufacturers who are claiming that their new AT compatibles > are 30% faster than the AT because they eliminated the 1 memory wait state > may be dead wrong. Although my 8 Mhz 8086 benchmark was done on 100ns static > ram, I have in the past tried to rate my static ram board against my dynamic > ram board with 150ns dynamic rams. I did a test to eliminate the wait state > by interleaving two boards so that the odd and even addresses were on > different boards thus eliminating any wait states. The improvement was > a measly 5%. In some situations I have experienced a 20% difference between the static and dynamic ram execution profiles. It depends heavily on the access pattern of the program being executed.> > > Sam Chin > tsc2597.acf4@nyu.ARPA > allegra!cmcl2!acf4!tsc2597 John Chapman ...!watmath!watcgl!jchapman
GUBBINS@radc-tops20.ARPA (Gern) (05/30/85)
The Z-100 and 8088/8086 machines will not suffer as you stated from 150nsec memory needing wait states. An 8088/8086 can run, in complete spec, with room to spare, at 8MHz with 150Nsec memory (its not bizzare, its a feature). By design, Intel has 'relaxed' r/w strobing which make this possible. I do not think the same is true of the 80286. A 5MHz 8088/8086 can run at 5MHz with no wait states needed. Anyway, its all in the spec books. This fact allows a Z-100 (normally, until recently, a stock 5MHz machine, now an 8MHz machine from ZDS) to be turboed to 7.5MHz with 200nsec memory and remain totally in spec (do note that the Z-100 inserts 1 I/O wait state which keeps the CRTC happy and continues to keep the other I/O happy). The AT at 6MHz looses (according to accepted numbers) about 20-30% of its speed due to the 1 memory wait state. I now refer you to the benchmark results posted by another person who ran the same machine code on both machines. -------
GUBBINS@radc-tops20.ARPA (Gern) (05/30/85)
correction to my last message. The relaxed strobing statement should
state, Intel designed the 8088/8086 to run with 3MHz memory at 5MHz with
no memory wait states. This allows turboing, and 8MHz speed with 150nsec
memory with no wait states.
The following blurb is the independent benchmark results posted. Note that
the same machine code was used on both the Z-100 and the IBM-AT and a
standard 5MHz Z-100 beat the 6MHz AT 2 out of 4, close in the third, and
lost fair and square in the forth. An 8MHz Z-100 (note that the results
are interpolations, real values may be off by +- 1 sec) beats the AT 3
out of 4 benchmarks.
The reason for the Z-100 putting up such a good show? That is the purpose
of all these messages. The AT wait state is one reason, the IBM firmware,
if like the PC, may be the other.
Benchmark Blurb:
26-May-85 21:58:54-EDT,2901;000000000001
Return-Path: <atm%deimos@cit-hamlet.arpa>
Received: from cit-hamlet.arpa by RADC-TOPS20.ARPA with TCP; Sun 26 May 85 21:58:36-EDT
Received: from deimos by hamlet with DECNET ; Sun, 26 May 85 18:57:45 PDT
X-ST-Return-Receipt-Requested:
Date: Sun, 26 May 85 18:57:16 PDT
From: atm%deimos@cit-hamlet.arpa
Message-Id: <850526185657.002@deimos>
Subject: Z-100 vs AT
To: INFO-HZ100@RADC-TOPS20.ARPA
<A corrected version of the message sent yeaterday>
Here is a bit of imput to the Z-100 vs. AT debate. I have run four benchmarks
on both machines. The Z-100 has a 5 MHz clock, but an 8087 has been added
(on a Hudson board). The AT has the standard 6 MHz clock and an 80287.
The programs are the following: The Sieve of Eratosthenes, 10 passes (see
BYTE, Jan 1983), which is entirely integer and logical operations. The
Savage benchmark is solid double-precision floating point function calls
(see Dr. Dobb's Journal, Sept. 1983 and Aug. 1984). Both of these have
been run on a very wide range of computers, from a Cray to an HP-15 !
The third is INTSUM, which does double-precision arithmetic only, no
function calls. The fourth is FOUR, which evaluates a Fourier series in
single-precision, calling SIN(A) and doing indexing.
All the benchmarks were compiled with MS-FORTRAN Version 3.2, using the
8087 mathematics library and the $NOFLOATCALLS metacommand, which is the
combination that gives the fastest code. On the Z-100 they were run under
Z-DOS Version 1.25, which is a few percent faster than MS-DOS 2.21,
since it takes less time to service the clock interrupt. Run times are in
seconds, and no allowance is made for loading time.
The results indicate that a Z-100 with standard clock about ties an AT
on any program which runs almost entirely in the 8087. (Note that the
AT's 80287 runs with a 4 MHz clock.) If you multiply the Z-100 times by
5/8 to simulate an 8 MHz clock, then the AT loses on any program
emphasizing floating point. However, it still wins on integer operations.
Compiles and links don't use floating point, so the AT seems noticeably
faster to use. The Compaq Deskpro, which has an 8086 and an 8087,
both running at 8 MHz, should beat either the 8 MHz Z-100 or the AT.
By the way, the AT can also be sped up to 8 MHz with a new clock crystal.
I think the contestants should adjourn to the bar for a friendly drink.
________________________________________________________________________
Program SIEVE SAVAGE INTSUM FOUR
Z-100 12.95 6.76 27.08 11.65
Z-100*5/8 8.09 4.23 16.93 7.28
AT 4.61 6.43 29.72 11.81
________________________________________________________________________
Alan Moffet
Caltech
Note that the 8087/80287 are a supported option in both machines, and
ZDS now supports 8MHz Z-100s, IBM only supports 6MHz ATs.
Gern
-------melmoy@nprdc.ARPA (Mel Moy) (05/30/85)
There certainly has been a lot of message traffic about benchmarking the AT against the Z-100. How many people are really making hardware and software decisions predicated on the outcome of this overextended harangue? Before long, someone is going to argue for the relative speed of a Commodore-64 with a 68020 board, or for an abacus lubricated with STP. Are your requirements such that you are confronted with the top end limits of the Z-100 or your AT's to the point that you can't work anymore? Or is this a need to justify your hardware commitment. Don't you believe that two or three years from now you will be using a different machine--regardless? I know I may be missing the point, but maybe somebody can educate me as to why this comparison between the AT, Z100, or anything else deserves this much concern. The technology changes! Computers are perishable and disposable! Computers have no emotions and are not hurt when they are superceded by advancements! Computers are tools. No tool is going to be appropriate for all work. Love your work--not your tools! Mel Moy
tsc2597@acf4.UUCP (Sam Chin) (05/30/85)
<> Some how I don't seem to be getting through! (1) We were comparing and 8088 vs a 80286. We were not comparing a 8087 to an 80287. No one ever mentioned benchmarks with the floating point processors until someone from Caltech posted those benchmark times. It is entirely true that a 4 Mhz 80287 (used on the AT) will be slower than an 8 Mhz 8087 (used on a Hudson board for example) but virtually all 8086 instructions will be faster on a 80286. Without even running benchmarks, just look at the 80286 spec to see how many cycles are required for the various instructions and then compare it to the 8088 spec. You will find out that the 80286 requires less cycles for virtually all instructions. I think I am just restating the obvious. (2) What I can tell you about memory wait states is that my 2 256K RAM boards from Lomas Data Products are loaded with 150ns RAMS. I have wire wrapped exactly 1 wait state on a memory cycle and 2 wait states on i/o cycles on the CPU board which has a 8 Mhz 8086. If I remove the wait state on the memory cycle, the system occasionally hangs. The manual clearly states that if I use a 8086 CPU above 5 Mhz, I have to enable the r/w acknowledge signal and enable the wait state on the memory cycle. It might be possible that the 8088 is sufficiently slower than the 8086 that the wait state is not necessary but then the 80286 is still faster than the 8086. (3) My benchmark with generic MS-BASIC on the AT proves that the AT is faster than an 8 Mhz 8086 running with 100ns static ram *even* with its one wait state. The original BASIC benchmark didn't make sense because you were not using the *exact* same basic interpreter. People all over the net reported wildly varying times when they ran the benchmark on their own versions of Microsoft Basic on their own machines. Will someone from Intel get into this and clear this up. We are not comparing uP from different companies. Sam Chin allegra!cmcl2!acf4!tsc2597 tsc2597.acf4@nyu
tsc2597@acf4.UUCP (Sam Chin) (05/31/85)
<> The argument is that : " The Z-100 is faster than the AT because the AT requires that one wait state on its memory cycle and the Z-100 doesn't." Now both Z-100 and AT use 150ns RAMS. Why did the AT designers have to insert that 1 wait state? The reason is that the 80286 was just too fast for those 150ns RAMS. If the claim is that an 8088 running at 8 Mhz is faster than a 6 Mhz 80286 then it too must have that 1 wait state. If it doesn't need 1 wait state, then it must obviously be slower than the 80286. Sam Chin allegra!cmcl2!acf4!tsc2597 tsc2597.acf4@nyu
GUBBINS@radc-tops20.ARPA (Gern) (05/31/85)
The point of all this Z-100 vs. IBM-AT is an attempt to uncover the reasons that the Z-100 at $1799 at 5MHz performs as well, if not better than the IBM-AT at >$4000 at 6MHz, all with current stock manufacturer supported capability. The normal observer would think that the AT, at 6MHz with a 16-bit CPU would surely outperform a Z-100 with a 5MHz 8/16-bit CPU. But, as exemplified by these messages, this is not the case. It is, as you stated, a case to justify the hardware commitment. It is also to inform and document info that may be used in source selection of computer equipment. I want to say a lot more, but I can not from my position. Cheers, Gern -------
GUBBINS@radc-tops20.ARPA (Gern) (05/31/85)
No, No, the 'friendly discussion' is that: The Z-100 is as fast at 5MHz and faster at 8MHz than the AT because the AT requires one memory wait state and was designed and firmware programmed by IBM and the Z-100 doesn't. The WS on memory boards as you mentioned is a common problem with mem boards. It is usually the fault of slow decoders and buffers on the board addressing logic rather that the speed of the memory ICs. Replacing the 74LS240/244 and others with 74ALS or 74S series TTL usually corrects the problem Cheers, Gern -------
CMP.WERNER@utexas-20.ARPA (Werner Uhrig) (05/31/85)
RE:
The point of all this Z-100 vs. IBM-AT is an attempt to uncover the
reasons that the Z-100 at $1799 at 5MHz performs as well, if not better
than the IBM-AT at >$4000 at 6MHz, all with current stock manufacturer
supported capability. The normal observer would think that the AT,
at 6MHz with a 16-bit CPU would surely outperform a Z-100 with a 5MHz
8/16-bit CPU. But, as exemplified by these messages, this is not
the case.
[above was Gern's message]
I remember well when IBM and other manufacturers sold you on the idea
of spending a lot of money for a machine upgrade to get better
performance when all that was involved was little 'tap-and-dance
routine' by the tech, (SWITCH to the left, JUMPer to the right (-: )
Economist call it "Maximizing sales, while Optimizing Profits"
or somesuch.
Of course, in the micro-world with many capabable people around and
ready to fill in the gap with add-on products, it should take no time
until we can buy the 'switch and jumpers' to defeat this "evil" scheme.
I would not be surprised to see a new Gernware product soon, which
will allow the AT to live up to its potential (and Gern to buy a Z-200
and head for Jamaica (-: ) Given it a thought yet, Gern ???
-------brownc@utah-cs.UUCP (Eric C. Brown) (05/31/85)
Has anybody considered the possibility that IBM AT BASICA ver. 3.0 is
a set of patches to IBM XT BASICA ver. 2.0, which is a set of patches to
IBM PC BASICA ver. 1.1, which is a set of patches to IBM PC BASICA ver. 1.0,
which is a set of patches to IBM PC Disk BASIC ver. 1.0, which is a set of
patches to IBM PC Cassette BASIC ver. 1.0?
I'm fairly sure that Z-100 ZBASIC is one unpatched piece of code, and it might
even be real 8086 code, rather than translated 8080 code (like IBM PC Cassette
BASIC). A more meaningful comparison might be between IBM PC BASICA and
IBM AT BASICA.
For my two cents, I have noticed that the AT runs about 6 times faster than
the Zenith Z-100 when you run things like Pascal programs or compilers. The
AT hard disk alone is a lot faster than the Z-100 hard disk, which speeds
compiles up a lot all by itself.
Personally, I'm waiting for my Zenith Z-200. Zenith Reliability, AT
Performance. What more could you ask for?
Eric C. Brown
brownc@utah-cs
..!{ihnp4, seismo, decvax}!utah-cs!browncphil@amdcad.UUCP (Phil Ngai) (06/01/85)
In article <1040026@acf4.UUCP> tsc2597@acf4.UUCP (Sam Chin) writes: >Will someone from Intel get into this and clear this up. We are not >comparing uP from different companies. I'm not from Intel but have designed products with the Intel family and dynamic RAMs and feel qualified to point out that you can't just say "my system needs 1 wait state with 150 nS memories to run an 8086 at 8 MHz, therefore all 8 MHz 8086 systems must have 1 wait state if used with 150 nS memories". A good dynamic RAM design is hard. Many designers cop out and insert wait states to make their job easier. But that doesn't mean all systems yield the same performance with the same parts. My Honda Civic has 4 cylinders and burns gasoline, just like a Porsche 944, so it should be able to keep up, right? It is possible to run an 80186 at 8 MHz with no wait states and 150 nS memories with plenty of margin IF you know what you are doing. Or if you don't care about margin. This margin, by the way, is designed in by conscientous manufacturers to allow for variations in the devices they use and to allow operation over a range of temperatures. Some devices get slower when they get lot and some get slower when they get cold. A manufacturer wants his product to work in both environments. Flaky products are not appreciated by customers. The people who crank up the clock rate in their computers are reducing their margin. It's your choice, but don't think it's a conspiracy to sell deliberately degraded products. The 8086 is a little harder but not impossible. There are some memory controller devices offered which do require wait states. I would claim they have a lousy architecture. But some designers think they are convenient and so you will find them in some systems. By the way, I think references to "3 MHz" memory are pretty weird. You can say a memory has a 150 nS access time or a 500 nS cycle time but "3 MHz" is a very odd way to talk about a memory device. -- There's always tomorrow. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
phil@amdcad.UUCP (Phil Ngai) (06/01/85)
In article <1040027@acf4.UUCP> tsc2597@acf4.UUCP (Sam Chin) writes: >Now both Z-100 and AT use 150ns RAMS. Why did the AT designers have to >insert that 1 wait state? The reason is that the 80286 was just too fast >for those 150ns RAMS. If the claim is that an 8088 running at 8 Mhz is >faster than a 6 Mhz 80286 then it too must have that 1 wait state. If it >doesn't need 1 wait state, then it must obviously be slower than the 80286. Sorry Sam, it isn't that simple. Using interleaved memory, you get 4 clock cycles minus data strobe and data setup times to perform a memory cycle on the 80286. Thus, an 8 MHz 80286 allows nearly 500 nS for a memory to cycle. I think if the AT needs 1 wait state at 6 MHz to use 150 nS memories, its designers must have been lazy (or lousy). -- There's always tomorrow. Phil Ngai (408) 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.ARPA
tsc2597@acf4.UUCP (Sam Chin) (06/01/85)
<> Thank you Mel Moy and Werner Uhrig for showing me why I was getting frustrated in this discussion. I don't have a Z-100 or an AT and therefore did not have the motives Gern had. All I was trying to do was explain something which seemed painfully obvious to me. Anyway as far as I am concerned, I finally understand everything and will not pursue the subject any further. All I hope is that the discussion generated some shreds of useful information. Sam Chin tsc2597.acf4@nyu allegra!cmcl2!acf4!tsc2597
indra@utai.UUCP (Mad as hell) (06/03/85)
> > The point of all this Z-100 vs. IBM-AT is an attempt to uncover the > reasons that the Z-100 at $1799 at 5MHz performs as well, if not better > than the IBM-AT at >$4000 at 6MHz, all with current stock manufacturer > supported capability. The normal observer would think that the AT, > at 6MHz with a 16-bit CPU would surely outperform a Z-100 with a 5MHz > 8/16-bit CPU. But, as exemplified by these messages, this is not > the case. > > It is, as you stated, a case to justify the hardware commitment. It is > also to inform and document info that may be used in source selection > of computer equipment. I want to say a lot more, but I can not from > my position. > > Cheers, > Gern > ------- Why do these guys compare two computers by their BASIC interpreter? How many people on the net use basic anyway? So why don't we get serious for once and do benchmarks in assembler, using anything else doesn't show a thing, except possibly, efficiency of interpreter/compiler.