add INLINEABLE to maybe, either, bool

[Dan Doel]

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