Carter Schonwald | 16 Sep 21:59 2013
Picon

add INLINEABLE to maybe, either, bool

Its come to my attention that maybe, either, and its new sibling bool, all lack the 
INLINEABLE attribute, or its more aggressive sibling INLINE

this seems like one of those operations where inlining in client use sites is a good option to have, and currently not possible!

theres probably other stuff that would benefit from an INLINEABLE pragma in base,
but this is an obvious, simple, "easy win" that I noticed when Oliver's patch got merged into base.

Thoughts?
Time scale: sometime this week? (ghc 7.8 merge window is landing!)

cheers
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Carter Schonwald | 16 Sep 22:11 2013
Picon

Re: add INLINEABLE to maybe, either, bool

woops, i've been corrected, this is a total non issue, 

pardon the noise. 


On Mon, Sep 16, 2013 at 3:59 PM, Carter Schonwald <carter.schonwald <at> gmail.com> wrote:
Its come to my attention that maybe, either, and its new sibling bool, all lack the 
INLINEABLE attribute, or its more aggressive sibling INLINE

this seems like one of those operations where inlining in client use sites is a good option to have, and currently not possible!

theres probably other stuff that would benefit from an INLINEABLE pragma in base,
but this is an obvious, simple, "easy win" that I noticed when Oliver's patch got merged into base.

Thoughts?
Time scale: sometime this week? (ghc 7.8 merge window is landing!)

cheers

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Austin Seipp | 16 Sep 22:12 2013

Re: add INLINEABLE to maybe, either, bool

I'm strongly opposed to this.

Being INLINE happy is not a good thing, it is a bad thing. More often
than not, I see people stuffing INLINE all over the place for things
that would trivially be unfolded and put in the interface file anyway.
This is bad, and it teaches people to just use the INLINE hammer
everywhere instead of understanding the actual implications of what
the inliner does. It also makes it impossible to actually observe how
the inliner behaves and see where it needs tuning: if we just mark
everything INLINE, we might as well not have it and make it
unconditional.

There are some particular cases where GHC is hesitant to inline small
things if it would lead to work duplication, or where the inliner
behavior is tweaked and you may want to force it across multiple
versions to be sure (lens is a good example of this.) But this is far
more rare, and this case is not that. In particular, Joachim checked
the 'bool' commit. As expected, the unfolding for bool was put into
the interface file for Data.Bool, meaning if you use -O (or just -O0
-fno-ignore-interface-pragmas,) it should be inlined at call sites
appropriately when it is used.

If we're going to INLINE things, we need to make sure it actually has
an empirical benefit, by looking at the core, and seeing where the
inliner is failing. Not just attach it to things because it seems like
a good idea. This also helps drive feedback into the inliner so we can
see where it fails.

On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
<carter.schonwald <at> gmail.com> wrote:
> Its come to my attention that maybe, either, and its new sibling bool, all
> lack the
> INLINEABLE attribute, or its more aggressive sibling INLINE
>
> this seems like one of those operations where inlining in client use sites
> is a good option to have, and currently not possible!
>
> theres probably other stuff that would benefit from an INLINEABLE pragma in
> base,
> but this is an obvious, simple, "easy win" that I noticed when Oliver's
> patch got merged into base.
>
> Thoughts?
> Time scale: sometime this week? (ghc 7.8 merge window is landing!)
>
> cheers
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

--

-- 
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
Edward Kmett | 16 Sep 22:33 2013
Picon

Re: add INLINEABLE to maybe, either, bool

Contrary to appearances, I fully agree. =)


On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin <at> well-typed.com> wrote:
I'm strongly opposed to this.

Being INLINE happy is not a good thing, it is a bad thing. More often
than not, I see people stuffing INLINE all over the place for things
that would trivially be unfolded and put in the interface file anyway.
This is bad, and it teaches people to just use the INLINE hammer
everywhere instead of understanding the actual implications of what
the inliner does. It also makes it impossible to actually observe how
the inliner behaves and see where it needs tuning: if we just mark
everything INLINE, we might as well not have it and make it
unconditional.

There are some particular cases where GHC is hesitant to inline small
things if it would lead to work duplication, or where the inliner
behavior is tweaked and you may want to force it across multiple
versions to be sure (lens is a good example of this.) But this is far
more rare, and this case is not that. In particular, Joachim checked
the 'bool' commit. As expected, the unfolding for bool was put into
the interface file for Data.Bool, meaning if you use -O (or just -O0
-fno-ignore-interface-pragmas,) it should be inlined at call sites
appropriately when it is used.

If we're going to INLINE things, we need to make sure it actually has
an empirical benefit, by looking at the core, and seeing where the
inliner is failing. Not just attach it to things because it seems like
a good idea. This also helps drive feedback into the inliner so we can
see where it fails.

On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
<carter.schonwald <at> gmail.com> wrote:
> Its come to my attention that maybe, either, and its new sibling bool, all
> lack the
> INLINEABLE attribute, or its more aggressive sibling INLINE
>
> this seems like one of those operations where inlining in client use sites
> is a good option to have, and currently not possible!
>
> theres probably other stuff that would benefit from an INLINEABLE pragma in
> base,
> but this is an obvious, simple, "easy win" that I noticed when Oliver's
> patch got merged into base.
>
> Thoughts?
> Time scale: sometime this week? (ghc 7.8 merge window is landing!)
>
> cheers
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Dan Burton | 16 Sep 22:59 2013
Picon

Re: add INLINEABLE to maybe, either, bool

I'm wary of "let's not mark it as INLINE because we want the compiler to automagically inline it for us." This seems like saying we should not have type signatures, because we want the type inferencer to figure it out for us. (If you want to test the auto-inliner's wisdom, then just add a setting that ignores INLINE pragmas and see if it inlines the same thing that humans do?)

I don't really care how it's accomplished, but I do think that we should make sure that maybe, either, and bool are inlined, and the most obvious way to accomplish this is to directly mark them INLINE, is it not?

-- Dan Burton


On Mon, Sep 16, 2013 at 1:33 PM, Edward Kmett <ekmett <at> gmail.com> wrote:
Contrary to appearances, I fully agree. =)


On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin <at> well-typed.com> wrote:
I'm strongly opposed to this.

Being INLINE happy is not a good thing, it is a bad thing. More often
than not, I see people stuffing INLINE all over the place for things
that would trivially be unfolded and put in the interface file anyway.
This is bad, and it teaches people to just use the INLINE hammer
everywhere instead of understanding the actual implications of what
the inliner does. It also makes it impossible to actually observe how
the inliner behaves and see where it needs tuning: if we just mark
everything INLINE, we might as well not have it and make it
unconditional.

There are some particular cases where GHC is hesitant to inline small
things if it would lead to work duplication, or where the inliner
behavior is tweaked and you may want to force it across multiple
versions to be sure (lens is a good example of this.) But this is far
more rare, and this case is not that. In particular, Joachim checked
the 'bool' commit. As expected, the unfolding for bool was put into
the interface file for Data.Bool, meaning if you use -O (or just -O0
-fno-ignore-interface-pragmas,) it should be inlined at call sites
appropriately when it is used.

If we're going to INLINE things, we need to make sure it actually has
an empirical benefit, by looking at the core, and seeing where the
inliner is failing. Not just attach it to things because it seems like
a good idea. This also helps drive feedback into the inliner so we can
see where it fails.

On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
<carter.schonwald <at> gmail.com> wrote:
> Its come to my attention that maybe, either, and its new sibling bool, all
> lack the
> INLINEABLE attribute, or its more aggressive sibling INLINE
>
> this seems like one of those operations where inlining in client use sites
> is a good option to have, and currently not possible!
>
> theres probably other stuff that would benefit from an INLINEABLE pragma in
> base,
> but this is an obvious, simple, "easy win" that I noticed when Oliver's
> patch got merged into base.
>
> Thoughts?
> Time scale: sometime this week? (ghc 7.8 merge window is landing!)
>
> cheers
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Austin Seipp | 16 Sep 23:56 2013

Re: add INLINEABLE to maybe, either, bool

A serious question: if you don't even trust GHC to inline 'bool',
'maybe' or 'either', given their triviality, do you trust it to ever
inline anything at all? I'm being completely honest here.

It still ignores the question of *why* the inliner is failing to do
what you want. If the type inferencer fails to infer the type of an
utterly trivial function - let's again say 'bool :: a -> a -> Bool ->
a', as it's type is about as trivial as it's definition - it is almost
certainly broken. By the same token, GHC not inlining 'bool' under -O
would almost certainly be a bug too, in my eyes. The definition is
trivial to the point where we should not ask "what if it doesn't
inline" - we should figure out WHY it does not do so. Maybe INLINE
would be a justified way of fixing it, but in this case it's just
unnecessary and has been verified as such.

By the same token, we also don't encourage people to wildly put `seq`
everywhere, or make everything on earth strict just because it makes
them feel good.

A compiler must work on a broad range of programs for a broad range of
use cases. There are certainly some cases that the compiler is *not*
tuned for. In some of these cases, we work to make them more
efficient. We patch the compiler to make it better where-ever
possible. But this case? This is nothing but a premature optimization
in my eyes - and one that even people like Edward or myself are guilty
of, for sure.* And I am repenting by rejecting the "INLINE school of
thought" (or INLINE school of hammers, as it were.)

If you want to make the argument that 'bool' - or something else even
- should be INLINE, by all means do so. But if you're going to do so
without any empirical cases, or examples of why it should be so
(especially when we have already checked the interface files,) and
just say it lets you sleep better at night? I simply do not buy it.

