chip@dartvax.UUCP (Brig ) (04/24/84)
We have had occasion to compare Intel's published 8088 timings
with actual 8088's. The published timings are simply false.
They are VERY flattering. In general, they claim instructions
take 2 clocks, where in fact most take 8.
The book specifically states that 8088 timings may be off by
"up to 10%". We have found 80-100% to be closer. Always slower.
I would take Intel timings with a very large dose of salt.
They are not exactly... well, come to think of it... they are
actually lying. I hope they clean up their act someday.
Brig Elliott ..decvax!dartvax!chipez@intelca.UUCP (Ed Zager) (04/26/84)
> > We have had occasion to compare Intel's published 8088 timings > with actual 8088's. The published timings are simply false. > They are VERY flattering. In general, they claim instructions > take 2 clocks, where in fact most take 8. > > The book specifically states that 8088 timings may be off by > "up to 10%". We have found 80-100% to be closer. Always slower. > > I would take Intel timings with a very large dose of salt. > They are not exactly... well, come to think of it... they are > actually lying. I hope they clean up their act someday. > > Brig Elliott ..decvax!dartvax!chip > The first thing Mr. Elliott needs to learn is the difference between TIMINGS, and EXECUTION SPEED, or EXECUTION TIME. Execution speed or execution time is the direct measure of how fast a processor will complete a task. This is what was discussed in his article. This is NOT!! a device's timings. A device's timings are the signal requirements of the system to properly drive the device and the device's signal requirements to properly drive the system. All of Intel's devices are tested extensively to guarantee these device timings. The published execution times are in the July 81 "iAPX88 Book" on pages 2-49 through 2-165, in the 1983 "iAPX88 Book" on pages 2-45 through 2-161, and in the August 1981 "iAPX 86,88 User's Manual" on pages 2-51 through 2-67. The only instructions specified to take 2 clocks are register to register type of instructions. These instructions will take longer to execute if they are not in the queue. An example of this is during the special case of executing a long string of register to register instructions. The prefetcher only gets to prefetch code while the execution unit is doing effective address calculations for a memory read or write. Since register to register operations do not perform bus cycles, the prefetcher does not get to prefetch code. But, look at what happens in "normal" code, a piece of data is loaded into a register, some operations are performed on the register and the data is put back into memory. We have performed enough memory operations to keep the queue full or near full. The text in the "iAPX 86/88 User's guide on pages 2-48 through 2-51 explains how to calculate instruction execution time and also explains additional factors which effect execution time. "Several additional factors can increase actual execution time over the figures shown in table 2-21. The time provided assumes that the instruction has already been prefetched and that it is waiting in the instructions queue, an assumption that is valid in most, but not all, operating conditions." The text also illustrates the other factors which effect execution speed. The text also states the following: "With typical instruction mixes, the time actually required to execute a sequence of instructions will TYPICALLY be within 5-10% of the sum of the individual timings given in table 2-21. CASES CAN BE CONSTRUCTED, HOWEVER, IN WHICH EXECUTION TIME MAY BE MUCH HIGHER THAN THE SUM OF THE FIGURES PROVIDED IN THE TABLE. (my emphasis added. From iAPX86/88 User's Manual pg 2-51) It would seem that Mr. Elliott does not understand the meaning of the word "typically", and he also has problems with selective reading (he only sees what he wants to). As Intel's documentation states the execution times CAN be longer than than the typical times given, However, both our customer's and our benchmarks show this is NOT the case in MOST code. What Mr. Elliott has done is made an improper generalization of one worst case example. I feel that transmitting an article such as Mr. Elliott's on a nation-wide network was a terribly irresponsible thing to do, since Mr. Elliott didn't seem to bother to get his facts straight first. -- Edward Zager, Intel, Santa Clara, Ca. {pur-ee,hplabs,ucbvax!amd70,ogcvax!omsvax}!intelca!ez
freund@nsc.UUCP (Bob Freund) (04/27/84)
Getting pretty sensitive, aren't we. Bob Freund National Semiconductor
rpk@ecsvax.UUCP (04/30/84)
[ 0000H <-- hex sign to ward off evil mailers ] It would be nice if Intel could ship microprocessors as quickly as their employees respond to net criticism. -Dick ...decvax!mcnc!ecsvax!rpk
gwes@inmet.UUCP (05/01/84)
#R:intelca:-25300:inmet:5800050:000:1808 inmet!gwes Apr 30 16:15:00 1984 -Null cosmos est- Re "typical" speeds & instruction mixes: Mr. Elliott has a point: Chip manufacturers have habitually exaggerated the real usefulness of their products by publishing "typical" timings in BIG print, and the minimum/maximum (as appropriate) in small print in the back of the spec sheet. Anyone who reads such a spec sheet should look VERY carefully for the words "minimum", "maximum", and especially "guaranteed". I have tested four computer models for real execution speed, both in standalone tests and "typical mixes". Of course, my typical mix is not the manufacturers' - I just took the three or four programs which showed up on accounting runs as taking the major (.gt. 50%) of system time. In all cases the manufacturers' timings were optimistic, usually by 30% or more. The reaction of the Intel person (sorry, name rolled off screen) is unfortunate at best. Data sheets should CLEARLY represent the real extremes of performance. Recently Fairchild and Texas Instruments have begun documenting their AS, FAST, and ALS TTL lines with MIN and MAX times only - no "typical". This is a great service to the engineering community and should be taken up by all manufacturers. Too often I have had to "fix" a design in which the engineer believed the "typical" timings. One reason to use a machine like the 286 would be for very high speed manipulations - perhaps as a coprocessor to a 68K or other useful machine. (Prejudice shows here...) The fact that hand-coding a high speed loop might have no effect because the prefetch was defeated would be an expensive lesson to learn. In short - marketing "hype" has no place on data sheets - guaranteed performance should be the data in big print. The "typical mix" is mostly mythical. Geoff Steckel (inmet!gwes or ima!inmet!gwes)