Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!amiga!cbmvax!martin From: martin@cbmvax.commodore.com (Martin Hunt) Newsgroups: comp.sys.amiga Subject: Benchmarks for 3000 vs 2500 Message-ID: <11445@cbmvax.commodore.com> Date: 9 May 90 01:13:41 GMT Reply-To: martin@cbmvax.UUCP (Martin Hunt) Distribution: comp Organization: Commodore Technology, West Chester, PA Lines: 73 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!martin