On Mon, Sep 16, 2013 at 3:59 PM, Dan Burton <danburton.email <at> gmail.com> wrote:
> I'm wary of "let's not mark it as INLINE because we want the compiler to
> automagically inline it for us." This seems like saying we should not have
> type signatures, because we want the type inferencer to figure it out for
> us. (If you want to test the auto-inliner's wisdom, then just add a setting
> that ignores INLINE pragmas and see if it inlines the same thing that humans
> do?)
>
> I don't really care how it's accomplished, but I do think that we should
> make sure that maybe, either, and bool are inlined, and the most obvious way
> to accomplish this is to directly mark them INLINE, is it not?
>
> -- Dan Burton
>
>
> On Mon, Sep 16, 2013 at 1:33 PM, Edward Kmett <ekmett <at> gmail.com> wrote:
>>
>> Contrary to appearances, I fully agree. =)
>>
>>
>> On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin <at> well-typed.com>
>> wrote:
>>>
>>> I'm strongly opposed to this.
>>>
>>> Being INLINE happy is not a good thing, it is a bad thing. More often
>>> than not, I see people stuffing INLINE all over the place for things
>>> that would trivially be unfolded and put in the interface file anyway.
>>> This is bad, and it teaches people to just use the INLINE hammer
>>> everywhere instead of understanding the actual implications of what
>>> the inliner does. It also makes it impossible to actually observe how
>>> the inliner behaves and see where it needs tuning: if we just mark
>>> everything INLINE, we might as well not have it and make it
>>> unconditional.
>>>
>>> There are some particular cases where GHC is hesitant to inline small
>>> things if it would lead to work duplication, or where the inliner
>>> behavior is tweaked and you may want to force it across multiple
>>> versions to be sure (lens is a good example of this.) But this is far
>>> more rare, and this case is not that. In particular, Joachim checked
>>> the 'bool' commit. As expected, the unfolding for bool was put into
>>> the interface file for Data.Bool, meaning if you use -O (or just -O0
>>> -fno-ignore-interface-pragmas,) it should be inlined at call sites
>>> appropriately when it is used.
>>>
>>> If we're going to INLINE things, we need to make sure it actually has
>>> an empirical benefit, by looking at the core, and seeing where the
>>> inliner is failing. Not just attach it to things because it seems like
>>> a good idea. This also helps drive feedback into the inliner so we can
>>> see where it fails.
>>>
>>> On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
>>> <carter.schonwald <at> gmail.com> wrote:
>>> > Its come to my attention that maybe, either, and its new sibling bool,
>>> > all
>>> > lack the
>>> > INLINEABLE attribute, or its more aggressive sibling INLINE
>>> >
>>> > this seems like one of those operations where inlining in client use
>>> > sites
>>> > is a good option to have, and currently not possible!
>>> >
>>> > theres probably other stuff that would benefit from an INLINEABLE
>>> > pragma in
>>> > base,
>>> > but this is an obvious, simple, "easy win" that I noticed when Oliver's
>>> > patch got merged into base.
>>> >
>>> > Thoughts?
>>> > Time scale: sometime this week? (ghc 7.8 merge window is landing!)
>>> >
>>> > cheers
>>> >
>>> > _______________________________________________
>>> > Libraries mailing list
>>> > Libraries <at> haskell.org
>>> > http://www.haskell.org/mailman/listinfo/libraries
>>> >
>>>
>>>
>>>
>>> --
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries <at> haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>

--

-- 
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
Austin Seipp | 17 Sep 01:03 2013

Re: add INLINEABLE to maybe, either, bool

In light of some recent conversations with others and self-review, I
realize my prior messages may have been too strong, come off as
hostile, or outright combative.

I'd like to publicly apologize for that: I'm sorry to ruffle feathers.
(As a GHC developer, what seems 'obvious' to me is much different than
most people, I realize.)

Now, in light of some discussions I had on IRC, there *are* things we
can do here, and I'd like to lightly recap my position and some other
points. To wit:

 * I think it is bad to overuse things like INLINE, and I believe it
encourages people to not understand the implications of what the
compiler is doing (all programmers generally must have some intuition
and control over their programs, and how they run.)

 * Using the INLINE hammer everywhere makes it *incredibly* difficult
to see where GHC deficiencies are, and that's not what we want - it
hurts our ability to have informed decisions and examples. I also find
it slightly disheartening that many people don't think GHC can handle
cases like this.

 * But Haskell is a language where inlining may not make a
constant-factor difference, but *orders of magnitude difference*.
vector-algorithms is a good example of this, and I'm not sure anyone
knows how to 'fix it' so it doesn't have to INLINE literally
everything. We're talking 10 orders of magnitude difference, if I
remember my conversations with Dan/Edward correctly. lens is a lesser
example: there are cases where GHC won't inline due to fear of work
duplication or other unusual cases, but we can tackle these in GHC in
some cases (and have.)

 * We tend to be quite sensitive to performance matters as a community, I feel.

 * And sometimes, things are hard. Even for people like Simon,
'fixing' bad inliner behavior can be a monstrous task, and INLINE is
certainly a way to help the compiler when its hands are tied.

Ultimately, nobody is wrong here. But we have options, and two of them
people brought up are good ones I think.

 1.) Perhaps GHC should have a flag to warn you if you use
INLINE/INLINEABLE on a definition that the inliner would have dealt
with anyway. This should not be on by default with -Wall. But it would
give us a useful tool to examine our assumptions more easily in a lot
of cases.

 2.) GHC does have a testsuite with many performance-related tests,
and tests that check the Core. We could easily add a test that checked
the core output of bool, maybe, and either (and other functions, as
time may go on.) This is much easier and probably more robust than
trying to contrive an example of what the performance difference might
be.

Personally, I am way more interested in #1, as opposed to #2 (a
failure to inline something so small would quickly be noticed -
because lots of things probably won't inline at that point and our
tests will fail!) However, I believe both of these are relatively
easy, and quite feasible to implement.

Unfortunately, I have about 10,000,000 things on my plate with the
upcoming release. So I'm afraid I don't have time to do these myself.

So, patches welcome! However, I am more than willing to help people
get their feet wet in doing the work. You can email me (same email I'm
using now,) or contact me on IRC (freenode, nick 'thoughtpolice') if
you prefer more real time communication. I'll help you to the best of
my abilities if you'd like to give it a go.

On Mon, Sep 16, 2013 at 4:56 PM, Austin Seipp <austin <at> well-typed.com> wrote:
> A serious question: if you don't even trust GHC to inline 'bool',
> 'maybe' or 'either', given their triviality, do you trust it to ever
> inline anything at all? I'm being completely honest here.
>
> It still ignores the question of *why* the inliner is failing to do
> what you want. If the type inferencer fails to infer the type of an
> utterly trivial function - let's again say 'bool :: a -> a -> Bool ->
> a', as it's type is about as trivial as it's definition - it is almost
> certainly broken. By the same token, GHC not inlining 'bool' under -O
> would almost certainly be a bug too, in my eyes. The definition is
> trivial to the point where we should not ask "what if it doesn't
> inline" - we should figure out WHY it does not do so. Maybe INLINE
> would be a justified way of fixing it, but in this case it's just
> unnecessary and has been verified as such.
>
> By the same token, we also don't encourage people to wildly put `seq`
> everywhere, or make everything on earth strict just because it makes
> them feel good.
>
> A compiler must work on a broad range of programs for a broad range of
> use cases. There are certainly some cases that the compiler is *not*
> tuned for. In some of these cases, we work to make them more
> efficient. We patch the compiler to make it better where-ever
> possible. But this case? This is nothing but a premature optimization
> in my eyes - and one that even people like Edward or myself are guilty
> of, for sure.* And I am repenting by rejecting the "INLINE school of
> thought" (or INLINE school of hammers, as it were.)
>
> If you want to make the argument that 'bool' - or something else even
> - should be INLINE, by all means do so. But if you're going to do so
> without any empirical cases, or examples of why it should be so
> (especially when we have already checked the interface files,) and
> just say it lets you sleep better at night? I simply do not buy it.
>
>
> On Mon, Sep 16, 2013 at 3:59 PM, Dan Burton <danburton.email <at> gmail.com> wrote:
>> I'm wary of "let's not mark it as INLINE because we want the compiler to
>> automagically inline it for us." This seems like saying we should not have
>> type signatures, because we want the type inferencer to figure it out for
>> us. (If you want to test the auto-inliner's wisdom, then just add a setting
>> that ignores INLINE pragmas and see if it inlines the same thing that humans
>> do?)
>>
>> I don't really care how it's accomplished, but I do think that we should
>> make sure that maybe, either, and bool are inlined, and the most obvious way
>> to accomplish this is to directly mark them INLINE, is it not?
>>
>> -- Dan Burton
>>
>>
>> On Mon, Sep 16, 2013 at 1:33 PM, Edward Kmett <ekmett <at> gmail.com> wrote:
>>>
>>> Contrary to appearances, I fully agree. =)
>>>
>>>
>>> On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin <at> well-typed.com>
>>> wrote:
>>>>
>>>> I'm strongly opposed to this.
>>>>
>>>> Being INLINE happy is not a good thing, it is a bad thing. More often
>>>> than not, I see people stuffing INLINE all over the place for things
>>>> that would trivially be unfolded and put in the interface file anyway.
>>>> This is bad, and it teaches people to just use the INLINE hammer
>>>> everywhere instead of understanding the actual implications of what
>>>> the inliner does. It also makes it impossible to actually observe how
>>>> the inliner behaves and see where it needs tuning: if we just mark
>>>> everything INLINE, we might as well not have it and make it
>>>> unconditional.
>>>>
>>>> There are some particular cases where GHC is hesitant to inline small
>>>> things if it would lead to work duplication, or where the inliner
>>>> behavior is tweaked and you may want to force it across multiple
>>>> versions to be sure (lens is a good example of this.) But this is far
>>>> more rare, and this case is not that. In particular, Joachim checked
>>>> the 'bool' commit. As expected, the unfolding for bool was put into
>>>> the interface file for Data.Bool, meaning if you use -O (or just -O0
>>>> -fno-ignore-interface-pragmas,) it should be inlined at call sites
>>>> appropriately when it is used.
>>>>
>>>> If we're going to INLINE things, we need to make sure it actually has
>>>> an empirical benefit, by looking at the core, and seeing where the
>>>> inliner is failing. Not just attach it to things because it seems like
>>>> a good idea. This also helps drive feedback into the inliner so we can
>>>> see where it fails.
>>>>
>>>> On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
>>>> <carter.schonwald <at> gmail.com> wrote:
>>>> > Its come to my attention that maybe, either, and its new sibling bool,
>>>> > all
>>>> > lack the
>>>> > INLINEABLE attribute, or its more aggressive sibling INLINE
>>>> >
>>>> > this seems like one of those operations where inlining in client use
>>>> > sites
>>>> > is a good option to have, and currently not possible!
>>>> >
>>>> > theres probably other stuff that would benefit from an INLINEABLE
>>>> > pragma in
>>>> > base,
>>>> > but this is an obvious, simple, "easy win" that I noticed when Oliver's
>>>> > patch got merged into base.
>>>> >
>>>> > Thoughts?
>>>> > Time scale: sometime this week? (ghc 7.8 merge window is landing!)
>>>> >
>>>> > cheers
>>>> >
>>>> > _______________________________________________
>>>> > Libraries mailing list
>>>> > Libraries <at> haskell.org
>>>> > http://www.haskell.org/mailman/listinfo/libraries
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Austin Seipp, Haskell Consultant
>>>> Well-Typed LLP, http://www.well-typed.com/
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries <at> haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>>
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries <at> haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>>
>>
>
>
>
> --
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/

