louie@trantor.UMD.EDU (12/17/85)
From: Louis A. Mamakos <louie@trantor.UMD.EDU>
It just so happens that I was in San Diego last week, and I dropped by to
visit the CSA folks. In case you tuned in late, they are a 68000 systems
house that manufacture a general purpose 68020/68881 piggyback board that
plugs into a 68000 socket. In addition, they have a version for the Amiga
that also has 256K of static RAM on board. The current version (a prototype)
that I played with runs at the same clock speed as the 68000 on the Amiga.
I took along a copy of the Dhrystone benchmarks to beat on it with. There
are three dhrystone runs: 32 bit integers without register variables, 32 bit
integers with register variables, and 16 bit integers with register variables.
Three test configurations were used: my standard Amiga at home, the CSA 68020
board with the 68020 cache enables, and the CSA 68020 board with cache and
additional memory enabled.
Standard Amiga 68020/cache 68020/cache/fast mem
32 bit/no reg 458 515 781
32 bit/reg 458 515 657 (??)
16 bit/reg 549 588 781
I cannot explain the obvious anomoly in data observed; it is possible
that the data may not have gathered with the 68020 instruction cache
enabled.
The additional 256K of static memory is on the CPU piggyback board, and it
32 bit wide. This presumably explains the improved performence. I assume
that the dhrystone program was loaded and run from the 'fast' memory. I
cannot be sure. I was running an amiga booted from a plain V1.0 kickstart
and workbench disk. The 'addmem' program was used to tell the system about
the additional memory. CSA had a small program that enabled the 68020
cache.
Rumors
------
I understand that CSA is working on a board with it's own clock (running
faster that the 7.1 odd MHz). This should improve the performence
considerably. CSA will be selling a version of the Amiga outfitted with
their board. They will be calling it a TurboAmiga.
I don't claim these numbers are correct or even reproducable. We were
running with an unknown set of software and hardware. Just fooling around
with the system in a few spare hours. If you want to know more about thelouie@trantor.UMD.EDU (12/17/85)
From: Louis A. Mamakos <louie@trantor.UMD.EDU> Sorry about not mentioning the source. I was going to include a PS with the relevant information, but my modem hung up at an awkward time. CSA is Computer Systems Associates 7564 Trade Street San Diego, CA 92121 (619) 566-3911 I don't own any of their products (yet). I am not a completely impartial party as I may be doing some software for them in the future. I would suggest that you wait to see what the availability of the higher speed version of the product; the existing version, although faster, doesn't show a *dramatic* increase in speed. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
mjg@ecsvax.UUCP (Michael Gingell) (12/18/85)
> I took along a copy of the Dhrystone benchmarks to beat on it with. There > are three dhrystone runs: 32 bit integers without register variables, 32 bit > integers with register variables, and 16 bit integers with register variables. > Three test configurations were used: my standard Amiga at home, the CSA 68020 > board with the 68020 cache enables, and the CSA 68020 board with cache and > additional memory enabled. > > Standard Amiga 68020/cache 68020/cache/fast mem > > 32 bit/no reg 458 515 781 > > 32 bit/reg 458 515 657 (??) > > 16 bit/reg 549 588 781 > > According to the folks at Amiga, when compiled on a Sun using the Greenhills compiler and then ported to a standard Amiga they got 850 Dhrystones/sec which shows that it might be more profitable to buy a better compiler than the 68020 board. Mike Gingell ..decvax!ecsvax!mjg
dale@amiga.UUCP (Dale Luck) (12/18/85)
In article <755@caip.RUTGERS.EDU> louie@trantor.UMD.EDU writes: >From: Louis A. Mamakos <louie@trantor.UMD.EDU> > Standard Amiga 68020/cache 68020/cache/fast mem > >32 bit/no reg 458 515 781 > >32 bit/reg 458 515 657 (??) > >16 bit/reg 549 588 781 > I ran the same benchmark using our greenhills c-compiler and obtained about 1300/sec using 68020/cache/32bit memory/7.18Mhz clock. The greenhills benches at about 850/sec on a plain 68000 amiga. > >I was running an amiga booted from a plain V1.0 kickstart and workbench disk. >CSA had a small program that enabled the 68020 cache. The V1.1 software automatically enables the cache on 68020 when booted. I wrote the little cache enable program for CSA, but is not needed anymore with 1.1. Dale Luck Amiga
kim@mips.UUCP (Kim DeVaughn) (12/19/85)
> From: Louis A. Mamakos <louie@trantor.UMD.EDU> > > It just so happens that I was in San Diego last week, and I dropped by to > visit the CSA folks. > [ ... ] > I took along a copy of the Dhrystone benchmarks to beat on it with. > > Standard Amiga 68020/cache 68020/cache/fast mem > 32 bit/no reg 458 515 781 > 32 bit/reg 458 515 657 (??) > 16 bit/reg 549 588 781 > I don't claim these numbers are correct or even reproducable. We were > running with an unknown set of software and hardware. Looks like you were using the native Lattice C compiler, as your Standard Amiga numbers are very close to the numbers Dale Luck (of CBM) posted awhile back. He also posted a Dhrystone number of 850 for the same code that was cross-compiled on a Sun using the Greehills compiler. Seems very apparent that one thing that's sorely needed for the Amiga is a *good* (read "well-optimized") compiler; it would seem that 850 is alot closer to the true capability of the Amiga, as that is in the same ballpark as the Dhrystones for the ST (the ST has been reported to run in excess of 1000 if the cursor is turned-off, etc). The 020 numbers ought to increase considerably with a good compiler, and could increase even more if it were optimized for the 020 chip itself; then with a "fast" 020 .... I leave it to your imagination! BTW, I have heard elsewhere that Aztec C will be ready for Beta testing in January ... /kim -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 415-960-1200 USPS: MIPS Computer Systems Inc, 1330 Charleston Rd, Mt View, CA 94043
nigel@minster.UUCP (nigel) (12/19/85)
In article <755@caip.RUTGERS.EDU> louie@trantor.UMD.EDU writes: >From: Louis A. Mamakos <louie@trantor.UMD.EDU> > >It just so happens that I was in San Diego last week, and I dropped by to >visit the CSA folks. In case you tuned in late, they are a 68000 systems >house that manufacture a general purpose 68020/68881 piggyback board that >plugs into a 68000 socket. In addition, they have a version for the Amiga >that also has 256K of static RAM on board. The current version (a prototype) >that I played with runs at the same clock speed as the 68000 on the Amiga. > > > Standard Amiga 68020/cache 68020/cache/fast mem > >32 bit/no reg 458 515 781 > >32 bit/reg 458 515 657 (??) > >16 bit/reg 549 588 781 ^^^ 68020,cache,fast memory, and still slower than an Atari 520ST?? Is it worth it?
tim@ism780c.UUCP (Tim Smith) (12/20/85)
>>[discussion of Amiga Dhrystone results, with and without 68020] In article <271@mips.UUCP> kim@mips.UUCP (Kim DeVaughn) writes: >Looks like you were using the native Lattice C compiler, as your Standard ... >Seems very apparent that one thing that's sorely needed for the Amiga is a >*good* (read "well-optimized") compiler; it would seem that 850 is alot >closer to the true capability of the Amiga, as that is in the same ballpark Even a non-optimized compiler should get much better Dhrystones than Lattice is! Has anyone looked at the code to see just what it is doing? -- Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim
keithd@cadovax.UUCP (Keith Doyle) (12/23/85)
In article <179@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >Even a non-optimized compiler should get much better Dhrystones than Lattice >is! Has anyone looked at the code to see just what it is doing? > >-- >Tim Smith sdcrdcf!ism780c!tim || ima!ism780!tim || ihnp4!cithep!tim I wish we could! They don't support the -S option allowing you to generate machine language source (so you can hand optimize) (sigh). Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
louie@trantor.UMD.EDU (12/23/85)
From: Louis A. Mamakos <louie@trantor.UMD.EDU> The dhrystone benchmarks that I ran were compiled with the native Lattice C compiler. I'm not real impressed with the qualitiy of the code that is produced, a real optimizing compiler is needed. I've heard the Apple is going to ship a native version of the Greenhills compiler for the Mac; it would be nice to have a version for the Amiga too. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
milazzo@rice.ARPA (12/23/85)
From: Paul Milazzo <milazzo@rice.ARPA>
Even more interesting than the increase in speed with the 68020 is that
the results are identical for 32 bit integers with and without
registers. Offhand, I'd say that this C compiler doesn't do registers
at all. Has anyone compared the assembly code generated in these two
cases?
If this hypothesis proves correct, we have one foo explanation for the
incredibly poor performance of the standard Amiga on this benchmark.
On the basis of architecture alone I would expect closer to twice the
quoted number (458) from this machine.
By the way, I assume that people collect these results without
displaying any graphics which would cut into the CPU time. For
example, displaying a 640x200x4 image would probably destroy the
machine's performance.
Paul G. Milazzo
Dept. of Computer Science
Rice University, Houston, TX
Domain: milazzo@rice.EDU
ARPA: milazzo@rice.ARPA
BITNET: milazzo@ricecsvm
UUCP: {cbosgd,convex,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzolouie@trantor.UMD.EDU (12/23/85)
From: Louis A. Mamakos <louie@trantor.UMD.EDU> I ran my test on the CSA 68020 AMIGA and on my amiga with the standard workbench screen (640 x 200 x 2), with no other stuff running. I'm not real thrilled with the quality of the code generated.. louie Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
papa@uscvax.UUCP (Marco Papa) (12/25/85)
> From: Paul Milazzo <milazzo@rice.ARPA> > > Even more interesting than the increase in speed with the 68020 is that > the results are identical for 32 bit integers with and without > registers. Offhand, I'd say that this C compiler doesn't do registers > at all. Has anyone compared the assembly code generated in these two > cases? > > If this hypothesis proves correct, we have one foo explanation for the > incredibly poor performance of the standard Amiga on this benchmark. ... > Paul G. Milazzo > Dept. of Computer Science > Rice University, Houston, TX The Lattice "C" compiler manual for the IBM PC says: "Items which are declared register are so flagged, but storage is allocated for them anyway against either the auto or the formal storage base..." "...This version of the compiler does not implement register variables bacause of the comparatively limited number of registers available on the 8086 series microprocessors. Declarations using registers are, however, accepted if properly made. Storage is reserved for these objects as if they had been declared auto". If the Amiga Lattice "C" compiler is a quick and dirty port of the IBM PC version, register variables are probably NOT supported even on the AMIGA. Marco Papa USC - Computer Science Dept. UUCP: ...!{decvax,ucbvax,hplabs}!sdcsvax!sdcrdcf!uscvax!papa ...!{allegra,trwrb,trwspp,ism780,cithep,oberon}!uscvax!papa CSNET: papa@usc-cse.csnet ARPA: papa%usc-cse@csnet-relay.arpa
mykes@3comvax.UUCP (Mike Schwartz) (12/28/85)
In article <822@caip.RUTGERS.EDU> milazzo@rice.ARPA writes: >From: Paul Milazzo <milazzo@rice.ARPA> > >Even more interesting than the increase in speed with the 68020 is that >the results are identical for 32 bit integers with and without >registers. Offhand, I'd say that this C compiler doesn't do registers >at all. Has anyone compared the assembly code generated in these two >cases? > Lattice 'C' on the PC does not use registers, and I doubt those guys did much more than porting over their dinosaur compiler.