Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!panews!slo.awdpa.ibm.com!jsalter From: jsalter@ibmpa.awdpa.ibm.com Newsgroups: comp.unix.aix Subject: Re: Help catching floating point exceptions Message-ID: <1991Jun6.032233.10629@ibmpa.awdpa.ibm.com> Date: 6 Jun 91 03:22:33 GMT References: <1991May27.213751.24223@murdoch.acc.Virginia.EDU> < <91149.150333AER7101@TECHNION.BITNET>> <1991May31.071822.9206@marlin.jcu.edu.au> Sender: news@ibmpa.awdpa.ibm.com (News Master) Reply-To: jsalter@slo.awdpa.ibm.com (Jim Salter) Organization: IBM PSP Development, Palo Alto, CA Lines: 33 In article <1991May31.071822.9206@marlin.jcu.edu.au> csrdh@marlin.jcu.edu.au (Rowan Hughes) writes: >In sdl@adagio.austin.ibm.com (sdl) writes: >DEC have released their new f77v3.0 compiler for the DECStations >(=R3000) and it traps all floating exceptions; the job aborts >with a core dump. I've done some benchmarking between the new and old >compilers (with and without fpe) and the performance has dropped by >less than 1/2%. Fpe is enabled ALL the time, irrelevent of >compiler options. [...] >It can be done easily on RISC, with no loss in performance. True, it *can* be done on RISC architectures. That's not the point. The point is whether it should be done on the POWER architecture the '6000s employ. I don't believe the R3000 is super-scalar, thereby limiting the effects of trapping. Since the '6000 is, instructions are scheduled out-of-order by the compilers to ensure the pipeline remains full for as long as possible. What trapping does is *serialize* the execution, forcing the instructions to be in-order, thus greatly limiting the performance by, as been noted many times, an order-of-magnitude. This is not a trivial performance hit. The first-generation SPARC may be only 2-3 MFLOPS, but to bring the '6000 down to 2-3 MFLOPS really hurts. I think everyone would agree that the FP performance of the '6000 is one of it's best points. To turn trapping on all the time would be marketing suicide. >Rowan Hughes James Cook University >Marine Modelling Unit Townsville, Australia. >Dept. Civil and Systems Engineering csrdh@marlin.jcu.edu.au jim/jsalter IBM PSP, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: jsalter@slo.awdpa.ibm.com UUCP: ..!uunet!ibmsupt!jsalter "IBM part #23521, aka Lt. Commander Data" The stuff above is on my own.