question about -fno-pre-inlining

[John Lato]

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<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
>
>