kuo@tramp.Colorado.EDU (Andy Y.A. Kuo) (10/16/89)
In article <8910111039.AA15764@trout.nosc.mil> jabernathy@pro-houston.cts.com (Joe Abernathy) writes: >[...lines deleted...] >(In particular, the formula is always Macintosh >MHz/4 = Apple II.) >[...lined deleted...] >publishing -- machines such as the Apple II and IBM clones have a dramatic >performance advantage over Macintosh. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >[....lines deleted...] >is generally: IBM MHz/5 = Apple II I was just wondering, if these hardware(?) conversion is true, then the speed of a (4Mhz AppleII)=(16Mhz Mac)=(20Mhz IBM). Which means a Mac is faster than IBM(at the same Mhz), but you also mentioned that IBM clones have dramatic performance advantage over Mac. Is the conversion wrong? Also, do you mean you run GS/OS, windows..etc on the GS or plain text?
brianw@microsoft.UUCP (Brian Willoughby) (10/17/89)
In article <12787@boulder.Colorado.EDU> kuo@tramp.Colorado.EDU (Andy Y.A. Kuo) writes: >In article <8910111039.AA15764@trout.nosc.mil> jabernathy@pro-houston.cts.com (Joe Abernathy) writes: > >I was just wondering, if these hardware(?) conversion is true, then >the speed of a (4Mhz AppleII)=(16Mhz Mac)=(20Mhz IBM). > >Which means a Mac is faster than IBM(at the same Mhz), but you also >mentioned that IBM clones have dramatic performance advantage over Mac. > >Is the conversion wrong? I don't know if I want to agree with Joe without reservations (see below) but that makes sense. Just because the Mac is capable of being faster at the same clock speed does not mean that the OS/Application allow it to perform at its peak. Consider that the Mac has to tediously draw every pixel in every character, while the IBM can utilize video hardware to handle characters in the text graphics modes. I also tend to think that the Mac OS impedes performance. Have any of you ever dissabled the A-line trap code and counted how many instructions are executed on every single system call? There's a lot of potential power wasted in making the App work with system subroutines which can move from ROM to RAM from one system release to another. Most IBM processor instructions are longer, take longer to fetch, and have fewer internal registers available (none of which are general purpose anyway). But I wouldn't agree on any static multiplier, since the 8 MHz Macs are actually executing at different speeds. The Mac Plus 68000 sees RAM 50% of the time, and often ends up with video wait states. The Mac SE was improved so that the 68000 see RAM 75% of the time, with approximately half the wait states. The SE/30, which is a 16 MHz machine has dual-port video RAMs and never cause the 68030 to see a wait state. If the SE/30 were 8 MHz, it would still burn the regular SE. Regarding the Apple II MHz = 4 times MAC, I did my own limited benchmark which almost supports this. I was programming sound digitizing routines on my Apple and pondering what it would be like on a Mac. So I wrote the exact same loop (intended to iterate at 40,000 times per second) with each instruction set. In this single example, the 6502 was twice as fast as an identically clocked 68000. The only reason it was 2 instead of around 4 is probably because the entire loop used 68000 registers only, which were loaded before the loop, while the 6502 used 'registers' in zero page. Judging from that experience, and the fact that most full applications could not possibly keep ALL variables in registers (especially considering subroutine and/or system calls), I would say that the 6502 is roughly four times as 'efficient' at using its cycles as the 68000. I arrived at that because the 6502 could handle many more variables without slowing down its rate of access, but that the 68000 would take a performance hit once you started loading and saving registers between memory and processor. Disclaimer - I don't think my limited benchmark could possibly take all systems into account. I was assuming zero wait states on all 68000 memory accesses. A 3.58 MHz Apple might actually be as fast as an 8 MHz Mac Plus when you consider that the 68000 cannot access RAM 50% of the time, and there is already a two times efficiency comparison (by my benchmark). Brian Willoughby UUCP: ...!{tikal, sun, uunet, elwood}!microsoft!brianw InterNet: microsoft!brianw@uunet.UU.NET or: microsoft!brianw@Sun.COM Bitnet brianw@microsoft.UUCP