--

-- 
Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
Roman Cheplyaka | 17 Sep 15:11 2013

Re: add INLINEABLE to maybe, either, bool

Austin,

First of all, let me say that I am generally on the same side of this
argument as you are now.

But Dan raised very good and valid points, and I don't think you
addressed them directly (quotations follow):

1. If you want to test the auto-inliner's wisdom, then just add a
   setting that ignores INLINE pragmas and see if it inlines the same
   thing that humans do?
2. I don't really care how it's accomplished, but I do think that we should
   make sure that maybe, either, and bool are inlined, and the most obvious
   way to accomplish this is to directly mark them INLINE, is it not?

Roman
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Dan Burton | 17 Sep 19:27 2013
Picon

Re: add INLINEABLE to maybe, either, bool

I again want to emphasize how we can view INLINE annotations much the same way as type annotations. It is considered good practice to annotate top-level definitions with type signatures. Why? Is it because the compiler can't figure it out? Is it because the programmer doesn't trust the compiler to figure it out? No, it's because it is a visible, enforced sanity check to make sure that the programmer and the compiler are on the same page, regardless of any magic the compiler is capable of. (I like the various ideas that are being thrown around about "asserting" that something will be inlined.)

I see superfluous INLINE pragmas as for the benefit of humans, allowing them to express their desires explicitly, rather than relying on implicit behavior that is hard for the average muggle to understand, verify, or guarantee. If someone reads through the source, and wonders whether "bool" will be inlined, they don't need to know any details about the current state of the inliner algorithm when they can just see the pragma right there in the source.

The inliner should be at the whim of its masters, the humans, not the other way around.


-- Dan Burton


On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
Austin,

First of all, let me say that I am generally on the same side of this
argument as you are now.

But Dan raised very good and valid points, and I don't think you
addressed them directly (quotations follow):

1. If you want to test the auto-inliner's wisdom, then just add a
   setting that ignores INLINE pragmas and see if it inlines the same
   thing that humans do?
2. I don't really care how it's accomplished, but I do think that we should
   make sure that maybe, either, and bool are inlined, and the most obvious
   way to accomplish this is to directly mark them INLINE, is it not?

Roman

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 17 Sep 19:40 2013
Picon

Re: add INLINEABLE to maybe, either, bool

Aside: INLINE pragmas do more than INLINE nowadays, they prevent the RHS (to be inlined) from being optimized before inlining happens. This makes it interfere badly with INLINABLE. For example, if you have:

