tombs@ee.rochester.edu (Thomas Tombs) (10/10/90)
Here are the results I got with my A3000-25/50 under AMAXII running 'Speedometer 2.5' compared to various Mac's running the same program: Note: Values in parentheses indicate Floating point unit was NOT used. Higher values indicate better performance except for the Sieve and Savage tests. A3000/25/50 MacIIci MacIIcx MAC+ ------------------------------------------------------- KWhetstones/sec 882.4(39.4) - 588.2(60.3) (7.37) Dhrystones/sec 2871(2717) - 3736(3816) (768.8) Sieve (sec) 3.70(3.83) - 6.00(5.98) (40.03) Savage Cum. Error 7.988e-10 - 7.988e-10 (2.297e-11) (2.297e-11) - (2.297e-11) - Savage Time (sec) 8.52(71.43) - 11.13(40.27) (385.4) Savage Iterations 25000(5000) - 25000(5000) (5000) CPU test (6.40) (5.15) (4.25) (.87) Math test 95.27(5.24) (9.79) 95.27(7.82) (1.02) Hard disk test 2.69 3.42 2.95 - Performance (5.42) (5.73) (4.96) - rating tom
daveh@cbmvax.commodore.com (Dave Haynie) (10/10/90)
In article <1990Oct9.184447.4539@ee.rochester.edu> tombs@ee.rochester.edu writes: >Here are the results I got with my A3000-25/50 under AMAXII running >'Speedometer 2.5' compared to various Mac's running the same program: > A3000/25/50 MacIIci MacIIcx MAC+ > ------------------------------------------------------- >Dhrystones/sec 2871(2717) 3736(3816) (768.8) The Dhrystone test doesn't use any floating point. But the results do say a few things. First, that AMAX seems to be taking on a bit more overhead than I would have expected. Secondly, that the compiler used here was lousy; typical A3000 Dhrystone 2.1 numbers are in the 5000-8000 range, depending on C compiler and settings. >tom -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
navas@cory.Berkeley.EDU (David C. Navas) (10/11/90)
In article <15009@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1990Oct9.184447.4539@ee.rochester.edu> tombs@ee.rochester.edu writes: >> A3000/25/50 MacIIci MacIIcx MAC+ >>Dhrys/sec 2871(2717) 3736(3816) (768.8) >The Dhrystone test doesn't use any floating point. But the results do say >a few things. First, that AMAX seems to be taking on a bit more overhead >than I would have expected. Hmmm... Sure that this test was running in FAST and not CHIP memory? That might just account for a few differences. You'll need something to soak up 1 to 2 megs BEFORE you try running the Dhrystone benchmark... >Secondly, that the compiler used here was lousy; >typical A3000 Dhrystone 2.1 numbers are in the 5000-8000 range, depending on >C compiler and settings. Yep, that's true -- these are the worst figures I've seen since, well since a long time ago... Even for the Mac Plus, that's not too good. David Navas navas@sim.berkeley.edu "Excuse my ignorance, but I've been run over by my train of thought." -me
martin@cbmvax.commodore.com (Martin Hunt) (10/11/90)
In article <28676@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: > > >In article <15009@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1990Oct9.184447.4539@ee.rochester.edu> tombs@ee.rochester.edu writes: >>> A3000/25/50 MacIIci MacIIcx MAC+ >>>Dhrys/sec 2871(2717) 3736(3816) (768.8) > >>The Dhrystone test doesn't use any floating point. But the results do say >>a few things. First, that AMAX seems to be taking on a bit more overhead >>than I would have expected. > >Hmmm... Sure that this test was running in FAST and not CHIP memory? That >might just account for a few differences. You'll need something to soak >up 1 to 2 megs BEFORE you try running the Dhrystone benchmark... Fast RAM is used BEFORE Chip RAM, so the problem is most likely that something is using up all the Fast RAM. In the case of a stock 2M 3000, that something is the 2.0 OS. Because ROMs are not out yet, the ROM image is loaded off disk, using up 512K of your 1M fast RAM. With other OS processes using up fast RAM, you are lucky if you have a useful amount when you are finished booting. This is a very common cause of slow benchmarks on 3000s. > > >David Navas navas@sim.berkeley.edu >"Excuse my ignorance, but I've been run over by my train of thought." -me Martin Martin Hunt martin@cbmvax.commodore.com Network Engineer connectivity <==> power Commodore-Amiga {uunet|pyramid|rutgers}!cbmvax!martin
stefanb@cip-s01.informatik.rwth-aachen.de (Stefan Becker) (10/11/90)
daveh@cbmvax.commodore.com (Dave Haynie) writes: >> A3000/25/50 MacIIci MacIIcx MAC+ >> ------------------------------------------------------- >>Dhrystones/sec 2871(2717) 3736(3816) (768.8) >The Dhrystone test doesn't use any floating point. But the results do say >a few things. First, that AMAX seems to be taking on a bit more overhead >than I would have expected. Secondly, that the compiler used here was lousy; >typical A3000 Dhrystone 2.1 numbers are in the 5000-8000 range, depending on >C compiler and settings. I used GNU CC 1.37.1 and got 7700 DS/s. Are you sure that your Dhrystone program did run in REAL fast mem? Chip mem figures are typically only a third of the fast mem ones. Stefan Mail : Stefan Becker, Holsteinstrasse 9, W-5100 Aachen /// Only Phone : +49-241-505705 FIDO: 2:242/7.6 Germany /// Amiga makes Domain: stefanb@cip-s02.informatik.rwth-aachen.de \\\/// it possible.. Bang : ..mcvax!unido!rwthinf!cip-s02!stefanb \XX/ -->A3000/25<--
jesup@cbmvax.commodore.com (Randell Jesup) (10/12/90)
In article <15070@cbmvax.commodore.com> martin@cbmvax.commodore.com (Martin Hunt) writes: >>>In article <1990Oct9.184447.4539@ee.rochester.edu> tombs@ee.rochester.edu writes: >>>> A3000/25/50 MacIIci MacIIcx MAC+ >>>>Dhrys/sec 2871(2717) 3736(3816) (768.8) >> >>>The Dhrystone test doesn't use any floating point. But the results do say >>>a few things. First, that AMAX seems to be taking on a bit more overhead >>>than I would have expected. >Fast RAM is used BEFORE Chip RAM, so the problem is most likely that >something is using up all the Fast RAM. In the case of a stock 2M >3000, that something is the 2.0 OS. Because ROMs are not out yet, the >ROM image is loaded off disk, using up 512K of your 1M fast RAM. With >other OS processes using up fast RAM, you are lucky if you have a useful >amount when you are finished booting. This is a very common cause of >slow benchmarks on 3000s. Also, Amax may not be able to use memory above the 16M boundary, since Mac programs (and maybe the OS as well) have in the past tended to use the top byte for flag information, etc. Only recently has there been a push towards "32-bit-clean" programming there. Martin is correct that if it's a 1M fast/1M chip machine, it may not have a lot of fast memory left for amax under the current MMU rom-images. With real roms there will be another 512K of fast ram available (at least under 2.0). The A3000 fastmem is in the 0x07xxxxxx range. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
JKT100@psuvm.psu.edu (JKT) (10/12/90)
In article <stefanb.655655538@cip-s01>, stefanb@cip-s01.informatik.rwth-aachen.de (Stefan Becker) says: > >daveh@cbmvax.commodore.com (Dave Haynie) writes: >>> A3000/25/50 MacIIci MacIIcx MAC+ >>> >>>--------------------------------------------------------------------- >>>Dhrystones/sec 2871(2717) 3736(3816) (768.8) > >>The Dhrystone test doesn't use any floating point. But the results do say >>a few things. First, that AMAX seems to be taking on a bit more overhead >>than I would have expected. Secondly, that the compiler used here was lousy; >>typical A3000 Dhrystone 2.1 numbers are in the 5000-8000 range, depending on >>C compiler and settings. > (couple of postings deleted about making sure the test runs in FAST, not chip RAM) It's my understanding that the tests listed under the "A3000-25/50" column were run in A-Max II mode, not under AmigaDOS. As such, there is no way to control what type of memory they run in, and to be honest, I doubt it would make as much of a difference in Mac mode as it would in Amiga mode. Myself, I am quite impressed with these results. An EMULATION of a MAC PLUS stands up to a Mac IIcx in speed!! This ought to make Apple squirm.... Kurt -- ----------------------------------------------------------------------- || Kurt Tappe (215) 363-9485 || Amigas, Macs, IBM's, C-64's, NeXTs, || || 184 W. Valley Hill Rd. || Apple ]['s.... I use 'em all. || || Malvern, PA 19355-2214 || (and in that order too! ;-) || || jkt100@psuvm.psu.edu --------------------------------------|| || jkt100@psuvm.bitnet jkt100%psuvm.bitnet@psuvax1 QLink: KurtTappe || -----------------------------------------------------------------------
navas@cory.Berkeley.EDU (David C. Navas) (10/14/90)
In article jesup@cbmvax.commodore.com (Randell Jesup) writes: >In article martin@cbmvax.commodore.com (Martin Hunt) writes: >>>>In article tombs@ee.rochester.edu writes: >>>>> A3000/25/50 MacIIci MacIIcx MAC+ >>>>>Dhrys/sec 2871(2717) 3736(3816) (768.8) >>> >>Fast RAM is used BEFORE Chip RAM, so the problem is most likely that >>something is using up all the Fast RAM. In the case of a stock 2M > Also, Amax may not be able to use memory above the 16M boundary, >..for amax under the current MMU rom-images. With real roms there will be >another 512K of fast ram available (at least under 2.0). Well, 512K if you don't run your startup-sequence :) First off, Martin is certainly correct in saying that the Amiga OS allocates FAST then CHIP (assuming you ask AllocMem to alloc some general purpose mem), but the Mac works somewhat differently. Not willing to stick foot into mouth, I'll just say that I always thought the Mac assumed contiguous memory, which makes it seem likely to me that they allocate memory from low t'high addresses. I would hope that AMax fixed the 16M boundry, at least by doing some MMU magic.... I've got AMax, and haven't used it except to impress some Mac weenie at school. [Lord knows there are enough of 'em.] David Navas navas@sim.berkeley.edu "Excuse my ignorance, but I've been run over by my train of thought." -me
daveh@cbmvax.commodore.com (Dave Haynie) (10/16/90)
In article <28676@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes: >In article <15009@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >>In article <1990Oct9.184447.4539@ee.rochester.edu> tombs@ee.rochester.edu writes: >>> A3000/25/50 MacIIci MacIIcx MAC+ >>>Dhrys/sec 2871(2717) 3736(3816) (768.8) >>The Dhrystone test doesn't use any floating point. ... >Hmmm... Sure that this test was running in FAST and not CHIP memory? That >might just account for a few differences. You'll need something to soak >up 1 to 2 megs BEFORE you try running the Dhrystone benchmark... As a matter of fact, it probably isn't using Fast memory. The current Mac OS requires 24 bit addressing. A3000 motherboard Fast memory lives in the $07000000-$07ffffff range, which would be trouble for a Mac unless the Readysoft folks were clever enough to map some of this Fast memory into 24 bit space by way of the MMU. And if that's the case, it would require even more cleverness to make that the first memory used -- Macs don't deal with memory in quite as sophisticated a way as Amigas. >David Navas navas@sim.berkeley.edu -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM
daveh@cbmvax.commodore.com (Dave Haynie) (10/17/90)
In article <90284.230747JKT100@psuvm.psu.edu> JKT100@psuvm.psu.edu (JKT) writes: >It's my understanding that the tests listed under the "A3000-25/50" >column were run in A-Max II mode, not under AmigaDOS. As such, there is >no way to control what type of memory they run in, and to be honest, >I doubt it would make as much of a difference in Mac mode as it would >in Amiga mode. Myself, I am quite impressed with these results. An >EMULATION of a MAC PLUS stands up to a Mac IIcx in speed!! Realize that AMAX isn't really much of an emulator. I call this kind of thing a "hostile port" of the Macintosh OS. Basically, an Amiga has most if not all of the proper hardware to run the Mac OS, only Apple doesn't think that it should. So the clever folks at Readysoft have, without Apple's blessing of course, found a way to port this OS over to the Amiga. They may have to emulate some of the Apple hardware, or perhaps not, depending on the Apple OS and what you can change around when you don't have the Mac OS source code. Contrast this to true emulations, such as the C64 (Go-64, The C64 Emulator) or PC-Clone (The Transformer). In both of these, you have very hardware specific "operating systems" which aren't 68000 based. The programs must emulate the CPU, video display, keyboard controller chip, etc. The emulations with both of these must extend to bit-level hardware emulations, since these machines typically allow application programs to bang on the hardware. Emulating the Atari ST would be a hybrid system. Getting the actual ST OS to run on an Amiga is more of a hostile port than anything else. But if you want color screens, it would be necessary to emulate the ST's video control registers, and worse, the ST video display, which is a packed pixel display rather than a bitplane display as on the Amiga. There are probably other bits of ST registers that would have to be emulated at the hardware level, too. >|| Kurt Tappe (215) 363-9485 || Amigas, Macs, IBM's, C-64's, NeXTs, || -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Standing on the shoulders of giants leaves me cold -REM