jclee@sdcc13.ucsd.edu (Jimmy Lee) (04/17/91)
What is the difference, in terms of preformance, between the Mac+ and the SE? I heard that the SE is 25 percent fast, but in what area? I have a P40S Quantum drive hook up to the Mac+ and I don't seem to notice any difference. They (Apple dealers) said that the SE will beat a Mac+ anytime. Is that true? Does anyone have any information on the public domain software called SCSI Accelerator? I am currently use it and have notice a big improvement. One last question: Even though I have a fast Quantum, the time it takes to duplicate a file like MS Word is still slower than a SE with a 20mb, 73ms seek time Miniscribe drive. Why is this so? How can I improve on this? :zz
john@newave.UUCP (John A. Weeks III) (04/20/91)
In article <18359@sdcc6.ucsd.edu> jclee@sdcc13.ucsd.edu (Jimmy Lee) writes: > What is the difference, in terms of preformance, between the Mac+ > and the SE? I was curious when the SE was introduced, so I wrote a benchmark program in Turbo Pascal and ran it on both machines. For a program that did lots of integer and floating point math, some recursion, and a few array sorts, I was not able to measure any run time difference even though my program ran for about 3 minutes on each machine. The clock speed of the SE and Mac + are the same. The I/O circuitry is a bit different, so the SE can read from the SCSI bus a bit faster. As a result, the SE can run with a 2:1 harddrive interleave, where the Mac + needed 3:1. But for all practical difference, there is no real speed difference between the Mac + and the SE. At least not a difference worth nit picking about. -john- -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ John A. Weeks III (612) 942-6969 john@newave.mn.org NeWave Communications ...uunet!tcnet!wd0gol!newave!john
das@eplunix.UUCP (David Steffens) (04/24/91)
In article <764@newave.UUCP>, john@newave.UUCP (John A. Weeks III) says: > But for all practical difference, there is no real speed difference between > the Mac + and the SE. At least not a difference worth nit picking about. Wrong. The SE has more of QuickDraw in ROM. Code in ROM executes twice as fast as code in RAM because the video refresh uses every other RAM cycle. Therefore, a benchmark which does lots of QuickDraw calls _will_ show a speed difference favoring the SE over the Plus by about 30-50% depending on the exact mix. This will also be noticeable to the user when running programs which do a lot of QuickDraw operations. Your mileage may vary. Tested using some heavy-duty graphics programming assigments for a course in computer graphics. -- David Allan Steffens | I believe in learning from past mistakes... Eaton-Peabody Laboratory | ...but does a good education require so many? Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114 {harvard,mit-eddie,think}!eplunix!das (617) 573-3748 (1400-1900h EST)
jcav@quads.uchicago.edu (john cavallino) (04/26/91)
In article <1068@eplunix.UUCP> das@eplunix.UUCP (David Steffens) writes: >In article <764@newave.UUCP>, john@newave.UUCP (John A. Weeks III) says: >> But for all practical difference, there is no real speed difference between >> the Mac + and the SE. At least not a difference worth nit picking about. > >Wrong. The SE has more of QuickDraw in ROM. Code in ROM executes >twice as fast as code in RAM because the video refresh uses every >other RAM cycle. Therefore, a benchmark which does lots of QuickDraw >calls _will_ show a speed difference favoring the SE over the Plus >by about 30-50% depending on the exact mix. This will also be noticeable >to the user when running programs which do a lot of QuickDraw operations. That's all well and good, but there are some hardware differences that make the SE noticably (to me) more comfortable to work with. The most important of these is the speed of the SCSI interface. The SE will talk to hard disks etc. well over twice as fast as the Plus. This is VERY important. The other difference is in how many memory access cycles are stolen to refresh the video display. The SE wastes 30% less time this way than does the Plus, which leads to about a 15% speed increase. I think these differences, especially the SCSI speed, are more than nit-picky. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ w c+ g+ k s(+) e+ h- pv | Telephone: 312-702-6900
amichiel@rodan.acs.syr.edu (Allen J Michielsen) (04/26/91)
In article <1068@eplunix.UUCP> das@eplunix.UUCP (David Steffens) writes: >In article <764@newave.UUCP>, john@newave.UUCP (John A. Weeks III) says: >> But for all practical difference, there is no real speed difference between >> the Mac + and the SE. At least not a difference worth nit picking about. > >Wrong. The SE has more of QuickDraw in ROM. Code in ROM executes >twice as fast as code in RAM... a speed difference the SE over the Plus >by about 30-50% depending on the exact mix. This will also be noticeable >to the user when running programs which do a lot of QuickDraw operations. Wrong. Code in ROM executes SLOWER because of the slow access times of the roms themselves. If this weren't the case, you wouldn't see a drastic system improvement when you copy rom to ram (and you do, period). However, you were close, ROM Quickdraw is faster than system / RAM Quickdraw because of system overhead (Part of which IS the interaction between ram access and video refresh). I'm also not conviced that all Quickdraw ROM routines are loaded into ram by the system, they either are probably loaded as required or when required, or generated as needed. ANyway, you are right when you see a pickup in quickdraw routines on the se, but not for the reason stated (or improperly stated). However, generally the original poster was fairly accurate, if you look at a typical user using a typical mix of applications in typical fashion in a typical environment. The difference is pretty small overall. IF however, the user mix were using QuickDraw intensive applications, the difference would be noticeable. al -- Al. Michielsen, Mechanical & Aerospace Engineering, Syracuse University InterNet: amichiel@rodan.acs.syr.edu amichiel@sunrise.acs.syr.edu Bitnet: AMICHIEL@SUNRISE
amanda@visix.com (Amanda Walker) (04/27/91)
In article <1991Apr26.153645.5151@rodan.acs.syr.edu> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: Wrong. Code in ROM executes SLOWER because of the slow access times of the roms themselves. If this weren't the case, you wouldn't see a drastic system improvement when you copy rom to ram (and you do, period). Bzzzzzt. Thank you for playing. On the Macintosh Plus and SE (which the original poster was discussing), ROM accesses are indeed faster than RAM accesses. RAM is time-division multiplexed between the CPU and the video circuitry, while the ROM is not. Since accessing RAM incurs up to four additional wait states, aggregate ROM execution speed is (on average) from one one and a half to two times faster than RAM, depending on stack and other RAM usage. Check out the timing diagrams if you don't believe me. -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "An architecture in hand is worth 4 or 5 in vapor." --Eugene Miya
peirce@outpost.UUCP (Michael Peirce) (04/27/91)
In article <1991Apr26.191830.18589@visix.com>, amanda@visix.com (Amanda Walker) writes: > > In article <1991Apr26.153645.5151@rodan.acs.syr.edu> > amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: > > Wrong. Code in ROM executes SLOWER because of the slow access > times of the roms themselves. If this weren't the case, you > wouldn't see a drastic system improvement when you copy rom to ram > (and you do, period). > > Bzzzzzt. Thank you for playing. > > On the Macintosh Plus and SE (which the original poster was discussing), > ROM accesses are indeed faster than RAM accesses. RAM is time-division > multiplexed between the CPU and the video circuitry, while the ROM is > not. Since accessing RAM incurs up to four additional wait states, aggregate > ROM execution speed is (on average) from one one and a half to two > times faster than RAM, depending on stack and other RAM usage. This is a PC-ism. Some PC clone machines do have ROM that is slower than their RAM. But you are right, Macs don't. -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
dbert@mole.gnu.ai.mit.edu (Douglas Siebert) (04/28/91)
In article <0B010004.a56ymb@outpost.UUCP> peirce@outpost.UUCP writes: > >In article <1991Apr26.191830.18589@visix.com>, amanda@visix.com (Amanda Walker) writes: >> >> In article <1991Apr26.153645.5151@rodan.acs.syr.edu> >> amichiel@rodan.acs.syr.edu (Allen J Michielsen) writes: >> >> Wrong. Code in ROM executes SLOWER because of the slow access >> times of the roms themselves. If this weren't the case, you >> wouldn't see a drastic system improvement when you copy rom to ram >> (and you do, period). >> >> Bzzzzzt. Thank you for playing. >> >> On the Macintosh Plus and SE (which the original poster was discussing), >> ROM accesses are indeed faster than RAM accesses. RAM is time-division >> multiplexed between the CPU and the video circuitry, while the ROM is >> not. Since accessing RAM incurs up to four additional wait states, aggregate >> ROM execution speed is (on average) from one one and a half to two >> times faster than RAM, depending on stack and other RAM usage. > >This is a PC-ism. Some PC clone machines do have ROM that is slower >than their RAM. But you are right, Macs don't. I just checked my Mac Plus (4M, rev. 2 ROMs) with Speedometer 2.5, which will supposedly test a machine against a "standard Mac SE with 20 meg HD" The results were (using 1.00 as the SE's score) CPU 0.82, math 1.02, and disk 6.72 (I used a RAMdisk for the test :) ) The CPU score is pretty much like most people expected, but the math being a bit faster has me confused... -- Doug Siebert | dbert@gnu.ai.mit.edu MBA Student (2nd year) | "All opinions expressed herein are obviously (starting MS in CS this fall?) | superior to yours or you wouldn't have need The University of Iowa | to be reading this, now would you?" :-)
lsr@Apple.com (Larry Rosenstein) (05/03/91)
In article <1991Apr26.191830.18589@visix.com>, amanda@visix.com (Amanda Walker) writes: > > On the Macintosh Plus and SE (which the original poster was discussing), > ROM accesses are indeed faster than RAM accesses. RAM is time-division > multiplexed between the CPU and the video circuitry, while the ROM is > not. I thought that some of the speed improvement of the SE vs. the Plus was that fewer CPU cycles were stolen by the video on the SE.
ostroff@Oswego.EDU (Boyd Ostroff) (05/04/91)
In article <13304@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >I thought that some of the speed >improvement of the SE vs. the Plus was that fewer CPU cycles were stolen by >the video on the SE. I recall reading this too; I think BYTE did an article on the SE explaining all this back in '87 - unfortunately my old issues don't go back that far. I did dig around a dusty pile of old stuff, though and found an Apple Brochure on the SE which states: +--------------------------------------------------------------------- |"RAM access speed has been improved 15-20% over the Mac Plus. A custom |chip in the Macintosh SE performs many basic Macintosh functions and |improves application and SCSI performance..." | |"SCSI throughput performance has been improved up to two times over the |Macintosh Plus" +--------------------------------------------------------------------- Also found the Spring 1987 issue of "Wheels for the Mind" (remember that?) which has a "Questions and Answers" section on the SE: +--------------------------------------------------------------------- |"IS THE PERFORMANCE OF THE MACINTOSH SE DIFFERENT THAN THAT OF THE |MACINTOSH PLUS? | |Yes. The CPU performance has been improved by about 20 percent, and |the internal SCSI performance has been increased by a factor of 2. |Part of the reason for this improvement was the development of a new |SCSI 'manager'. For example, there is now a hardware handshake line |(it used to be done in software). All toolbox routines have also been |enhanced." +--------------------------------------------------------------------- Just thought this might be of interest - it's official Apple "party line" from their own publications.... THEIR opinions, not necessarily MINE! |||| Boyd Ostroff / Tech Director / SUNY Oswego Dept of Theatre / 315-341-2987 |||| Sys Admin at cboard.UUCP / Serving the Performing Arts / 315-947-6414/8N1 |||| ostroff@oswego.oswego.edu / cboard!ostroff@natasha.oswego.edu
rbailey@kinetics.com (Robert Bailey) (05/08/91)
The News Manager) Nntp-Posting-Host: plasma Reply-To: rbailey@wc.novell.com Organization: Novell, Inc. References: <764@newave.UUCP> <1068@eplunix.UUCP> <1991Apr26.191830.18589@visix.com> <13304@goofy.Apple.COM> Distribution: usa Date: 3 May 91 01:25:40 GMT In <13304@goofy.Apple.COM> lsr@Apple.com (Larry Rosenstein) writes: >I thought that some of the speed >improvement of the SE vs. the Plus was that fewer CPU cycles were stolen by >the video on the SE. I think that the Plus uses a 16-bit shift register that has to be filled every 4 memory cycles, while the SE uses a 32-bit shift register that only has to be filled every 8 cycles. This gives you 7/8 of your memory bandwidth instead of 3/4. I think this completely accounts for the reported ~15% performance increase of the SE. Of course, the SE has other significant advantages as well... Robert Bailey rbailey@wc.novell.com =============================================================================== Robert Bailey Voice: (415) 975-4500 Novell, Inc. Internet: rbailey@wc.novell.com 1340 Treat Blvd. Suite 500 UUCP: ucbvax!mtxinu!kinetics!rbailey Walnut Creek, CA 94596 ===============================================================================