Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!xanth!mcnc!rti!xyzzy!dg-rtp!meissner From: meissner@dg-rtp.dg.com (Michael Meissner) Newsgroups: comp.arch Subject: Re: FORTRAN Dhrystone for i860? [NO Message-ID: <4926@xyzzy.UUCP> Date: 5 Apr 89 20:08:43 GMT References: <15347@winchester.mips.COM> <46500054@uxe.cso.uiuc.edu> Sender: usenet@xyzzy.UUCP Reply-To: meissner@dg-rtp.UUCP (Michael Meissner) Organization: Data General (Languages @ Research Triangle Park, NC.) Lines: 46 In article grunwald@flute.cs.uiuc.edu writes: | | re: does greenhills auto-inline strcpy & strlen, etc? | | yes, they do, on the 386 compiler we have. In addition, they also inline | cos/sin/tan automatically, and possibly some other functions (memcpy, etc) | as well. | | I noticed this when comparing Gnu C to Greenhills C on a 386. Once you discount | the strcpy hacks, Gnu C is about the same speed (this was 1.30, 1.34 and up | should be better due to loop opt. changes). I've been meaning to post for sometime, about my experiences with GNU and dhrystone. For our 88k machines, Data General decided to go with the GNU compiler for it's default compiler, for various reasons, instead of using Greenhills. Anyway, when the GNU compiler was complete enough to run benchmarks, we naturally ran dhrystone, and found that for the 20 MHz Motorola Anglefire, the then current Greenhills compiler came in at about 31,000 dhrystones, wheras the best I could get GNU was around 19,000. Needless to say this caused some soul searching, and poring over the generated code. The only thing that we found that was substanially different was that the Greenhills compiler had changed the 4 strcpy calls into calls to an internal function with the two pointers and the length. GNU was just calling strcpy directly. By editing the assembly languange output to call the same routine Greenhills did, the GNU compiler suddenly spurted to 33,000 dhrystones. In addition to high amounts of time being consumed by strcpy, we also discovered that naive single-byte strcmp's will dramatically lower your dhrystones as well. Note, I think it perfectially legitimate to optimize calls to strcpy and friends if you can do it in a safe fashion. I don't think that strcpy's where the second argument is a constant string, is as frequent as normal strcpy's, so I tend to think that dhrystone in this case is not measuring typicall integer performance. We eventually modified the compiler to optimize strcpy, and memcpy (and to a limited extent, strcmp, and memcmp). Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?