[Haskell-cafe] Inlinable (>>>)

[David Sorokin]

Hi Cafe,

I offer to define the functions of the Control.Category module inlinable:

-- | Right-to-left composition
(<<<) :: Category cat => cat b c -> cat a b -> cat a c
{-# INLINABLE (<<<) #-}
(<<<) = (.)

-- | Left-to-right composition
(>>>) :: Category cat => cat a b -> cat b c -> cat a c
{-# INLINABLE (>>>) #-}
f >>> g = g . f

Perhaps all functions from this module should be marked by this pragma as possible.

I suppose that the current definition without the pragma is the cause why the execution slows down in my applications, when using monad parameters in the constraints. I noticed it yet two or three years ago, while playing with the monad transformers, but decided to write now.

Best regards,
David Sorokin

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

[Joe Hillenbrand]

CCing Libraries

[Joachim Breitner]

Hi,

Am Donnerstag, den 02.03.2017, 18:18 +0300 schrieb David Sorokin:
> I offer to define the functions of the Control.Category module
> inlinable:
>
> -- | Right-to-left composition
> (<<<) :: Category cat => cat b c -> cat a b -> cat a c
> {-# INLINABLE (<<<) #-}
> (<<<) = (.)
>
> -- | Left-to-right composition
> (>>>) :: Category cat => cat a b -> cat b c -> cat a c
> {-# INLINABLE (>>>) #-}
> f >>> g = g . f
>
> Perhaps all functions from this module should be marked by this
> pragma as possible.

I am surprised that GHC does not consider these inlineable
automatically. Maybe it should? Would be worth investigating, if
someone is interested in some entry-level GHC hacking, why GHC does not
treat them as `INLINEABLE` in the first place. They are certainly small
enough, I would say…

Joachim

--
Joachim “nomeata” Breitner
  ma...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nom...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nom...@debian.org

[Matthew Pickering]

I suspect this is because GHC will not specialise functions when used
in other modules unless they are marked INLINABLE.

Matt

[Saurabh Nanda]

I had a similar WTF moment when I noticed that Lucid's HtmlT over IO was 2x slower than HtmlT over Reader/Identity. Discussions over this mailing list pointed to the lack of INLINE pragmas on various functions, like >>=

It was finally resolved via a liberal sprinkling of INLINE -- https://github.com/chrisdone/lucid/pull/67/files 

Why can't GHC automatically consider *every* function as INLINABLE? Let the GHC heuristics decide what is worthy of being inlined. What's the downside?

-- Saurabh. 

[Brandon Allbery]

On Sat, Mar 4, 2017 at 11:58 AM, Saurabh Nanda <saurab...@gmail.com> wrote:

Why can't GHC automatically consider *every* function as INLINABLE? Let the GHC heuristics decide what is worthy of being inlined. What's the downside?

At a guess, performance of both .hi file handling and analysis for inlining. Don't people already gripe about how "slow" ghc is?

Also, inlining the wrong thing can completely derail other optimizations (e.g. fusion).

--

brandon s allbery kf8nh                               sine nomine associates

allb...@gmail.com                                  ball...@sinenomine.net

unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

[Joachim Breitner]

Hi,

Am Samstag, den 04.03.2017, 22:28 +0530 schrieb Saurabh Nanda:
> I had a similar WTF moment when I noticed that Lucid's HtmlT over IO
> was 2x slower than HtmlT over Reader/Identity. Discussions over this
> mailing list pointed to the lack of INLINE pragmas on various
> functions, like >>=
>
> It was finally resolved via a liberal sprinkling of INLINE -- https:/
> /github.com/chrisdone/lucid/pull/67/files 
>
> Why can't GHC automatically consider *every* function as INLINABLE?
> Let the GHC heuristics decide what is worthy of being inlined. What's
> the downside?

the original post was about INLINEABLE not INLINE – let’s keep these
two apart.

INLINEABLE says: „Dear compiler, keep the definition of this function
in the interface so that you can, maybe, inline (or specialize) it
later.“

INLINE implies INLINEABLE, but also says: „…, and really do inline it“.

BTW, there is a flag -fexpose-all-unfoldings that effectively add
INLINEABLE to all functions.

Greetings,

[Matthew Pickering]

-fexpose-all-unfoldings will allow all definitions to be inlined
across modules but NOT specialised. If you want to turn on more
aggressive specialisation then you can also use
-fspecialise-aggressively. Using the two together would be more like
marking everything as INLINABLE but not exactly the same.

[Saurabh Nanda]

The original post was about INLINEABLE not INLINE – let’s keep these

two apart

I understand the difference between INLINE and INLINEABLE. However from a practical standpoint aren't the two highly correlated? I wouldn't need to bother with INLINE if GHC considered every function as INLINEABLE and had a good set of inlining heuristics. Also, as a newbie, I would prefer depending on the compiler's heuristics, rather than forcing it to inline functions (the impact of which I may not fully understand)

-- Saurabh. 

[Saurabh Nanda]

.At a guess, performance of both .hi file handling and analysis for inlining. Don't people already gripe about how "slow" ghc is?

In that case, an optional flag which people can turn-on only when preparing the final build to be pushed into production.  

-- Saurabh.