f = g
{-# INLINE f #-}

g :: Hashable a => ...
g = ...
{-# INLINABLE g #-}

INLINE makes the call site specialization that INLINABLE otherwise gives fail.

I for one miss the old INLINE.

On Tue, Sep 17, 2013 at 10:27 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
I again want to emphasize how we can view INLINE annotations much the same way as type annotations. It is considered good practice to annotate top-level definitions with type signatures. Why? Is it because the compiler can't figure it out? Is it because the programmer doesn't trust the compiler to figure it out? No, it's because it is a visible, enforced sanity check to make sure that the programmer and the compiler are on the same page, regardless of any magic the compiler is capable of. (I like the various ideas that are being thrown around about "asserting" that something will be inlined.)

I see superfluous INLINE pragmas as for the benefit of humans, allowing them to express their desires explicitly, rather than relying on implicit behavior that is hard for the average muggle to understand, verify, or guarantee. If someone reads through the source, and wonders whether "bool" will be inlined, they don't need to know any details about the current state of the inliner algorithm when they can just see the pragma right there in the source.

The inliner should be at the whim of its masters, the humans, not the other way around.


-- Dan Burton


On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
Austin,

First of all, let me say that I am generally on the same side of this
argument as you are now.

But Dan raised very good and valid points, and I don't think you
addressed them directly (quotations follow):

1. If you want to test the auto-inliner's wisdom, then just add a
   setting that ignores INLINE pragmas and see if it inlines the same
   thing that humans do?
2. I don't really care how it's accomplished, but I do think that we should
   make sure that maybe, either, and bool are inlined, and the most obvious
   way to accomplish this is to directly mark them INLINE, is it not?

Roman

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Simon Peyton-Jones | 17 Sep 19:45 2013
Picon

RE: add INLINEABLE to maybe, either, bool

Johan

 

I don’t understand your difficulty below at all.  After all, at every call site of ‘f’ we will inline it, as the INLINE pragma stipulates; and then we’ll generate specialised code for g, exactly as (I suppose) you hope. 

 

What other behaviour did you seek?

                                      

Simon

 

From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of Johan Tibell
Sent: 17 September 2013 18:41
To: Dan Burton
Cc: Haskell Libraries
Subject: Re: add INLINEABLE to maybe, either, bool

 

Aside: INLINE pragmas do more than INLINE nowadays, they prevent the RHS (to be inlined) from being optimized before inlining happens. This makes it interfere badly with INLINABLE. For example, if you have:

 

f = g

{-# INLINE f #-}

 

g :: Hashable a => ...
g = ...

{-# INLINABLE g #-}

 

INLINE makes the call site specialization that INLINABLE otherwise gives fail.

 

I for one miss the old INLINE.

 

On Tue, Sep 17, 2013 at 10:27 AM, Dan Burton <danburton.email <at> gmail.com> wrote:

I again want to emphasize how we can view INLINE annotations much the same way as type annotations. It is considered good practice to annotate top-level definitions with type signatures. Why? Is it because the compiler can't figure it out? Is it because the programmer doesn't trust the compiler to figure it out? No, it's because it is a visible, enforced sanity check to make sure that the programmer and the compiler are on the same page, regardless of any magic the compiler is capable of. (I like the various ideas that are being thrown around about "asserting" that something will be inlined.)

 

I see superfluous INLINE pragmas as for the benefit of humans, allowing them to express their desires explicitly, rather than relying on implicit behavior that is hard for the average muggle to understand, verify, or guarantee. If someone reads through the source, and wonders whether "bool" will be inlined, they don't need to know any details about the current state of the inliner algorithm when they can just see the pragma right there in the source.

 

The inliner should be at the whim of its masters, the humans, not the other way around.

 


-- Dan Burton

 

On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:

Austin,

First of all, let me say that I am generally on the same side of this
argument as you are now.

But Dan raised very good and valid points, and I don't think you
addressed them directly (quotations follow):

1. If you want to test the auto-inliner's wisdom, then just add a

   setting that ignores INLINE pragmas and see if it inlines the same
   thing that humans do?

2. I don't really care how it's accomplished, but I do think that we should

   make sure that maybe, either, and bool are inlined, and the most obvious
   way to accomplish this is to directly mark them INLINE, is it not?

Roman

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

 


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

 

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 17 Sep 19:49 2013
Picon

Re: add INLINEABLE to maybe, either, bool

On Tue, Sep 17, 2013 at 10:45 AM, Simon Peyton-Jones
<simonpj <at> microsoft.com> wrote:
> I don’t understand your difficulty below at all.  After all, at every call site of ‘f’ we will inline
it, as the INLINE pragma stipulates; and then we’ll generate specialised code for g, exactly as (I
suppose) you hope.

We don't! This is an actual bug I had in unordered-containers and it's
fixes by changing the INLINE to INLINABLE on f above. I think the
problem is that once we're done inlining, the specilize phase has
already passed (i.e. specialize happens before the simplifier). If you
remember we once discussed trying to add a second, late specialize
phase to cover this very case.

> What other behaviour did you seek?

At the call site of f (where f gets inlined) should get the Hashable
dict specialized if the concrete type of 'a' is known.

>
>
>
> Simon
>
>
>
> From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of Johan Tibell
> Sent: 17 September 2013 18:41
> To: Dan Burton
> Cc: Haskell Libraries
> Subject: Re: add INLINEABLE to maybe, either, bool
>
>
>
> Aside: INLINE pragmas do more than INLINE nowadays, they prevent the RHS (to be inlined) from being
optimized before inlining happens. This makes it interfere badly with INLINABLE. For example, if you have:
>
>
>
> f = g
>
> {-# INLINE f #-}
>
>
>
> g :: Hashable a => ...
> g = ...
>
> {-# INLINABLE g #-}
>
>
>
> INLINE makes the call site specialization that INLINABLE otherwise gives fail.
>
>
>
> I for one miss the old INLINE.
>
>
>
> On Tue, Sep 17, 2013 at 10:27 AM, Dan Burton <danburton.email <at> gmail.com> wrote:
>
> I again want to emphasize how we can view INLINE annotations much the same way as type annotations. It is
considered good practice to annotate top-level definitions with type signatures. Why? Is it because the
compiler can't figure it out? Is it because the programmer doesn't trust the compiler to figure it out? No,
it's because it is a visible, enforced sanity check to make sure that the programmer and the compiler are on
the same page, regardless of any magic the compiler is capable of. (I like the various ideas that are being
thrown around about "asserting" that something will be inlined.)
>
>
>
> I see superfluous INLINE pragmas as for the benefit of humans, allowing them to express their desires
explicitly, rather than relying on implicit behavior that is hard for the average muggle to understand,
verify, or guarantee. If someone reads through the source, and wonders whether "bool" will be inlined,
they don't need to know any details about the current state of the inliner algorithm when they can just see
the pragma right there in the source.
>
>
>
> The inliner should be at the whim of its masters, the humans, not the other way around.
>
>
>
>
> -- Dan Burton
>
>
>
> On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
>
> Austin,
>
> First of all, let me say that I am generally on the same side of this
> argument as you are now.
>
> But Dan raised very good and valid points, and I don't think you
> addressed them directly (quotations follow):
>
> 1. If you want to test the auto-inliner's wisdom, then just add a
>
>    setting that ignores INLINE pragmas and see if it inlines the same
>    thing that humans do?
>
> 2. I don't really care how it's accomplished, but I do think that we should
>
>    make sure that maybe, either, and bool are inlined, and the most obvious
>    way to accomplish this is to directly mark them INLINE, is it not?
>
> Roman
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
Simon Peyton-Jones | 17 Sep 19:56 2013
Picon

RE: add INLINEABLE to maybe, either, bool

Ah I see, thanks!  That's a bug.  Would you like to make a ticket for it?  Or is there one already?

Simon

|  -----Original Message-----
|  From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of Johan Tibell
|  Sent: 17 September 2013 18:50
|  To: Simon Peyton-Jones
|  Cc: Haskell Libraries
|  Subject: Re: add INLINEABLE to maybe, either, bool
|  
|  On Tue, Sep 17, 2013 at 10:45 AM, Simon Peyton-Jones
|  <simonpj <at> microsoft.com> wrote:
|  > I don't understand your difficulty below at all.  After all, at every call site of 'f'
|  we will inline it, as the INLINE pragma stipulates; and then we'll generate
|  specialised code for g, exactly as (I suppose) you hope.
|  
|  We don't! This is an actual bug I had in unordered-containers and it's
|  fixes by changing the INLINE to INLINABLE on f above. I think the
|  problem is that once we're done inlining, the specilize phase has
|  already passed (i.e. specialize happens before the simplifier). If you
|  remember we once discussed trying to add a second, late specialize
|  phase to cover this very case.
|  
|  > What other behaviour did you seek?
|  
|  At the call site of f (where f gets inlined) should get the Hashable
|  dict specialized if the concrete type of 'a' is known.
|  
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of Johan Tibell
|  > Sent: 17 September 2013 18:41
|  > To: Dan Burton
|  > Cc: Haskell Libraries
|  > Subject: Re: add INLINEABLE to maybe, either, bool
|  >
|  >
|  >
|  > Aside: INLINE pragmas do more than INLINE nowadays, they prevent the RHS
|  (to be inlined) from being optimized before inlining happens. This makes it
|  interfere badly with INLINABLE. For example, if you have:
|  >
|  >
|  >
|  > f = g
|  >
|  > {-# INLINE f #-}
|  >
|  >
|  >
|  > g :: Hashable a => ...
|  > g = ...
|  >
|  > {-# INLINABLE g #-}
|  >
|  >
|  >
|  > INLINE makes the call site specialization that INLINABLE otherwise gives fail.
|  >
|  >
|  >
|  > I for one miss the old INLINE.
|  >
|  >
|  >
|  > On Tue, Sep 17, 2013 at 10:27 AM, Dan Burton <danburton.email <at> gmail.com>
|  wrote:
|  >
|  > I again want to emphasize how we can view INLINE annotations much the same
|  way as type annotations. It is considered good practice to annotate top-level
|  definitions with type signatures. Why? Is it because the compiler can't figure it
|  out? Is it because the programmer doesn't trust the compiler to figure it out? No,
|  it's because it is a visible, enforced sanity check to make sure that the
|  programmer and the compiler are on the same page, regardless of any magic the
|  compiler is capable of. (I like the various ideas that are being thrown around about
|  "asserting" that something will be inlined.)
|  >
|  >
|  >
|  > I see superfluous INLINE pragmas as for the benefit of humans, allowing them
|  to express their desires explicitly, rather than relying on implicit behavior that is
|  hard for the average muggle to understand, verify, or guarantee. If someone reads
|  through the source, and wonders whether "bool" will be inlined, they don't need to
|  know any details about the current state of the inliner algorithm when they can
|  just see the pragma right there in the source.
|  >
|  >
|  >
|  > The inliner should be at the whim of its masters, the humans, not the other way
|  around.
|  >
|  >
|  >
|  >
|  > -- Dan Burton
|  >
|  >
|  >
|  > On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma <at> ro-che.info>
|  wrote:
|  >
|  > Austin,
|  >
|  > First of all, let me say that I am generally on the same side of this
|  > argument as you are now.
|  >
|  > But Dan raised very good and valid points, and I don't think you
|  > addressed them directly (quotations follow):
|  >
|  > 1. If you want to test the auto-inliner's wisdom, then just add a
|  >
|  >    setting that ignores INLINE pragmas and see if it inlines the same
|  >    thing that humans do?
|  >
|  > 2. I don't really care how it's accomplished, but I do think that we should
|  >
|  >    make sure that maybe, either, and bool are inlined, and the most obvious
|  >    way to accomplish this is to directly mark them INLINE, is it not?
|  >
|  > Roman
|  >
|  > _______________________________________________
|  > Libraries mailing list
|  > Libraries <at> haskell.org
|  > http://www.haskell.org/mailman/listinfo/libraries
|  >
|  >
|  >
|  >
|  > _______________________________________________
|  > Libraries mailing list
|  > Libraries <at> haskell.org
|  > http://www.haskell.org/mailman/listinfo/libraries
|  >
|  >
|  _______________________________________________
|  Libraries mailing list
|  Libraries <at> haskell.org
|  http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 17 Sep 20:05 2013
Picon

Re: add INLINEABLE to maybe, either, bool

http://ghc.haskell.org/trac/ghc/ticket/5928

On Tue, Sep 17, 2013 at 10:56 AM, Simon Peyton-Jones
<simonpj <at> microsoft.com> wrote:
> Ah I see, thanks!  That's a bug.  Would you like to make a ticket for it?  Or is there one already?
>
> Simon
>
> |  -----Original Message-----
> |  From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of Johan Tibell
> |  Sent: 17 September 2013 18:50
> |  To: Simon Peyton-Jones
> |  Cc: Haskell Libraries
> |  Subject: Re: add INLINEABLE to maybe, either, bool
> |
> |  On Tue, Sep 17, 2013 at 10:45 AM, Simon Peyton-Jones
> |  <simonpj <at> microsoft.com> wrote:
> |  > I don't understand your difficulty below at all.  After all, at every call site of 'f'
> |  we will inline it, as the INLINE pragma stipulates; and then we'll generate
> |  specialised code for g, exactly as (I suppose) you hope.
> |
> |  We don't! This is an actual bug I had in unordered-containers and it's
> |  fixes by changing the INLINE to INLINABLE on f above. I think the
> |  problem is that once we're done inlining, the specilize phase has
> |  already passed (i.e. specialize happens before the simplifier). If you
> |  remember we once discussed trying to add a second, late specialize
> |  phase to cover this very case.
> |
> |  > What other behaviour did you seek?
> |
> |  At the call site of f (where f gets inlined) should get the Hashable
> |  dict specialized if the concrete type of 'a' is known.
> |
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of Johan Tibell
> |  > Sent: 17 September 2013 18:41
> |  > To: Dan Burton
> |  > Cc: Haskell Libraries
> |  > Subject: Re: add INLINEABLE to maybe, either, bool
> |  >
> |  >
> |  >
> |  > Aside: INLINE pragmas do more than INLINE nowadays, they prevent the RHS
> |  (to be inlined) from being optimized before inlining happens. This makes it
> |  interfere badly with INLINABLE. For example, if you have:
> |  >
> |  >
> |  >
> |  > f = g
> |  >
> |  > {-# INLINE f #-}
> |  >
> |  >
> |  >
> |  > g :: Hashable a => ...
> |  > g = ...
> |  >
> |  > {-# INLINABLE g #-}
> |  >
> |  >
> |  >
> |  > INLINE makes the call site specialization that INLINABLE otherwise gives fail.
> |  >
> |  >
> |  >
> |  > I for one miss the old INLINE.
> |  >
> |  >
> |  >
> |  > On Tue, Sep 17, 2013 at 10:27 AM, Dan Burton <danburton.email <at> gmail.com>
> |  wrote:
> |  >
> |  > I again want to emphasize how we can view INLINE annotations much the same
> |  way as type annotations. It is considered good practice to annotate top-level
> |  definitions with type signatures. Why? Is it because the compiler can't figure it
> |  out? Is it because the programmer doesn't trust the compiler to figure it out? No,
> |  it's because it is a visible, enforced sanity check to make sure that the
> |  programmer and the compiler are on the same page, regardless of any magic the
> |  compiler is capable of. (I like the various ideas that are being thrown around about
> |  "asserting" that something will be inlined.)
> |  >
> |  >
> |  >
> |  > I see superfluous INLINE pragmas as for the benefit of humans, allowing them
> |  to express their desires explicitly, rather than relying on implicit behavior that is
> |  hard for the average muggle to understand, verify, or guarantee. If someone reads
> |  through the source, and wonders whether "bool" will be inlined, they don't need to
> |  know any details about the current state of the inliner algorithm when they can
> |  just see the pragma right there in the source.
> |  >
> |  >
> |  >
> |  > The inliner should be at the whim of its masters, the humans, not the other way
> |  around.
> |  >
> |  >
> |  >
> |  >
> |  > -- Dan Burton
> |  >
> |  >
> |  >
> |  > On Tue, Sep 17, 2013 at 6:11 AM, Roman Cheplyaka <roma <at> ro-che.info>
> |  wrote:
> |  >
> |  > Austin,
> |  >
> |  > First of all, let me say that I am generally on the same side of this
> |  > argument as you are now.
> |  >
> |  > But Dan raised very good and valid points, and I don't think you
> |  > addressed them directly (quotations follow):
> |  >
> |  > 1. If you want to test the auto-inliner's wisdom, then just add a
> |  >
> |  >    setting that ignores INLINE pragmas and see if it inlines the same
> |  >    thing that humans do?
> |  >
> |  > 2. I don't really care how it's accomplished, but I do think that we should
> |  >
> |  >    make sure that maybe, either, and bool are inlined, and the most obvious
> |  >    way to accomplish this is to directly mark them INLINE, is it not?
> |  >
> |  > Roman
> |  >
> |  > _______________________________________________
> |  > Libraries mailing list
> |  > Libraries <at> haskell.org
> |  > http://www.haskell.org/mailman/listinfo/libraries
> |  >
> |  >
> |  >
> |  >
> |  > _______________________________________________
> |  > Libraries mailing list
> |  > Libraries <at> haskell.org
> |  > http://www.haskell.org/mailman/listinfo/libraries
> |  >
> |  >
> |  _______________________________________________
> |  Libraries mailing list
> |  Libraries <at> haskell.org
> |  http://www.haskell.org/mailman/listinfo/libraries
Dan Doel | 17 Sep 20:24 2013
Picon

Re: add INLINEABLE to maybe, either, bool

On Tue, Sep 17, 2013 at 1:27 PM, Dan Burton <danburton.email <at> gmail.com> wrote:
I again want to emphasize how we can view INLINE annotations much the same way as type annotations. It is considered good practice to annotate top-level definitions with type signatures. Why? Is it because the compiler can't figure it out? Is it because the programmer doesn't trust the compiler to figure it out? No, it's because it is a visible, enforced sanity check to make sure that the programmer and the compiler are on the same page, regardless of any magic the compiler is capable of. (I like the various ideas that are being thrown around about "asserting" that something will be inlined.)

The purpose of top-level signatures is that checking against them will sometimes flag errors in the written code, and to give readers more information about what the code does (similar to documentation). Neither of these is accomplished by INLINE pragmas. The latter would be more like type annotations overriding what the compiler infers, even if they don't unify.
 
I see superfluous INLINE pragmas as for the benefit of humans, allowing them to express their desires explicitly, rather than relying on implicit behavior that is hard for the average muggle to understand, verify, or guarantee. If someone reads through the source, and wonders whether "bool" will be inlined, they don't need to know any details about the current state of the inliner algorithm when they can just see the pragma right there in the source.

Frankly, no one should have to worry about whether bool should be inlined. It should just be fast. It's pretty abysmal* in general that so many high-performance libraries need** INLINE all over the place like they do. I'm the author of one (vector-algorithms), and I don't like it. I don't know how to fix GHC for my case (which, by the way, is very different from bool), but I one day hope to remove all the INLINEs from it. They are a terrible way of achieving what they accomplish, but it's order(s) of magnitude in performance.

Many detractors of types like to say that their purpose is just to aid the compiler in optimization. That's wrong, but INLINE pragmas and the like are exactly that, and if they are often on people's minds, it's because the compiler is not yet smart enough. I don't think this is a state of affairs we should accept or encourage by putting redundant pragmas on everything. It's exactly the kind of micro-optimization that I don't want to have to think about in a language like Haskell. But unfortunately, GHC probably requires more worrying about this (for performance use cases) than modern C compilers.

Constantly giving hints to the compiler about basic inlining for acceptable performance is not being "the master." It is being the assistant.

-- Dan

[*] No offense to the GHC devs. They do a great job, and I personally don't know how to do this better.

[**] This is assuming that many of the libraries actually need the pragmas. I expect a lot of the INLINEs in lens are the result of Ed just mechanically putting them on everything. And many INLINEs you see in base (mentioned earlier) may well be from code that was written during poorer inlining heuristics, but hasn't been revised with that regard.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Edward Kmett | 17 Sep 20:50 2013
Picon

Re: add INLINEABLE to maybe, either, bool

Lens does go a bit overboard with INLINE, but the performance when we didn't wasn't good.

We need both 'what to do' and 'what to do it to' to inline to the extent possible to get the same core you get from direct implementation and my recollection from the last time I fiddled with it was that GHC likes to avoid inlining class members too much to get the right performance characteristics.

Now, we could remove many of the INLINE pragmas from the `fooOf` variants and replace them with INLINEABLE. However, then we'd have to deal with 5928. Many of them have non-trivial bodies though, so without an explicit INLINEABLE, they'd probably be too big to get thrown in the .hi file by default.

Right now the inliner can just go nuts and make the lens code vanish when everything is concretely known. 

You can view the splitting of 'what to do' and 'what to do it to' provided by lens as very similar to the way stream fusion gets decent optimization by factoring out the recursion, so that GHC can't accidentally pick a bad loop breaker. 

In that setting inlining all the remaining non-recursive bits makes a lot of sense.

-Edward


On Tue, Sep 17, 2013 at 2:24 PM, Dan Doel <dan.doel <at> gmail.com> wrote:
On Tue, Sep 17, 2013 at 1:27 PM, Dan Burton <danburton.email <at> gmail.com> wrote:
I again want to emphasize how we can view INLINE annotations much the same way as type annotations. It is considered good practice to annotate top-level definitions with type signatures. Why? Is it because the compiler can't figure it out? Is it because the programmer doesn't trust the compiler to figure it out? No, it's because it is a visible, enforced sanity check to make sure that the programmer and the compiler are on the same page, regardless of any magic the compiler is capable of. (I like the various ideas that are being thrown around about "asserting" that something will be inlined.)

The purpose of top-level signatures is that checking against them will sometimes flag errors in the written code, and to give readers more information about what the code does (similar to documentation). Neither of these is accomplished by INLINE pragmas. The latter would be more like type annotations overriding what the compiler infers, even if they don't unify.
 
I see superfluous INLINE pragmas as for the benefit of humans, allowing them to express their desires explicitly, rather than relying on implicit behavior that is hard for the average muggle to understand, verify, or guarantee. If someone reads through the source, and wonders whether "bool" will be inlined, they don't need to know any details about the current state of the inliner algorithm when they can just see the pragma right there in the source.

Frankly, no one should have to worry about whether bool should be inlined. It should just be fast. It's pretty abysmal* in general that so many high-performance libraries need** INLINE all over the place like they do. I'm the author of one (vector-algorithms), and I don't like it. I don't know how to fix GHC for my case (which, by the way, is very different from bool), but I one day hope to remove all the INLINEs from it. They are a terrible way of achieving what they accomplish, but it's order(s) of magnitude in performance.

Many detractors of types like to say that their purpose is just to aid the compiler in optimization. That's wrong, but INLINE pragmas and the like are exactly that, and if they are often on people's minds, it's because the compiler is not yet smart enough. I don't think this is a state of affairs we should accept or encourage by putting redundant pragmas on everything. It's exactly the kind of micro-optimization that I don't want to have to think about in a language like Haskell. But unfortunately, GHC probably requires more worrying about this (for performance use cases) than modern C compilers.

Constantly giving hints to the compiler about basic inlining for acceptable performance is not being "the master." It is being the assistant.

-- Dan

[*] No offense to the GHC devs. They do a great job, and I personally don't know how to do this better.

[**] This is assuming that many of the libraries actually need the pragmas. I expect a lot of the INLINEs in lens are the result of Ed just mechanically putting them on everything. And many INLINEs you see in base (mentioned earlier) may well be from code that was written during poorer inlining heuristics, but hasn't been revised with that regard.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ian Lynagh | 17 Sep 20:34 2013
Picon

Re: add INLINEABLE to maybe, either, bool

On Tue, Sep 17, 2013 at 10:27:23AM -0700, Dan Burton wrote:
> I again want to emphasize how we can view INLINE annotations much the same
> way as type annotations. It is considered good practice to annotate
> top-level definitions with type signatures. Why?

1. Having type sigs means that you get better type errors.

2. Having type sigs makes it easier for developers to work out what a
   function does and how to use it.

3. Having type signatures means that you get an error if the compiler
   doesn't agree with you.

None of these apply to INLINE pragmas.

To get something similar you'd need an INLINED pragma, where
    {-# INLINED f #-}
    f = ...
would be a compilation error if the compiler didn't decide that f should
get an unfolding. (I'm not seriously proposing this pragma).

> No, it's because it is a visible, enforced
> sanity check to make sure that the programmer and the compiler are on the
> same page,

INLINED would be a sanity check. INLINE is an instruction.

> If someone reads through the source, and wonders whether "bool"
> will be inlined

The purpose of writing an optimising compiler is so that we can, for the
most part, leave it alone to optimise our programs.

Thanks
Ian
Simon Peyton-Jones | 18 Sep 13:10 2013
Picon

RE: add INLINEABLE to maybe, either, bool

Just to add: the more concrete, reproducible examples we have that demonstrate

- a substantial perf improvement
- from an inlining that GHC didn't do automatically

the easier it is to see a general pattern that we might exploit to improve GHC's automatic behaviour.

Simon

| -----Original Message-----
| From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of
| Austin Seipp
| Sent: 17 September 2013 00:04
| To: Austin Seipp
| Cc: Haskell Libraries
| Subject: Re: add INLINEABLE to maybe, either, bool
| 
| In light of some recent conversations with others and self-review, I
| realize my prior messages may have been too strong, come off as
| hostile, or outright combative.
| 
| I'd like to publicly apologize for that: I'm sorry to ruffle feathers.
| (As a GHC developer, what seems 'obvious' to me is much different than
| most people, I realize.)
| 
| Now, in light of some discussions I had on IRC, there *are* things we
| can do here, and I'd like to lightly recap my position and some other
| points. To wit:
| 
|  * I think it is bad to overuse things like INLINE, and I believe it
| encourages people to not understand the implications of what the
| compiler is doing (all programmers generally must have some intuition
| and control over their programs, and how they run.)
| 
|  * Using the INLINE hammer everywhere makes it *incredibly* difficult
| to see where GHC deficiencies are, and that's not what we want - it
| hurts our ability to have informed decisions and examples. I also find
| it slightly disheartening that many people don't think GHC can handle
| cases like this.
| 
|  * But Haskell is a language where inlining may not make a
| constant-factor difference, but *orders of magnitude difference*.
| vector-algorithms is a good example of this, and I'm not sure anyone
| knows how to 'fix it' so it doesn't have to INLINE literally
| everything. We're talking 10 orders of magnitude difference, if I
| remember my conversations with Dan/Edward correctly. lens is a lesser
| example: there are cases where GHC won't inline due to fear of work
| duplication or other unusual cases, but we can tackle these in GHC in
| some cases (and have.)
| 
|  * We tend to be quite sensitive to performance matters as a community,
| I feel.
| 
|  * And sometimes, things are hard. Even for people like Simon,
| 'fixing' bad inliner behavior can be a monstrous task, and INLINE is
| certainly a way to help the compiler when its hands are tied.
| 
| Ultimately, nobody is wrong here. But we have options, and two of them
| people brought up are good ones I think.
| 
|  1.) Perhaps GHC should have a flag to warn you if you use
| INLINE/INLINEABLE on a definition that the inliner would have dealt
| with anyway. This should not be on by default with -Wall. But it would
| give us a useful tool to examine our assumptions more easily in a lot
| of cases.
| 
|  2.) GHC does have a testsuite with many performance-related tests,
| and tests that check the Core. We could easily add a test that checked
| the core output of bool, maybe, and either (and other functions, as
| time may go on.) This is much easier and probably more robust than
| trying to contrive an example of what the performance difference might
| be.
| 
| Personally, I am way more interested in #1, as opposed to #2 (a
| failure to inline something so small would quickly be noticed -
| because lots of things probably won't inline at that point and our
| tests will fail!) However, I believe both of these are relatively
| easy, and quite feasible to implement.
| 
| Unfortunately, I have about 10,000,000 things on my plate with the
| upcoming release. So I'm afraid I don't have time to do these myself.
| 
| So, patches welcome! However, I am more than willing to help people
| get their feet wet in doing the work. You can email me (same email I'm
| using now,) or contact me on IRC (freenode, nick 'thoughtpolice') if
| you prefer more real time communication. I'll help you to the best of
| my abilities if you'd like to give it a go.
| 
| 
| On Mon, Sep 16, 2013 at 4:56 PM, Austin Seipp <austin <at> well-typed.com>
| wrote:
| > A serious question: if you don't even trust GHC to inline 'bool',
| > 'maybe' or 'either', given their triviality, do you trust it to ever
| > inline anything at all? I'm being completely honest here.
| >
| > It still ignores the question of *why* the inliner is failing to do
| > what you want. If the type inferencer fails to infer the type of an
| > utterly trivial function - let's again say 'bool :: a -> a -> Bool ->
| > a', as it's type is about as trivial as it's definition - it is almost
| > certainly broken. By the same token, GHC not inlining 'bool' under -O
| > would almost certainly be a bug too, in my eyes. The definition is
| > trivial to the point where we should not ask "what if it doesn't
| > inline" - we should figure out WHY it does not do so. Maybe INLINE
| > would be a justified way of fixing it, but in this case it's just
| > unnecessary and has been verified as such.
| >
| > By the same token, we also don't encourage people to wildly put `seq`
| > everywhere, or make everything on earth strict just because it makes
| > them feel good.
| >
| > A compiler must work on a broad range of programs for a broad range of
| > use cases. There are certainly some cases that the compiler is *not*
| > tuned for. In some of these cases, we work to make them more
| > efficient. We patch the compiler to make it better where-ever
| > possible. But this case? This is nothing but a premature optimization
| > in my eyes - and one that even people like Edward or myself are guilty
| > of, for sure.* And I am repenting by rejecting the "INLINE school of
| > thought" (or INLINE school of hammers, as it were.)
| >
| > If you want to make the argument that 'bool' - or something else even
| > - should be INLINE, by all means do so. But if you're going to do so
| > without any empirical cases, or examples of why it should be so
| > (especially when we have already checked the interface files,) and
| > just say it lets you sleep better at night? I simply do not buy it.
| >
| >
| > On Mon, Sep 16, 2013 at 3:59 PM, Dan Burton
| <danburton.email <at> gmail.com> wrote:
| >> I'm wary of "let's not mark it as INLINE because we want the compiler
| to
| >> automagically inline it for us." This seems like saying we should not
| have
| >> type signatures, because we want the type inferencer to figure it out
| for
| >> us. (If you want to test the auto-inliner's wisdom, then just add a
| setting
| >> that ignores INLINE pragmas and see if it inlines the same thing that
| humans
| >> do?)
| >>
| >> I don't really care how it's accomplished, but I do think that we
| should
| >> make sure that maybe, either, and bool are inlined, and the most
| obvious way
| >> to accomplish this is to directly mark them INLINE, is it not?
| >>
| >> -- Dan Burton
| >>
| >>
| >> On Mon, Sep 16, 2013 at 1:33 PM, Edward Kmett <ekmett <at> gmail.com>
| wrote:
| >>>
| >>> Contrary to appearances, I fully agree. =)
| >>>
| >>>
| >>> On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin <at> well-
| typed.com>
| >>> wrote:
| >>>>
| >>>> I'm strongly opposed to this.
| >>>>
| >>>> Being INLINE happy is not a good thing, it is a bad thing. More
| often
| >>>> than not, I see people stuffing INLINE all over the place for
| things
| >>>> that would trivially be unfolded and put in the interface file
| anyway.
| >>>> This is bad, and it teaches people to just use the INLINE hammer
| >>>> everywhere instead of understanding the actual implications of what
| >>>> the inliner does. It also makes it impossible to actually observe
| how
| >>>> the inliner behaves and see where it needs tuning: if we just mark
| >>>> everything INLINE, we might as well not have it and make it
| >>>> unconditional.
| >>>>
| >>>> There are some particular cases where GHC is hesitant to inline
| small
| >>>> things if it would lead to work duplication, or where the inliner
| >>>> behavior is tweaked and you may want to force it across multiple
| >>>> versions to be sure (lens is a good example of this.) But this is
| far
| >>>> more rare, and this case is not that. In particular, Joachim
| checked
| >>>> the 'bool' commit. As expected, the unfolding for bool was put into
| >>>> the interface file for Data.Bool, meaning if you use -O (or just -
| O0
| >>>> -fno-ignore-interface-pragmas,) it should be inlined at call sites
| >>>> appropriately when it is used.
| >>>>
| >>>> If we're going to INLINE things, we need to make sure it actually
| has
| >>>> an empirical benefit, by looking at the core, and seeing where the
| >>>> inliner is failing. Not just attach it to things because it seems
| like
| >>>> a good idea. This also helps drive feedback into the inliner so we
| can
| >>>> see where it fails.
| >>>>
| >>>> On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
| >>>> <carter.schonwald <at> gmail.com> wrote:
| >>>> > Its come to my attention that maybe, either, and its new sibling
| bool,
| >>>> > all
| >>>> > lack the
| >>>> > INLINEABLE attribute, or its more aggressive sibling INLINE
| >>>> >
| >>>> > this seems like one of those operations where inlining in client
| use
| >>>> > sites
| >>>> > is a good option to have, and currently not possible!
| >>>> >
| >>>> > theres probably other stuff that would benefit from an INLINEABLE
| >>>> > pragma in
| >>>> > base,
| >>>> > but this is an obvious, simple, "easy win" that I noticed when
| Oliver's
| >>>> > patch got merged into base.
| >>>> >
| >>>> > Thoughts?
| >>>> > Time scale: sometime this week? (ghc 7.8 merge window is
| landing!)
| >>>> >
| >>>> > cheers
| >>>> >
| >>>> > _______________________________________________
| >>>> > Libraries mailing list
| >>>> > Libraries <at> haskell.org
| >>>> > http://www.haskell.org/mailman/listinfo/libraries
| >>>> >
| >>>>
| >>>>
| >>>>
| >>>> --
| >>>> Austin Seipp, Haskell Consultant
| >>>> Well-Typed LLP, http://www.well-typed.com/
| >>>> _______________________________________________
| >>>> Libraries mailing list
| >>>> Libraries <at> haskell.org
| >>>> http://www.haskell.org/mailman/listinfo/libraries
| >>>
| >>>
| >>>
| >>> _______________________________________________
| >>> Libraries mailing list
| >>> Libraries <at> haskell.org
| >>> http://www.haskell.org/mailman/listinfo/libraries
| >>>
| >>
| >
| >
| >
| > --
| > Austin Seipp, Haskell Consultant
| > Well-Typed LLP, http://www.well-typed.com/
| 
| 
| 
| --
| Austin Seipp, Haskell Consultant
| Well-Typed LLP, http://www.well-typed.com/
| _______________________________________________
| Libraries mailing list
| Libraries <at> haskell.org
| http://www.haskell.org/mailman/listinfo/libraries
Simon Marlow | 26 Sep 17:45 2013
Picon

Re: add INLINEABLE to maybe, either, bool

I read this discussion and thought that one small thing we could do is 
to clarify the documentation for INLINE a bit.  Here's what I came up 
with; comments welcome.  I'll commit this if there are no objections.

         <para>
           GHC (with <option>-O</option>, as always) tries to inline
           (or &ldquo;unfold&rdquo;) functions/values that are
           &ldquo;small enough,&rdquo; thus avoiding the call overhead
           and possibly exposing other more-wonderful optimisations.
           GHC has a set of heuristics, tuned over a long period of
           time using many benchmarks, that decide when it is
           beneficial to inline a function at its call site.  The
           heuristics are designed to inline functions when it appears
           to be beneficial to do so, but without incurring excessive
           code bloat.  If a function looks too big, it won't be
           inlined, and functions larger than a certain size will not
           even have their definition exported in the interface file.
           Some of the thresholds that govern these heuristic decisions
           can be changed using flags, see <xref linkend="options-f"
           />.
         </para>

         <para>
           Normally GHC will do a reasonable job of deciding by itself
           when it is a good idea to inline a function.  However,
           sometimes you might want to override the default behaviour.
           For exmaple, if you have a key function that is important to
           inline because it leads to further optimisations, but GHC
           judges it to be too big to inline.
         </para>

Cheers,
Simon

On 16/09/2013 19:03, Austin Seipp wrote:
> In light of some recent conversations with others and self-review, I
> realize my prior messages may have been too strong, come off as
> hostile, or outright combative.
>
> I'd like to publicly apologize for that: I'm sorry to ruffle feathers.
> (As a GHC developer, what seems 'obvious' to me is much different than
> most people, I realize.)
>
> Now, in light of some discussions I had on IRC, there *are* things we
> can do here, and I'd like to lightly recap my position and some other
> points. To wit:
>
>   * I think it is bad to overuse things like INLINE, and I believe it
> encourages people to not understand the implications of what the
> compiler is doing (all programmers generally must have some intuition
> and control over their programs, and how they run.)
>
>   * Using the INLINE hammer everywhere makes it *incredibly* difficult
> to see where GHC deficiencies are, and that's not what we want - it
> hurts our ability to have informed decisions and examples. I also find
> it slightly disheartening that many people don't think GHC can handle
> cases like this.
>
>   * But Haskell is a language where inlining may not make a
> constant-factor difference, but *orders of magnitude difference*.
> vector-algorithms is a good example of this, and I'm not sure anyone
> knows how to 'fix it' so it doesn't have to INLINE literally
> everything. We're talking 10 orders of magnitude difference, if I
> remember my conversations with Dan/Edward correctly. lens is a lesser
> example: there are cases where GHC won't inline due to fear of work
> duplication or other unusual cases, but we can tackle these in GHC in
> some cases (and have.)
>
>   * We tend to be quite sensitive to performance matters as a community, I feel.
>
>   * And sometimes, things are hard. Even for people like Simon,
> 'fixing' bad inliner behavior can be a monstrous task, and INLINE is
> certainly a way to help the compiler when its hands are tied.
>
> Ultimately, nobody is wrong here. But we have options, and two of them
> people brought up are good ones I think.
>
>   1.) Perhaps GHC should have a flag to warn you if you use
> INLINE/INLINEABLE on a definition that the inliner would have dealt
> with anyway. This should not be on by default with -Wall. But it would
> give us a useful tool to examine our assumptions more easily in a lot
> of cases.
>
>   2.) GHC does have a testsuite with many performance-related tests,
> and tests that check the Core. We could easily add a test that checked
> the core output of bool, maybe, and either (and other functions, as
> time may go on.) This is much easier and probably more robust than
> trying to contrive an example of what the performance difference might
> be.
>
> Personally, I am way more interested in #1, as opposed to #2 (a
> failure to inline something so small would quickly be noticed -
> because lots of things probably won't inline at that point and our
> tests will fail!) However, I believe both of these are relatively
> easy, and quite feasible to implement.
>
> Unfortunately, I have about 10,000,000 things on my plate with the
> upcoming release. So I'm afraid I don't have time to do these myself.
>
> So, patches welcome! However, I am more than willing to help people
> get their feet wet in doing the work. You can email me (same email I'm
> using now,) or contact me on IRC (freenode, nick 'thoughtpolice') if
> you prefer more real time communication. I'll help you to the best of
> my abilities if you'd like to give it a go.
>
>
> On Mon, Sep 16, 2013 at 4:56 PM, Austin Seipp <austin <at> well-typed.com> wrote:
>> A serious question: if you don't even trust GHC to inline 'bool',
>> 'maybe' or 'either', given their triviality, do you trust it to ever
>> inline anything at all? I'm being completely honest here.
>>
>> It still ignores the question of *why* the inliner is failing to do
>> what you want. If the type inferencer fails to infer the type of an
>> utterly trivial function - let's again say 'bool :: a -> a -> Bool ->
>> a', as it's type is about as trivial as it's definition - it is almost
>> certainly broken. By the same token, GHC not inlining 'bool' under -O
>> would almost certainly be a bug too, in my eyes. The definition is
>> trivial to the point where we should not ask "what if it doesn't
>> inline" - we should figure out WHY it does not do so. Maybe INLINE
>> would be a justified way of fixing it, but in this case it's just
>> unnecessary and has been verified as such.
>>
>> By the same token, we also don't encourage people to wildly put `seq`
>> everywhere, or make everything on earth strict just because it makes
>> them feel good.
>>
>> A compiler must work on a broad range of programs for a broad range of
>> use cases. There are certainly some cases that the compiler is *not*
>> tuned for. In some of these cases, we work to make them more
>> efficient. We patch the compiler to make it better where-ever
>> possible. But this case? This is nothing but a premature optimization
>> in my eyes - and one that even people like Edward or myself are guilty
>> of, for sure.* And I am repenting by rejecting the "INLINE school of
>> thought" (or INLINE school of hammers, as it were.)
>>
>> If you want to make the argument that 'bool' - or something else even
>> - should be INLINE, by all means do so. But if you're going to do so
>> without any empirical cases, or examples of why it should be so
>> (especially when we have already checked the interface files,) and
>> just say it lets you sleep better at night? I simply do not buy it.
>>
>>
>> On Mon, Sep 16, 2013 at 3:59 PM, Dan Burton <danburton.email <at> gmail.com> wrote:
>>> I'm wary of "let's not mark it as INLINE because we want the compiler to
>>> automagically inline it for us." This seems like saying we should not have
>>> type signatures, because we want the type inferencer to figure it out for
>>> us. (If you want to test the auto-inliner's wisdom, then just add a setting
>>> that ignores INLINE pragmas and see if it inlines the same thing that humans
>>> do?)
>>>
>>> I don't really care how it's accomplished, but I do think that we should
>>> make sure that maybe, either, and bool are inlined, and the most obvious way
>>> to accomplish this is to directly mark them INLINE, is it not?
>>>
>>> -- Dan Burton
>>>
>>>
>>> On Mon, Sep 16, 2013 at 1:33 PM, Edward Kmett <ekmett <at> gmail.com> wrote:
>>>>
>>>> Contrary to appearances, I fully agree. =)
>>>>
>>>>
>>>> On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin <at> well-typed.com>
>>>> wrote:
>>>>>
>>>>> I'm strongly opposed to this.
>>>>>
>>>>> Being INLINE happy is not a good thing, it is a bad thing. More often
>>>>> than not, I see people stuffing INLINE all over the place for things
>>>>> that would trivially be unfolded and put in the interface file anyway.
>>>>> This is bad, and it teaches people to just use the INLINE hammer
>>>>> everywhere instead of understanding the actual implications of what
>>>>> the inliner does. It also makes it impossible to actually observe how
>>>>> the inliner behaves and see where it needs tuning: if we just mark
>>>>> everything INLINE, we might as well not have it and make it
>>>>> unconditional.
>>>>>
>>>>> There are some particular cases where GHC is hesitant to inline small
>>>>> things if it would lead to work duplication, or where the inliner
>>>>> behavior is tweaked and you may want to force it across multiple
>>>>> versions to be sure (lens is a good example of this.) But this is far
>>>>> more rare, and this case is not that. In particular, Joachim checked
>>>>> the 'bool' commit. As expected, the unfolding for bool was put into
>>>>> the interface file for Data.Bool, meaning if you use -O (or just -O0
>>>>> -fno-ignore-interface-pragmas,) it should be inlined at call sites
>>>>> appropriately when it is used.
>>>>>
>>>>> If we're going to INLINE things, we need to make sure it actually has
>>>>> an empirical benefit, by looking at the core, and seeing where the
>>>>> inliner is failing. Not just attach it to things because it seems like
>>>>> a good idea. This also helps drive feedback into the inliner so we can
>>>>> see where it fails.
>>>>>
>>>>> On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
>>>>> <carter.schonwald <at> gmail.com> wrote:
>>>>>> Its come to my attention that maybe, either, and its new sibling bool,
>>>>>> all
>>>>>> lack the
>>>>>> INLINEABLE attribute, or its more aggressive sibling INLINE
>>>>>>
>>>>>> this seems like one of those operations where inlining in client use
>>>>>> sites
>>>>>> is a good option to have, and currently not possible!
>>>>>>
>>>>>> theres probably other stuff that would benefit from an INLINEABLE
>>>>>> pragma in
>>>>>> base,
>>>>>> but this is an obvious, simple, "easy win" that I noticed when Oliver's
>>>>>> patch got merged into base.
>>>>>>
>>>>>> Thoughts?
>>>>>> Time scale: sometime this week? (ghc 7.8 merge window is landing!)
>>>>>>
>>>>>> cheers
>>>>>>
>>>>>> _______________________________________________
>>>>>> Libraries mailing list
>>>>>> Libraries <at> haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Austin Seipp, Haskell Consultant
>>>>> Well-Typed LLP, http://www.well-typed.com/
>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries <at> haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Libraries mailing list
>>>> Libraries <at> haskell.org
>>>> http://www.haskell.org/mailman/listinfo/libraries
>>>>
>>>
>>
>>
>>
>> --
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>
>
>
Simon Peyton-Jones | 26 Sep 17:56 2013
Picon

RE: add INLINEABLE to maybe, either, bool

Looks great to me, thanks.  I imagine you are proposing this as a preamble to 7.18.5.1?
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#inline-noinline-pragma

Simon

| -----Original Message-----
| From: Libraries [mailto:libraries-bounces <at> haskell.org] On Behalf Of
| Simon Marlow
| Sent: 26 September 2013 16:46
| To: Austin Seipp
| Cc: Haskell Libraries
| Subject: Re: add INLINEABLE to maybe, either, bool
| 
| I read this discussion and thought that one small thing we could do is
| to clarify the documentation for INLINE a bit.  Here's what I came up
| with; comments welcome.  I'll commit this if there are no objections.
| 
|          <para>
|            GHC (with <option>-O</option>, as always) tries to inline
|            (or &ldquo;unfold&rdquo;) functions/values that are
|            &ldquo;small enough,&rdquo; thus avoiding the call overhead
|            and possibly exposing other more-wonderful optimisations.
|            GHC has a set of heuristics, tuned over a long period of
|            time using many benchmarks, that decide when it is
|            beneficial to inline a function at its call site.  The
|            heuristics are designed to inline functions when it appears
|            to be beneficial to do so, but without incurring excessive
|            code bloat.  If a function looks too big, it won't be
|            inlined, and functions larger than a certain size will not
|            even have their definition exported in the interface file.
|            Some of the thresholds that govern these heuristic decisions
|            can be changed using flags, see <xref linkend="options-f"
|            />.
|          </para>
| 
|          <para>
|            Normally GHC will do a reasonable job of deciding by itself
|            when it is a good idea to inline a function.  However,
|            sometimes you might want to override the default behaviour.
|            For exmaple, if you have a key function that is important to
|            inline because it leads to further optimisations, but GHC
|            judges it to be too big to inline.
|          </para>
| 
| Cheers,
| Simon
| 
| 
| 
| On 16/09/2013 19:03, Austin Seipp wrote:
| > In light of some recent conversations with others and self-review, I
| > realize my prior messages may have been too strong, come off as
| > hostile, or outright combative.
| >
| > I'd like to publicly apologize for that: I'm sorry to ruffle feathers.
| > (As a GHC developer, what seems 'obvious' to me is much different than
| > most people, I realize.)
| >
| > Now, in light of some discussions I had on IRC, there *are* things we
| > can do here, and I'd like to lightly recap my position and some other
| > points. To wit:
| >
| >   * I think it is bad to overuse things like INLINE, and I believe it
| > encourages people to not understand the implications of what the
| > compiler is doing (all programmers generally must have some intuition
| > and control over their programs, and how they run.)
| >
| >   * Using the INLINE hammer everywhere makes it *incredibly* difficult
| > to see where GHC deficiencies are, and that's not what we want - it
| > hurts our ability to have informed decisions and examples. I also find
| > it slightly disheartening that many people don't think GHC can handle
| > cases like this.
| >
| >   * But Haskell is a language where inlining may not make a
| > constant-factor difference, but *orders of magnitude difference*.
| > vector-algorithms is a good example of this, and I'm not sure anyone
| > knows how to 'fix it' so it doesn't have to INLINE literally
| > everything. We're talking 10 orders of magnitude difference, if I
| > remember my conversations with Dan/Edward correctly. lens is a lesser
| > example: there are cases where GHC won't inline due to fear of work
| > duplication or other unusual cases, but we can tackle these in GHC in
| > some cases (and have.)
| >
| >   * We tend to be quite sensitive to performance matters as a
| community, I feel.
| >
| >   * And sometimes, things are hard. Even for people like Simon,
| > 'fixing' bad inliner behavior can be a monstrous task, and INLINE is
| > certainly a way to help the compiler when its hands are tied.
| >
| > Ultimately, nobody is wrong here. But we have options, and two of them
| > people brought up are good ones I think.
| >
| >   1.) Perhaps GHC should have a flag to warn you if you use
| > INLINE/INLINEABLE on a definition that the inliner would have dealt
| > with anyway. This should not be on by default with -Wall. But it would
| > give us a useful tool to examine our assumptions more easily in a lot
| > of cases.
| >
| >   2.) GHC does have a testsuite with many performance-related tests,
| > and tests that check the Core. We could easily add a test that checked
| > the core output of bool, maybe, and either (and other functions, as
| > time may go on.) This is much easier and probably more robust than
| > trying to contrive an example of what the performance difference might
| > be.
| >
| > Personally, I am way more interested in #1, as opposed to #2 (a
| > failure to inline something so small would quickly be noticed -
| > because lots of things probably won't inline at that point and our
| > tests will fail!) However, I believe both of these are relatively
| > easy, and quite feasible to implement.
| >
| > Unfortunately, I have about 10,000,000 things on my plate with the
| > upcoming release. So I'm afraid I don't have time to do these myself.
| >
| > So, patches welcome! However, I am more than willing to help people
| > get their feet wet in doing the work. You can email me (same email I'm
| > using now,) or contact me on IRC (freenode, nick 'thoughtpolice') if
| > you prefer more real time communication. I'll help you to the best of
| > my abilities if you'd like to give it a go.
| >
| >
| > On Mon, Sep 16, 2013 at 4:56 PM, Austin Seipp <austin <at> well-typed.com>
| wrote:
| >> A serious question: if you don't even trust GHC to inline 'bool',
| >> 'maybe' or 'either', given their triviality, do you trust it to ever
| >> inline anything at all? I'm being completely honest here.
| >>
| >> It still ignores the question of *why* the inliner is failing to do
| >> what you want. If the type inferencer fails to infer the type of an
| >> utterly trivial function - let's again say 'bool :: a -> a -> Bool ->
| >> a', as it's type is about as trivial as it's definition - it is
| almost
| >> certainly broken. By the same token, GHC not inlining 'bool' under -O
| >> would almost certainly be a bug too, in my eyes. The definition is
| >> trivial to the point where we should not ask "what if it doesn't
| >> inline" - we should figure out WHY it does not do so. Maybe INLINE
| >> would be a justified way of fixing it, but in this case it's just
| >> unnecessary and has been verified as such.
| >>
| >> By the same token, we also don't encourage people to wildly put `seq`
| >> everywhere, or make everything on earth strict just because it makes
| >> them feel good.
| >>
| >> A compiler must work on a broad range of programs for a broad range
| of
| >> use cases. There are certainly some cases that the compiler is *not*
| >> tuned for. In some of these cases, we work to make them more
| >> efficient. We patch the compiler to make it better where-ever
| >> possible. But this case? This is nothing but a premature optimization
| >> in my eyes - and one that even people like Edward or myself are
| guilty
| >> of, for sure.* And I am repenting by rejecting the "INLINE school of
| >> thought" (or INLINE school of hammers, as it were.)
| >>
| >> If you want to make the argument that 'bool' - or something else even
| >> - should be INLINE, by all means do so. But if you're going to do so
| >> without any empirical cases, or examples of why it should be so
| >> (especially when we have already checked the interface files,) and
| >> just say it lets you sleep better at night? I simply do not buy it.
| >>
| >>
| >> On Mon, Sep 16, 2013 at 3:59 PM, Dan Burton
| <danburton.email <at> gmail.com> wrote:
| >>> I'm wary of "let's not mark it as INLINE because we want the
| compiler to
| >>> automagically inline it for us." This seems like saying we should
| not have
| >>> type signatures, because we want the type inferencer to figure it
| out for
| >>> us. (If you want to test the auto-inliner's wisdom, then just add a
| setting
| >>> that ignores INLINE pragmas and see if it inlines the same thing
| that humans
| >>> do?)
| >>>
| >>> I don't really care how it's accomplished, but I do think that we
| should
| >>> make sure that maybe, either, and bool are inlined, and the most
| obvious way
| >>> to accomplish this is to directly mark them INLINE, is it not?
| >>>
| >>> -- Dan Burton
| >>>
| >>>
| >>> On Mon, Sep 16, 2013 at 1:33 PM, Edward Kmett <ekmett <at> gmail.com>
| wrote:
| >>>>
| >>>> Contrary to appearances, I fully agree. =)
| >>>>
| >>>>
| >>>> On Mon, Sep 16, 2013 at 4:12 PM, Austin Seipp <austin <at> well-
| typed.com>
| >>>> wrote:
| >>>>>
| >>>>> I'm strongly opposed to this.
| >>>>>
| >>>>> Being INLINE happy is not a good thing, it is a bad thing. More
| often
| >>>>> than not, I see people stuffing INLINE all over the place for
| things
| >>>>> that would trivially be unfolded and put in the interface file
| anyway.
| >>>>> This is bad, and it teaches people to just use the INLINE hammer
| >>>>> everywhere instead of understanding the actual implications of
| what
| >>>>> the inliner does. It also makes it impossible to actually observe
| how
| >>>>> the inliner behaves and see where it needs tuning: if we just mark
| >>>>> everything INLINE, we might as well not have it and make it
| >>>>> unconditional.
| >>>>>
| >>>>> There are some particular cases where GHC is hesitant to inline
| small
| >>>>> things if it would lead to work duplication, or where the inliner
| >>>>> behavior is tweaked and you may want to force it across multiple
| >>>>> versions to be sure (lens is a good example of this.) But this is
| far
| >>>>> more rare, and this case is not that. In particular, Joachim
| checked
| >>>>> the 'bool' commit. As expected, the unfolding for bool was put
| into
| >>>>> the interface file for Data.Bool, meaning if you use -O (or just -
| O0
| >>>>> -fno-ignore-interface-pragmas,) it should be inlined at call sites
| >>>>> appropriately when it is used.
| >>>>>
| >>>>> If we're going to INLINE things, we need to make sure it actually
| has
| >>>>> an empirical benefit, by looking at the core, and seeing where the
| >>>>> inliner is failing. Not just attach it to things because it seems
| like
| >>>>> a good idea. This also helps drive feedback into the inliner so we
| can
| >>>>> see where it fails.
| >>>>>
| >>>>> On Mon, Sep 16, 2013 at 2:59 PM, Carter Schonwald
| >>>>> <carter.schonwald <at> gmail.com> wrote:
| >>>>>> Its come to my attention that maybe, either, and its new sibling
| bool,
| >>>>>> all
| >>>>>> lack the
| >>>>>> INLINEABLE attribute, or its more aggressive sibling INLINE
| >>>>>>
| >>>>>> this seems like one of those operations where inlining in client
| use
| >>>>>> sites
| >>>>>> is a good option to have, and currently not possible!
| >>>>>>
| >>>>>> theres probably other stuff that would benefit from an INLINEABLE
| >>>>>> pragma in
| >>>>>> base,
| >>>>>> but this is an obvious, simple, "easy win" that I noticed when
| Oliver's
| >>>>>> patch got merged into base.
| >>>>>>
| >>>>>> Thoughts?
| >>>>>> Time scale: sometime this week? (ghc 7.8 merge window is
| landing!)
| >>>>>>
| >>>>>> cheers
| >>>>>>
| >>>>>> _______________________________________________
| >>>>>> Libraries mailing list
| >>>>>> Libraries <at> haskell.org
| >>>>>> http://www.haskell.org/mailman/listinfo/libraries
| >>>>>>
| >>>>>
| >>>>>
| >>>>>
| >>>>> --
| >>>>> Austin Seipp, Haskell Consultant
| >>>>> Well-Typed LLP, http://www.well-typed.com/
| >>>>> _______________________________________________
| >>>>> Libraries mailing list
| >>>>> Libraries <at> haskell.org
| >>>>> http://www.haskell.org/mailman/listinfo/libraries
| >>>>
| >>>>
| >>>>
| >>>> _______________________________________________
| >>>> Libraries mailing list
| >>>> Libraries <at> haskell.org
| >>>> http://www.haskell.org/mailman/listinfo/libraries
| >>>>
| >>>
| >>
| >>
| >>
| >> --
| >> Austin Seipp, Haskell Consultant
| >> Well-Typed LLP, http://www.well-typed.com/
| >
| >
| >
| _______________________________________________
| Libraries mailing list
| Libraries <at> haskell.org
| http://www.haskell.org/mailman/listinfo/libraries
Bardur Arantsson | 26 Sep 18:02 2013
Picon

