Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!apollo!rehrauer From: rehrauer@apollo.HP.COM (Steve Rehrauer) Newsgroups: comp.sys.apollo Subject: Re: PRISM Fortran compiler causes trashing! Message-ID: <478a5a3f.20b6d@apollo.HP.COM> Date: 20 Dec 89 15:30:00 GMT References: <129179@sun.Eng.Sun.COM> Sender: root@apollo.HP.COM Reply-To: rehrauer@apollo.HP.COM (Steve Rehrauer) Organization: Hewlett-Packard Apollo Division - Chelmsford, MA Lines: 48 In article hanche@imf.unit.no (Harald Hanche-Olsen) writes: >This is a short tale about a long FORTRAN compilation on the DN10000. >... >Rhetoric question: What do those compiler writers at HP/apollo think >they're doing? Writing for machines with a minimum of 128M of memory? (I'm responding for Bruce Olsen regards Prism compiler performance. These are his words, not mine.) --------------------------------------------- Mr. Hanche-Olsen has evidently encountered a compile_time performance problem that we have not seen. He got these results with the first release Fortran compiler, compiling on a machine configured with the minimum amount of physical memory. The design goals for the DN10000 compilers were ( in priority order ) - Code Quality, - Reliability, - Compile-time efficiency. While we were very pleased with the levels of code quality an reliability that we attained, the initial release did not exhibit the level of compile- time efficiency that we wanted. The second release shows substantial improvement. The typical user, compiling code that is not dramatically too large for his physical memory, will see compile speeds on the order of several thousand lines per minute. Your mileage may vary. We expect to make further substantial compile-time improvements in subsequent releases. In sum, we believe that you can expect good compile times on the DN10000 provided that you have a reasonable amount of physical memory for the job at hand. When you're estimating your memory needs, keep in mind that code for most RISC machines is 1.5 -2.0X as large as the corresponding code for CISC machines. Again, your mileage may vary. Also, it generally requires a sophisticated compiler to take advantage of the improved run-time performance of RISC architectures. Such compilers tend to be bigger and (yes, we admit it) slower than comparable CISC compilers. The payoff, we believe, is that your program runs faster. Should you experience this problem (or any other), we would of course welcome any input that can help us reproduce and analyze it. Bruce Olsen Apollo Division/HP -- >>"Aaiiyeeee! Death from above!"<< | Steve Rehrauer, rehrauer@apollo.hp.com "Flee, lest we be trod upon!" | The Apollo System Division of H.P.