sansom@trwrb.UUCP (Richard Sansom) (06/10/87)
I asked Joe Knapp (ihnp4!asr2!jmk) to send me a copy of orbit.c so I could
compile and execute with MWC 2.0. Well, he sent it, I compiled it, and got
results which produce the following updated performance chart:
machine compiler run time (s) accuracy
=========== ============ ======== ==========
520ST Lattice 3.03.01 480 very good
6300+ Microsoft 192 excellent
>> 520ST MWC 2.0 180 excellent
Amiga 1000 Manx -lm 25 poor
6300+/80287 Microsoft 22 excellent
VAX 11/785 Unix V cc 4 excellent
The good news is that the results were _exactly_ the same as those produced
by the VAX 11/785. The bad news is that the ST is still much slower than it
should be (based on the Amiga's performance).
I'm gonna kick this thing around for a few more days and see if I can
determine just what is slowing the ST down soooooo much.
-Rich
--
/////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
/// Richard E. Sansom TRW Electronics & Defense Sector \\\
\\\ {decvax,ucbvax,ihnp4}!trwrb!sansom Redondo Beach, CA ///
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/////////////////////////////////////ljdickey@water.UUCP (06/11/87)
In article <1959@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: >The good news is that the results were _exactly_ the same as those produced >by the VAX 11/785. The bad news is that the ST is still much slower than it >should be (based on the Amiga's performance). Richard, Could it be that the speed of your program on the Amiga might have something do to with the precision of the arithmetic. I notice that your results show the Amiga to be fast, but not too accurate. Not too long ago, several people sent in performance reports for something called the "Savage Benchmark". My recollection is that there was a "speed-precision" trade off. On one machine, a program compiled with variables declared to be single precision ran faster, but were less accurate, than the same program variables declared to be double precision. I wonder if that could account for your observed differences. Lee Dickey
rnss@ihuxy.ATT.COM (Ron Schreiner) (06/11/87)
In article <1959@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: >I asked Joe Knapp (ihnp4!asr2!jmk) to send me a copy of orbit.c so I could >compile and execute with MWC 2.0. ..... >results > machine compiler run time (s) accuracy > =========== ============ ======== ========== ... > >> 520ST MWC 2.0 180 excellent > Amiga 1000 Manx -lm 25 poor >The good news is that the results were _exactly_ the same as those produced >by the VAX 11/785. The bad news is that the ST is still much slower than it >should be (based on the Amiga's performance). What good is 8 times faster if it's not right ? I'll bet I can write a floating point package that will run 16 times faster than the Amiga just as long as you are willing to give up accuracy. But seriously folks, doesn't the Amiga have a math co-processor ? I had heard rumors to that effect but I don't know for sure.
dillon@CORY.BERKELEY.EDU.UUCP (06/12/87)
>> machine compiler run time (s) accuracy >> =========== ============ ======== ========== >.... >> >> 520ST MWC 2.0 180 excellent >> Amiga 1000 Manx -lm 25 poor > >What good is 8 times faster if it's not right ? >I'll bet I can write a floating point package that will run 16 times >faster than the Amiga just as long as you are willing to give up accuracy. > >But seriously folks, doesn't the Amiga have a math co-processor ? >I had heard rumors to that effect but I don't know for sure. The Amiga does not have a math co-processor, though it supports a 68881. As far as the floating point benchmarks go, you have a choice of three different floating point formats on the Amiga. (1) Motorola's fast floating point (FFP), (2) IEEE double precision floating point, and, of course, (3) 68881 support. The one specified above is Motorola's FFP format, which stores the floating point number in a single longword. This format is excellent for most applications, and has an accuracy of about 10 digits. Those applications which require more accuracy usually use the double precision format (two longwords, or 8 bytes). -Matt
cmcmanis@sun.uucp (Chuck McManis) (06/12/87)
In article <1996@ihuxy.ATT.COM> rnss@ihuxy.UUCP (Ron Schreiner) writes: >What good is 8 times faster if it's not right ? >I'll bet I can write a floating point package that will run 16 times >faster than the Amiga just as long as you are willing to give up accuracy. > >But seriously folks, doesn't the Amiga have a math co-processor ? >I had heard rumors to that effect but I don't know for sure. As mentioned previously, the accuracy problem is due to the incorrect definition of the value of PI in the Aztec C include files. No, the Amiga does not come with a floating point coprocessor. The MicroBotics 2 Meg memory card supports the '881, and the 68020 adapter has a socket for one. It is not however standard equipment (don't I wish). -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses. But you knew that, didn't you.
hah@isum.intel.com (Hans Hansen) (06/12/87)
In article <1959@trwrb.UUCP> sansom@trwrb.UUCP (Richard Sansom) writes: > > machine compiler run time (s) accuracy > =========== ============ ======== ========== > 520ST Lattice 3.03.01 480 very good > Amiga 1000 Manx -lm 25 poor > > The bad news is that the ST is still much slower than it >should be (based on the Amiga's performance). > >-Rich First place to look is the length of the integers used to compute. Lattice uses 32 bit integers std while Manx uses 16 bit integers std (32 bit compile option). Manx also produces a much smaller object module. Hans
braner@batcomputer.tn.cornell.edu (braner) (06/13/87)
[] As far as I know, the Amiga does not "support" the 68881 in any way beyond providing an expansion slot. The 68881 is really only fully supported by the 68020 CPU chip. The "Turbo Amiga" is basically a seperate computer that uses the Amiga as sort of a terminal. It has its own CPU, memory. And it costs a lot more than the Amiga itself. The Mac II is comparable in price and comes standard with the 68020/ 68881. These two machines may seem expensive to us Atari users, but they are _incredibly_ powerful for number crunching. Better than the VAX and for a small fraction of the price... Where are you, Atari? (Working on a new 8/16 bit machine, I believe.) The Motorola FFP library (and all other 32-bit FP libs) do _NOT_ have 10-digit precision, only about 6--7 digits. That is frequently useful but just as frequently terrible. Think about it: 10^10 ~ 2^33, so no bits left for the exponent... - Moshe Braner
dillon@CORY.BERKELEY.EDU.UUCP (06/13/87)
>As far as I know, the Amiga does not "support" the 68881 in any way >beyond providing an expansion slot. The 68881 is really only fully >supported by the 68020 CPU chip. The "Turbo Amiga" is basically a One for me: The amiga supports the 68881 in the following ways: -Automatic detection and setting of a flag bit in Exec library -Automatic multi-tasking support (save/restore 68881 registers on task switch). Both Lattice and Aztec support a 68881 fp library. >The Motorola FFP library (and all other 32-bit FP libs) do _NOT_ have >10-digit precision, only about 6--7 digits. That is frequently useful >but just as frequently terrible. Think about it: 10^10 ~ 2^33, so >no bits left for the exponent... One for you: 24 bits mantissa, 1 bit sign, 7 bit exponent Yielding 7.22 digits (base 10) with a nominal exponent range -63 to +63. However, if that accuracy is good enough for an application, one usually uses the IEEE double precision format instead. This gives 15-16 digits accuracy with a nominal exponent range -307 to +308 -Matt
cmcmanis@pepper.UUCP (06/15/87)
In article <1361@batcomputer.tn.cornell.edu> (braner) writes: >As far as I know, the Amiga does not "support" the 68881 in any way >beyond providing an expansion slot. The 68881 is really only fully >supported by the 68020 CPU chip. The "Turbo Amiga" is basically a >seperate computer that uses the Amiga as sort of a terminal. It has >its own CPU, memory. And it costs a lot more than the Amiga itself. >The Mac II is comparable in price and comes standard with the 68020/ >68881. These two machines may seem expensive to us Atari users, but >they are _incredibly_ powerful for number crunching. Better than the >VAX and for a small fraction of the price... Where are you, Atari? >(Working on a new 8/16 bit machine, I believe.) A small clarification here, the Amiga 'supports' the 68881 insomuch that it knows to save it's context on task switches, and there are some resident libraries that use it, thus if your program currently calls routines in the library mathieee.library then when that library is replaced with the one that uses the 68881 your program automagically speeds up. But if it is a '000 or '010 processor the speed ups are mostly in the trancendental functions, not your basic multiply and divide. Secondly, the 'Turbo' Amiga does not use the Amiga as a 'terminal', the 68020 removes the 68000 from the bus by asserting a line on the expansion connector (or on a daughter board). The 68020 boots from the Kickstart just like the 68000 would have if it had control of the bus. The Turbo Tower from CSA associates is an expansion box that also contains a 32 bit memory buss. Anyway, you get the idea, it isn't anything like the proposed 'TT'. This is not to say it is good or bad either since there are benefits either way. >The Motorola FFP library (and all other 32-bit FP libs) do _NOT_ have >10-digit precision, only about 6--7 digits. That is frequently useful >but just as frequently terrible. Think about it: 10^10 ~ 2^33, so >no bits left for the exponent... >- Moshe Braner So true, at a conference once I asked the Motorola Rep what they used FFP for. He replied "I think Tiny Basic uses it." Ask yourself, do you want to use a format that has less precision than a $5 calculator? --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
ger@qtecmuc.UUCP (06/17/87)
According to Kernighan&Ritchie (Appendix A, 6.2 on page 184 in my copy) 'all floating point arithmetic in C is carried out in double precision'. Therefore, if manx on the AMIGA really uses one longword for floating point evaluations it simply isn't real C and benchmarks with this compiler are pure nonsens if compared with 'correct' C-Compilers using 64bit double precision. Gerhard Pehland UUCP: ...!seismo!unido!qtecmuc!ger
ali@rocky.STANFORD.EDU (Ali Ozer) (06/22/87)
In article <19400004@qtecmuc.UUCP> ger@qtecmuc.UUCP writes: >According to Kernighan&Ritchie (Appendix A, 6.2 on page 184 in my copy) >'all floating point arithmetic in C is carried out in double >precision'. Therefore, if manx on the AMIGA really uses one longword >for floating point evaluations it simply isn't real C and benchmarks >with this compiler are pure nonsens if compared with 'correct' >C-Compilers using 64bit double precision. The use of single-word floating point operations is a feature, not a limitation. Manx gives you various FP modes, among which the IEEE double and the Motorola FFP. 68881 is also supported. You specify which mode you want through switches to the compiler and/or linking in the various libraries... Now if I have a program that did not need 10+ digits but could get away with the 7 or so digits Motorola FFP provides, I will certainly use the FFP mode, considering it is 7 to 8 times faster. Ali Ozer, ali@rocky.stanford.edu
jmk@asr2.UUCP (Joe Knapp) (06/22/87)
In article <19400004@qtecmuc.UUCP> ger@qtecmuc.UUCP (Gerhard Pehland) writes: >'all floating point arithmetic in C is carried out in double >precision'. Therefore, if manx on the AMIGA really uses one longword >for floating point evaluations it simply isn't real C and benchmarks >with this compiler are pure nonsens if compared with 'correct' >C-Compilers using 64bit double precision. A quick note: the earlier benchmark results for Manx did not suffer from a misdefined PI, as was suggested. It was correct to many decimal places. Based on what others have said here recently, it appears that the MFFP library is at fault for the lack of precision. Joe Knapp ihnp4!asr2!jmk
manis@ubc-cs.UUCP (Vincent Manis) (06/23/87)
In article <19400004@qtecmuc.UUCP> ger@qtecmuc.UUCP writes: >According to Kernighan&Ritchie (Appendix A, 6.2 on page 184 in my copy) >'all floating point arithmetic in C is carried out in double >precision'. Therefore, if manx on the AMIGA really uses one longword >for floating point evaluations it simply isn't real C and benchmarks >with this compiler are pure nonsens if compared with 'correct' >C-Compilers using 64bit double precision. Yet another instance where K&R are incorrect. When they say "double precision" they really mean type "double", which may or may not actually be double precision. An Amiga implementation which treats float and double the same is not incorrect (though obviously not as good as one which provides extra precision). ANSI says that double can have no less precision than float, which the Lattice version certainly satisfies. Incidentally, I goofed in a recent posting on Mark Williams C f.p. I said that they implement the VAX F and D formats (found on the PDP-11). Looking at the MWC manual, it appears that they use VAX G format (slightly more exponent, slightly less fraction. ----- Vincent Manis {seismo,uw-beaver}!ubc-vision!ubc-cs!manis Dept. of Computer Science manis@cs.ubc.cdn Univ. of British Columbia manis%ubc.csnet@csnet-relay.arpa Vancouver, B.C. V6T 1W5 manis@ubc.csnet (604) 228-6770 or 228-3061 "To lose one parent, Mr Worthing, may be regarded as a misfortune; but to lose both looks like carelessness." -- Oscar Wilde
steven@cwi.nl (Steven Pemberton) (06/25/87)
In article <19400004@qtecmuc.UUCP> ger@qtecmuc.UUCP writes: > According to Kernighan&Ritchie (Appendix A, 6.2 on page 184 in my copy) > 'all floating point arithmetic in C is carried out in double precision'. > Therefore, if manx on the AMIGA really uses one longword for floating point > evaluations it simply isn't real C, and benchmarks with this compiler > are pure nonsense if compared with 'correct' C-Compilers using 64 bit > double precision. You have misunderstood. One page earlier it says "[float] and [double] may be synonymous in some implementations.": when they say that floating point is carried out in double precision, they mean 'in the accuracy used for double precision'. Actually, I know of at least one implementation that evaluates expressions in greater than double precision. Obviously not a correct C compiler :-). Steven Pemberton, CWI, Amsterdam; steven@cwi.nl (steven@mcvax.uucp old style).
jdg@elmgate.UUCP (Jeff Gortatowsky) (06/25/87)
In article <19400004@qtecmuc.UUCP> ger@qtecmuc.UUCP writes: > > >According to Kernighan&Ritchie (Appendix A, 6.2 on page 184 in my copy) >'all floating point arithmetic in C is carried out in double >precision'. Therefore, if manx on the AMIGA really uses one longword >for floating point evaluations it simply isn't real C and benchmarks >with this compiler are pure nonsens if compared with 'correct' >C-Compilers using 64bit double precision. > >Gerhard Pehland >UUCP: ...!seismo!unido!qtecmuc!ger I'm not too sure (have to go home and check) but I believe Megamax also uses single precision *if* you don't link with double.l. Now Manx 3.4a on the amiga gives you 4 different floating point choices. Manx single, Amiga built in single (shared lib I think), Manx IEEE double, and Amiga IEEE (again a built in shrared lib). PLUS 68881 support. Change, is there a new release of MegaMax (large memory model, etc)? Would some MWC 2.0 owners mail me their thoughts on the robust(ness?) of this compiler? Latly I've had tons of problems porting code (just C standard stuff) between machines (Amiga and ST) because MegaMax chokes badly on some complex expressions (and not so complex) that Manx 3.4 swallows just fine. I really need a robust compiler so as to concentrate on coding and not on compiler problems. Does MWC 2.0 fit that bill? -- Jeff Gortatowsky {seismo,allegra}!rochester!kodak!elmgate!jdg Eastman Kodak Company These comments are mine alone and not Eastman Kodak's. How's that for a simple and complete disclaimer?