burati@apollo.UUCP (Mike Burati) (12/21/88)
Jaye, (and others)
After playing with the source to paranoia, that you sent me, for a couple
of minutes, here's what I found out:
> From: umix!caesar.cs.montana.edu!icsu6000 (Mathisen)
> To: umix!apollo
> Subject: Paranoia test, and some interesting results
>
> Apollo dropped off a 3500 for us to play around with for a while. I
> had just been playing with a program called paranoia which is supposed to test
> floating point thingies, and tell you how good your machine-compiler handles
> floating point arithmetic.
As you can see below, it's not too smart about how it checks...
> Machine(config) Time to compile Bombed at what point.
> -------------------------------------------------------------------------------
> dali HP9000/350 SRX
> 25mhz 020, 881 fpu 40 seconds Just after milestone 30 with
> running HP-UX 6.0 Div lacks Guard digit, IOT
> trap, (core dumped)
> bridger Apollo 3500
> 25mhz 030, 882 fpu 127 seconds pow:DOMAIN error, then goes
> running SR10.0 into infinite loop, which
> even kill -KILL pid doesn't stop.
As shown below, I compiled the exact same code in 35 seconds with the same switches
that you did. There may have been something weird happening on your machine, or maybe
it's because I was using sr10.1 and you were using sr10.0. (Also note, that it didn't
crash or go into an infinite loop on my sr10.1 machine, but finished cleanly).
> caesar mVAXII
> whatmore to say?? 101 seconds Completes the test, says
> Ultrix 2.3, with pcc. it has one error.
> While I realize this is one very limited test, for the combination
> of what works, versus performance, the mVAXII isn't bad is it? I'm suprised
> by the pathetic compilation speed of the 3500, sounds like some serious
> C compiler work is needed here.
> Jaye mathisen
> systems manager,Dept. of Computer Science,Montana State University, Bozeman MT
I compiled the benchmark on a DN3500 with 8MB memory running sr10.1
and got the following times: (note, since we use global libraries
(shared) you don't really need the -lc or -lm)
% time cc paranoia.c -o paranoia -s -lc -lm
33.1u 4.0s 0:47 77% 0+0k 112+0io 725pf+0w
% time cc paranoia.c -o paranoia -s
32.9u 3.1s 0:39 91% 0+0k 13+0io 364pf+0w
This produced the following results (note: it doesn't go into an infinite
loop like you said, so it may be a problem that's fixed in sr10.1).
The number of SERIOUS DEFECTs discovered = 1.
The number of DEFECTs discovered = 2.
The number of FLAWs discovered = 1.
By default, the compilers produce code that's backwards compatible all the
way back to a DN100. This means that the compiler doesn't produce code for
the 68882 unless you ask it to (ie: floating pt ops are done through a library
instead). Add the following command line switch to tell it to compile for the
68881/68882 machines (note: you could substitute the 3000 with 330 4000 ...)
% time cc paranoia.c -o paranoia -s -W0,"-cpu,3000"
33.8u 2.2s 0:37 95% 0+0k 81+0io 65pf+0w
Compiling with the above option gets rid of one of the messages and leaves you
with only:
The number of DEFECTs discovered = 2.
The number of FLAWs discovered = 1.
The arithmetic diagnosed may be Acceptable
despite inconvenient Defects.
Now, looking through the output, I found out that its thinks that using extra
precision bits is a flaw (why is that a flaw?). Our systems (and probably others)
use 80 bit extended precision on the 6888X floating point coprocessors. So,
just to see what would happen, I tweaked my 68881 down to double precision (64 bits)
and it got rid of another of the messages.
The number of DEFECTs discovered = 2.
The arithmetic diagnosed may be Acceptable
despite inconvenient Defects.
END OF TEST.
I haven't had time to check the last two messages that exist, but as the output says,
"The arithmetic diagnosed may be Acceptable". Given the nature of the other two errors
that I got rid of, and the reasons that they showed up in the first place, I would assume
that these last two are similar.
..Mike Burati
Tech Consultant
Apollo Computer
burati@apollo.com
The above are my own comments (done on my own time), to help out a confused customer.
They should not be construed as an official statement by apollo.