question about -fno-pre-inlining

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

question about -fno-pre-inlining

John Lato-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

RE: question about -fno-pre-inlining

Simon Peyton Jones
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: [hidden email] [mailto:glasgow-haskell-users-
| [hidden email]] On Behalf Of John Lato
| Sent: 18 June 2009 09:58
| To: [hidden email]
| 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
| [hidden email]
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: question about -fno-pre-inlining

John Lato-2
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<[hidden email]> 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: [hidden email] [mailto:glasgow-haskell-users-
> | [hidden email]] On Behalf Of John Lato
> | Sent: 18 June 2009 09:58
> | To: [hidden email]
> | 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
> | [hidden email]
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: question about -fno-pre-inlining

John Lato-2
In reply to this post by Simon Peyton Jones
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<[hidden email]> 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: [hidden email] [mailto:glasgow-haskell-users-
> | [hidden email]] On Behalf Of John Lato
> | Sent: 18 June 2009 09:58
> | To: [hidden email]
> | 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
> | [hidden email]
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users