Simon, Thanks for the quick reply, and also the link. I'll be sure to read it. I don't know what pre-inlining is; I was testing different compiler options with acovea, which indicated the performance boost. When I tried it myself, I noticed the differing value.
I'm pretty sure the affected code is in a library I'm developing. If I turn off pre-inlining when compiling the library I get the same final value as when turning it off in just the test program, although performance is markedly worse. Unfortunately that doesn't narrow it down much; there are several modules in the library. The algorithm shouldn't be particularly sensitive. I'm just normalize Ints to Doubles in the range +- 1.0 and finding the maximum. I'm not using the FFI, but there are a few questionable tactics employed. In particular, I'm doing both: 1. Casting Ptr's (in IO). 2. Using an Int24 data type that has operations on unboxed Int#'s, similar to Int16's implementation. Of course the problem may be unrelated to both of these. I just wanted to find out if this was expected or not before I attempt to isolate it, because that will take a bit of work. I'll see what I can do, but it may be a while before I make any progress. Cheers, John On Thu, Jun 18, 2009 at 11:16 AM, Simon Peyton-Jones<simo...@microsoft.com> wrote: > John > > | When compiled with -fno-pre-inlining, my test program gives a > | different result than compiled without (0.988... :: Double, compared > | to 1.0). It's numerical code, and was originally compiled with > > That's entirely unexpected. I am very surprised that turning off pre-inlining > a) affects the results at all > b) improves performance > > Of course this is a floating point program, where various numeric > transformations are invalid if you want bit-for-bit accuracy. (eg addition > is not associative). But a 2% change seems big, unless it's a very > sensitive algorithm. > > To find out what "pre-inlining" is read Section 5 of > http://research.microsoft.com/en-us/um/people/simonpj/papers/inlining/inline-jfp.ps.gz > It's called "PreInlineUnconditionally" there. > > I'm not sure how to proceed. The more you can boil it down, the easier it'll > be to find out what is going on. One way to do this is to make the program > smaller. But even finding out which function is sensitive to the setting of > -fno-pre-inlining would be interesting. (You can't set this on a function by > function basis, so you'll have to split the module.) > > If you can make a self-contained test case, do make a Trac ticket for it. > > Are you using the FFI? > > All very odd. > > Simon > > | -----Original Message----- > | From: glasgow-haskell-users-boun...@haskell.org > [mailto:glasgow-haskell-users- > | boun...@haskell.org] On Behalf Of John Lato > | Sent: 18 June 2009 09:58 > | To: glasgow-haskell-users@haskell.org > | Subject: question about -fno-pre-inlining > | > | Hello, > | > | I was experimenting with compiler flags trying to tune some > | performance and got something unexpected with the -fno-pre-inlining > | flag. I was hoping somebody here might be able to clarify an issue > | for me. > | > | When compiled with -fno-pre-inlining, my test program gives a > | different result than compiled without (0.988... :: Double, compared > | to 1.0). It's numerical code, and was originally compiled with > | -fexcess-precision, however I have tried both with and without > | -fexcess-precision and the results are the same. The only other > | compiler flags in use are -O2 and --make. Is this expected behavior > | or a possible bug? I believe the value with -fno-pre-inlining is > | correct (and runs about 30% faster too). > | > | This was done on an OSX 10.5 Macbook with GHC-6.10.3. I could check > | this on some other systems if it would be helpful. > | > | Sincerely, > | John Lato > | _______________________________________________ > | Glasgow-haskell-users mailing list > | Glasgow-haskell-users@haskell.org > | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
