add INLINEABLE to maybe, either, bool

[Edward Kmett]

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<http://ghc.haskell.org/trac/ghc/ticket/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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131011/a653b868/attachment.html>