tsc2597@acf4.UUCP (Sam Chin) (05/29/85)
<>
For interests sake, I benchmarked a S-100 machine with an 8 Mhz 8086 using
the Harmonic series benchmark proposed a few articles ago. Using Microsoft
C Version 3.00, I got:
9.787613 using float and it took 13 seconds
9.787606 using double and it took 14 seconds
I took out the CPU board, lowered the clock rate to 5 Mhz and plugged in the
8087 floating point processor and reran the benchmarks. It gave the same
results and took less than 1 second in each case. Although these times
(even the software floating point) are faster than the Mac with a 8 Mhz
68000 (Using C), it doesn't mean that for the same clock speed that the 8086
is faster than the 68000 but rather that Microsoft did a better job in
implementing the floating point on their C compiler.
Sam Chin
allegra!cmcl2!acf4!tsc2597
tsc2597.acf4@nyugmp@rayssd.UUCP (Gregory M. Paris) (06/02/85)
> From: tsc2597@acf4.UUCP (Sam Chin) > > ... Although these times > (even the software floating point) are faster than the Mac with a 8 Mhz > 68000 (Using C), it doesn't mean that for the same clock speed that the 8086 > is faster than the 68000 but rather that Microsoft did a better job in > implementing the floating point on their C compiler. It doesn't have to mean that at all. It probably means that the Mac is slower because half of it's clock cycles are given up to the video hardware. The effective 68000 clock rate is only 4Mhz. -- ++--------------------------------------------------------------------------++ || Gregory M. Paris || || ...!{allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++--------------------------------------------------------------------------++
ech@spuxll.UUCP (Ned Horvath) (06/04/85)
This "statistic" gets misstated so often it's almost funny. The facts, direct from Apple: - Video refresh consumes at most 25% of the memory cycles, leaving you with (at worst) a 6 MHz 68000. - Video refresh cycle-stealing does NOT lock out ROM references, so when running in the toolbox (which is a large fraction of time for many applications) loss due to the refresh is considerably reduced. Despite which, when/if Apple markets a Mac with a faster 68k, I would hope that they would put the screen memory in a separate dual-port memory. =Ned=
planting@uwvax.UUCP (W. Harry Plantinga) (06/04/85)
> From Gregory M. Paris: > > It doesn't have to mean that at all. It probably means that the Mac is > slower because half of it's clock cycles are given up to the video hardware. > The effective 68000 clock rate is only 4Mhz. People seem to like to say "The effective 68000 clock rate is only x MHz" where the x is replaced by some number from 3 to 7 depending on the person's opinion of the mac. According to Byte mag, it's around 6 MHz, more if you are doing graphics or some other type of program which spends lots of time in rom. Incidentally, one may not like it that the clock speed is effectively lowered, but bear in mind that the I*M PC/AT has a clock speed of 6 MHz with one wait state. (:-) -Harry Plantinga {seismo,allegra,ihnp4,heurikon}!uwavx!planting planting@wisc-rsch.arpa
jer@peora.UUCP (J. Eric Roskos) (06/07/85)
>> It doesn't have to mean that at all. It probably means that the Mac is >> slower because half of it's clock cycles are given up to the video hardware. >> The effective 68000 clock rate is only 4Mhz. > >People seem to like to say "The effective 68000 clock rate is only x MHz" >where the x is replaced by some number from 3 to 7 depending on the >person's opinion of the mac. But there's really nothing wrong with saying what the effective clock rate is; it should have nothing to do with your opinion of the MAC. What it has to do with is how much of your program executes in ROM and how much in RAM. The original statement above is definitely wrong, first of all. The video "steals" cycles from the CPU only for part of the time (roughly proportional to the ratio of the time the CRT beam is writing on the screen to the sum of that time plus the time the beam is doing horizontal and vertical retraces). Nowhere near "half" the cycles are given up to the video hardware. Furthermore, this only happens when the CPU tries to access dynamic RAM while the display is accessing it, so when the CPU is executing from ROM, the delays don't occur. There's something else you have to consider, too, though, in comparing to the IBM PC (which the referenced message later did). The IBM PC has its DMA controller programmed to periodically do a dummy DMA transfer to refresh the dynamic RAM. The length of the transfer is sufficient to scan all the combinations of the [row or column, I forget which] addresses in the memory array. It does this fairly often, and takes a good bit of time. On the Mac, the video RAM accessing does this for you, so you don't have the dummy DMAs taking up time. (However, the IBM PC's refresh time takes significantly less time than the Mac's video-accessing time). -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Zl FB vf n xvyyre junyr."
gmp@rayssd.UUCP (Gregory M. Paris) (06/08/85)
> From: -Harry Plantinga > > People seem to like to say "The effective 68000 clock rate is only x MHz" > where the x is replaced by some number from 3 to 7 depending on the > person's opinion of the mac. > > According to Byte mag, it's around 6 MHz, more if you are doing > graphics or some other type of program which spends lots of time in > rom. > My figure of 4 MHz was based entirely on the article I was following-up to. (I think that poster was correct about the 8 MHz clock though; I don't think that Apple is using the 10 MHz or 12 MHz 68000 chips.) From a hardware standpoint, the effective clock rate *IS* 4 MHz. That says virtually nothing about the performance of the MAC relative to any other computer. The intent of my article was to correct the poster's erroneous assumption about the writers of the compiler he was using. -- ++--------------------------------------------------------------------------++ || Gregory M. Paris || || ...!{allegra,linus,raybed2,ccice5,brunix}!rayssd!gmp || ++--------------------------------------------------------------------------++
e-smith@utah-cs.UUCP (Eric L. Smith) (06/10/85)
Someone correct me if I'm wrong, but... {just waiting for the flames about
math and spelling errors!}
All timing in the Macintosh operates at a master clock rate of 15.67 MHz.
This is divided by two to get the CPU clock, 7.83 MHz. The 68000 requires
a minimum of 4 clock cycles (8 master clock cycles) to complete a memory
access. The video/sound/disk speed circuitry also takes 8 master clock
cycles per memory access. The catch is, when the 68K tries to access the
RAM, if a video access is in progress, or is about to start, it has to wait.
The Mac displays active video on 342 out of 370 scan lines, and on each scan
line there are 32 (512/16) video accesses or 256 master clock cycles out of
704 master clock cycles total per scan line (44*16, where 44 is the total
number of words (16-bit) per scan line). Audio and disk speed take 1 video
access on *every* scan line (all 370). This means that the total number of
clock cycles eaten by video, audio, and disk speed per video frame is
(32*342+370)*8, or 90,512, out of 704*370, or 260,480 clock cycles, for an
overhead of only 34.75%. The only remaining problem is that out of the
remaining 65.25% of the time, the 68K has to waste some of the available
cycles for synchronization, for instance if a memory access is initiated one
cycle before a video access begins, that cycle is wasted.
-------------------------------------------------------------------------------
Eric L. Smith (801) 581-8100 e-smith@utah-cs.arpa ...decvax!utah-cs!e-smith
3118 Merrill Engineering, University of Utah, Salt Lake City, UT 84112
The opinions expressed herein do not necessarily represent those of the
University of Utah, my friends, enemies, computer, or even me. :-)
If everyone would dare to be stupid, what a stupid world this would be.
-- Wierd Al Yankovic
--
-------------------------------------------------------------------------------
Eric L. Smith (801) 581-8100 e-smith@utah-cs.arpa ...decvax!utah-cs!e-smith
3118 Merrill Engineering, University of Utah, Salt Lake City, UT 84112
The opinions expressed herein do not necessarily represent those of the
University of Utah, my friends, enemies, computer, or even me. :-)