icsu6000@CAESAR.CS.MONTANA.EDU (Mathisen) (12/13/88)
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. Only one machine passed the test, out of the 3 I tried it on, and that was a mVAX II running Ultrix 2.3, both the Apollo and an HP9000/350 SRX crapped out. 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. 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. I'd be happy to send the source to anybody who wants it. Jaye mathisen systems manager,Dept. of Computer Science,Montana State University, Bozeman MT
pha@CAEN.ENGIN.UMICH.EDU (Paul H. Anderson) (12/14/88)
Simply because a program runs on one machine doesn't mean it will run on others. Perhaps the fact that it crapped out on 2 out of the 3 machines you tried it on should tell you something. Also, it is bogus to give compile time results without explaining which options were used and what the run time results were. There are very substantial differences between different levels of optimisation in terms of expected run time. I have found the Apollo compilers to be quite good, mostly in terms of speed of compilation and error messages given. I don't usually care about the last 5% of compiled code performance. Paul Anderson CAEN
giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus) (12/15/88)
In article <8812130122.AA21360@caesar.cs.montana.edu> icsu6000@CAESAR.CS.MONTANA.EDU (Mathisen) writes: > > Only one machine passed the test, out of the 3 I tried it on, and >that was a mVAX II running Ultrix 2.3, both the Apollo and an HP9000/350 SRX >crapped out. I am suspicious. Have you given an example of this to Apollo? Have you used the debugger to find out where the program is? Have you used the tb (trace back) command to see where the program is? Does your program get through lint? It is not my experience that the C compiler is so easy to break. If you think you have found a bug, please file an apr or ucr to report it (do a help on crucr or a man on mkapr if you are not sure how to report a bug). >[...] I'm suprised >by the pathetic compilation speed of the 3500, sounds like some serious >C compiler work is needed here. Did you use the /com/cc or /bin/cc? /com/cc will default to doing some optimization. As you know, this will take longer. The documentation for /com/cc states that the default optimization is 3 on a 0 to 4 scale where 4 is the highest level of optimization. >I'd be happy to send the source to anybody who wants it. I want to be sure Apollo gets a copy of the code. If your sales person is uninterested, you do not wish to place an APR, and you do not have a service contract to call the help line, please send the code to me so I can enter an APR myself. -- UUCP: uunet!hi-csc!giebelhaus UUCP: tim@apollo.uucp ARPA: hi-csc!giebelhaus@umn-cs.arpa ARPA: tim@apollo.com Tim Giebelhaus, Apollo Computer, Regional Software Support Specialist. My comments and opinions have nothing to do with work.