Re: add INLINEABLE to maybe, either, bool

On 2013-09-26 17:45, Simon Marlow wrote:
> I read this discussion and thought that one small thing we could do is
> to clarify the documentation for INLINE a bit.  Here's what I came up
> with; comments welcome.  I'll commit this if there are no objections.
> 
>         <para>
>           GHC (with <option>-O</option>, as always) tries to inline
>           (or &ldquo;unfold&rdquo;) functions/values that are
>           &ldquo;small enough,&rdquo; thus avoiding the call overhead
>           and possibly exposing other more-wonderful optimisations.
>           GHC has a set of heuristics, tuned over a long period of
>           time using many benchmarks, that decide when it is
>           beneficial to inline a function at its call site.  The
>           heuristics are designed to inline functions when it appears
>           to be beneficial to do so, but without incurring excessive
>           code bloat.  If a function looks too big, it won't be
>           inlined, and functions larger than a certain size will not
>           even have their definition exported in the interface file.
>           Some of the thresholds that govern these heuristic decisions
>           can be changed using flags, see <xref linkend="options-f"
>           />.
>         </para>
> 
>         <para>
>           Normally GHC will do a reasonable job of deciding by itself
>           when it is a good idea to inline a function.  However,
>           sometimes you might want to override the default behaviour.
>           For exmaple, if you have a key function that is important to
                ^^^^^^^

