question about -fno-pre-inlining
John Lato
jwlato at gmail.com
Fri Jun 26 05:34:14 EDT 2009
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<simonpj at 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-bounces at haskell.org [mailto:glasgow-haskell-users-
> | bounces at haskell.org] On Behalf Of John Lato
> | Sent: 18 June 2009 09:58
> | To: glasgow-haskell-users at 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 at haskell.org
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
More information about the Glasgow-haskell-users
mailing list