martin@cbmvax.commodore.com (Martin Hunt) (05/09/90)
Many of you have been asking about the relative performance of the 2500
vs the 3000. Since both machines use a 25Mhz 68030 and 68882, their
CPU performance is very similar. They also use similar disk controllers,
which are limited mostly by the speed of the disk anyways. The major
difference is the 32 bit chip memory and ROMs in the 3000. So, the 3000
should be much faster at accessing the chip bus.
I have also seen several rumors that the 25MHz 3000 is no faster than
the 16MHz version because of "slow memory". One ST magazine I read even
suggested that you were wasting your money buying a 25MHz 3000 because
it would not run any faster than a 16 MHz machine!
CAUTION!!!
The following results are from the C version of Dhrystone 2.1. Dhrystone
measures a CPUs integer performance only. It is a small benchmark and can
be easily "cached" on some computers resulting in misleading numbers.
Older versions of Dhrystone also suffered from numerous problems and cannot
be compared with version 2.1 results. Version 1.1, for example could be
optimized out of existence by a really intelligent compiler. Some
disreputable computer manufacturers still post 1.1 results, hoping they
will be confused with the current version.
Dhrystone is most useful when comparing similar computers or different
compilers on the same computer.
When compiling, I left the source code intact and used the lattice
-v and -O flags only, which disable stack checking and enable optimization.
I also tried compiling with the -m2 flag, enabling 68020 code generation.
I also used 32 bit ints because I don't believe in benchmarking 32 bit
CPUs with 16 bit integers.
All benchmarks were run with instruction and data cache and "fastrom".
The program was run at normal priority (0) with multitasking enabled.
2500/30 3000 (16 MHz) 3000 (25 Mhz) 2000
Normal 5950 4300 6050 600
Registers 6110 4400 6225 620
68020 6600 4770 6800
68020/Reg 6820 4970 7000
Manx 5.0 produced code that was 15% smaller, but also 15% slower.
The 3000 would probably benefit from static column DRAMS. I haven't
tried this yet.
LATTICE BUG!
There is a bug in the Lattice compiler that causes programs
with names that are not multiples of 4 long to be much slower on a 68020
or 68030. This is because the filename is pushed on the stack and can
cause the stack to not be longword aligned. For example, when I renamed
"dhrystone" to "dhry", I got an additional 900 dhrystones!
FINAL COMMENT
So how fast is 7000 dhrystones? It's faster than a NeXT and all Mac IIs
except the FX. It's probably about the same as a 33MHz 386 without
external cache. Of course, you will see widely varying numbers because
some people "tune" their compilers or even the dhrystone source.
I know some of you were expecting to see numbers like 20000 or so.
Currently, SPARCstations and 486s are getting dhrystone ratings like
this. Most of this is the result of dhrystone fitting entirely on
the computers on-board or on-chip cache. The 68030, with only 256
bytes of cache can't do this. The Amiga 3000 has been built to be
both economical and expandable, so not only can you afford one,
but you can also add on external cache memory or a 68040 when these
become available.
--
Martin Hunt martin@cbmvax.commodore.com
Commodore-Amiga Engineering {uunet|pyramid|rutgers}!cbmvax!martinnavas@cory.Berkeley.EDU (David C. Navas) (05/09/90)
In article <11445@cbmvax.commodore.com> martin@cbmvax.UUCP (Martin Hunt) writes: >One ST magazine I read even >suggested that you were wasting your money buying a 25MHz 3000 because >it would not run any faster than a 16 MHz machine! Gee, that's a good source for information regarding amigs... :) These numbers look pretty familiar. Here's an interesting question: Are they stock A3000's, or do they have some of those fast ZIPs n 'em? Could you do it on a Zipped machine?? :) Thanks!! >The 3000 would probably benefit from static column DRAMS. I haven't >tried this yet. Oops didn't see that, sorry... Does anyone else have numbers for a "zipped" machine? >"dhrystone" to "dhry", I got an additional 900 dhrystones! So we're talking 7900, or was that 6100 before renaming? >So how fast is 7000 dhrystones? It's faster than a NeXT and all Mac IIs >except the FX. It's probably about the same as a 33MHz 386 without >external cache. Do you have those numbers available? They would be highly appreciated as well -- at least by me! Thanks again... >I know some of you were expecting to see numbers like 20000 or so. Hey, we're not *all* that gullible, are we? Well? :) :) >Martin Hunt martin@cbmvax.commodore.com >Commodore-Amiga Engineering {uunet|pyramid|rutgers}!cbmvax!martin David Navas navas@cory.berkeley.edu "Excuse my ignorance, but I've been run over by my train of thought." -me
karl@sugar.hackercorp.com (Karl Lehenbauer) (05/09/90)
In article <24883@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU.UUCP (David C. Navas) writes: >One ST magazine I read even >suggested that you were wasting your money buying a 25MHz 3000 because >it would not run any faster than a 16 MHz machine! Don't believe it for even one second. The 25 MHz machine would be faster even if the RAM was the same speed... caches and everything, you know... There are lots of 68030 CPU cycles where the CPU doesn't even access main memory. Plus for floating point the 25 MHz machine has a 68882 rather than the '881 in the 16 MHz one. Also, traditionally, ST people have probably been the greatest spreaders of lies and misinformation about the Amiga of any group, like the ST dealer here in Houston that claimed, and probably still claims, that the Amiga doesn't multitask. -- -- uunet!sugar!karl -- Usenet access: (713) 438-5018
new@udel.EDU (Darren New) (05/10/90)
In article <11445@cbmvax.commodore.com> martin@cbmvax.UUCP (Martin Hunt) writes: > There is a bug in the Lattice compiler that causes programs >with names that are not multiples of 4 long to be much slower on a 68020 >or 68030. This is because the filename is pushed on the stack and can >cause the stack to not be longword aligned. For example, when I renamed >"dhrystone" to "dhry", I got an additional 900 dhrystones! Can you clarify this please? Is it the name of the executable that must be a multiple of four, or the name of the source? If it's the executable, then it seems it would be fixable by hacking the startup code. If it's the source, I can't imagine why Lattice is pushing the name of the source on the stack except for debugging purposes. If it is the name of the source and you don't wish to change this, is it feasible to push a short on the stack (declaring a short int in main, maybe) thereby realligning the stack? Or could it be done by adding an adjustment in the startup code that checks the stack allignment and corrects it? Have you reported this bug to Lattice? -- Darren
jmeissen@oregon.oacis.org (John Meissen) (05/10/90)
In article <18962@estelle.udel.EDU> new@ee.udel.edu (Darren New) writes: >the source, I can't imagine why Lattice is pushing the name of the source >on the stack except for debugging purposes. If it is the name of the source The problem is that in some cases the program wants access to a copy of the original line, to do its own parsing, whatever. Well, AmigaDOS strips the command from the line and only passes the tail. So to provide this compatability we had to reconstruct the command line, putting it on the stack. Since there is no dependancy on where this reconstructed line exists, it would make sense to AllocMem a buffer for it. That would eliminate the problem. For anyone so inclined, it should be a relatively simple hack to the startup code (c.a). -- John Meissen ............................... Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes
sterling@cbmvax.commodore.com (Rick Sterling) (05/10/90)
In article <18962@estelle.udel.EDU> new@ee.udel.edu (Darren New) writes: > In article <11445@cbmvax.commodore.com> martin@cbmvax.UUCP (Martin Hunt) writes: > > There is a bug in the Lattice compiler that causes programs > >with names that are not multiples of 4 long to be much slower on a 68020 > > ... > Can you clarify this please? Is it the name of the executable that must be > a multiple of four, or the name of the source? If it's the executable, > ... > -- Darren It is the executable ... simply renaming the executable illustrates the bug. I brought this to Lattice's attention eon's ago when 5.02 was released. Hopefully they have fixed it by now. I haven't checked later releases as I spend most of my time in Forth-land ;-) __ __ |__) (__` | \ick ,__)terling ----------------------------------------------- Test Engineering Commodore Technology Group (215)-431-9275 UUCP ...{uunet,allegra,rutgers}!cbmvax!sterling
papa@pollux.usc.edu (Marco Papa) (05/10/90)
What I would like to see is comparative benchmarks between the A3000 and other '030 based competitor machines such as the NeXT and the Mac IIfx. Does anybody have Dhrystones, Kornerstone and Spec marks for each one of the A3000, Mac IIfx and NeXT? -- Marco -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "Xerox sues somebody for copying?" -- David Letterman -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=