Typo.
wren | 17 Sep 04:15 2013

Re: add INLINEABLE to maybe, either, bool

On 9/16/13 4:59 PM, Dan Burton wrote:
> I'm wary of "let's not mark it as INLINE because we want the compiler 
> to
> automagically inline it for us." This seems like saying we should not 
> have
> type signatures, because we want the type inferencer to figure it out 
> for
> us. (If you want to test the auto-inliner's wisdom, then just add a 
> setting
> that ignores INLINE pragmas and see if it inlines the same thing that
> humans do?)
>
> I don't really care how it's accomplished, but I do think that we 
> should
> make sure that maybe, either, and bool are inlined, and the most 
> obvious
> way to accomplish this is to directly mark them INLINE, is it not?

I almost wonder if there should be a SHOULD_INLINE pragma which does 
not actually change program behavior, but rather will emit warnings if 
the marked function does not end up in the interface file. (N.B., this 
is distinct from ensuring that we inline it at any particular 
call-site.)

The inliner is fairly robust at this point, but SHOULD_INLINE would 
also help catch regressions; I'm mainly thinking of base and core 
libraries here, rather than general libraries. Though, for general 
libraries, having the pragma could help folks learn what the inliner 
deems to be "small enough". I think it's clear *what* the inliner does; 
but it's not always clear *when* it will decide to do its magic.

--

-- 
Live well,
~wren

Gmane