Re: question about -fno-pre-inlining
In case anyone else was following this, I've discovered the source of the differing output. I had made some assumptions about when some code would be executed based upon faulty reasoning. Without pre-inlining those assumptions happened to hold, but they did not when pre-inlining was enabled. Thanks to Echo Nolan who independently discovered my error. Now that I've fixed this issue, the output is the same (and correct) regardless of compiler flags. It's still faster without pre-inlining, but that's a relatively minor problem in comparison. Sincerely, John On Thu, Jun 18, 2009 at 11:16 AM, Simon Peyton-Jones 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
Re: question about -fno-pre-inlining
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 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
RE: question about -fno-pre-inlining
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
