Quantcast

Inlinable (>>>)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Inlinable (>>>)

David Sorokin-2
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

Joe Hillenbrand
CCing  Libraries

On Thu, Mar 2, 2017 at 7:18 AM, David Sorokin <[hidden email]> wrote:

> 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.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

Joachim Breitner-2
In reply to this post by David Sorokin-2
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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
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.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

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

Matt

On Fri, Mar 3, 2017 at 11:40 AM, Joachim Breitner
<[hidden email]> wrote:

> 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
>   [hidden email]https://www.joachim-breitner.de/
>   XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: [hidden email]
> _______________________________________________
> 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.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

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. 

On 3 Mar 2017 5:36 pm, "Matthew Pickering" <[hidden email]> wrote:
I suspect this is because GHC will not specialise functions when used
in other modules unless they are marked INLINABLE.

Matt

On Fri, Mar 3, 2017 at 11:40 AM, Joachim Breitner
<[hidden email]> wrote:
> 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
>   [hidden email]https://www.joachim-breitner.de/
>   XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: [hidden email]
> _______________________________________________
> 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.
_______________________________________________
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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

Brandon Allbery

On Sat, Mar 4, 2017 at 11:58 AM, Saurabh Nanda <[hidden email]> 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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

Joachim Breitner-2
In reply to this post by Saurabh Nanda
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,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
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.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

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.


On Sat, Mar 4, 2017 at 7:13 PM, Joachim Breitner
<[hidden email]> wrote:

> 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,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   [hidden email]https://www.joachim-breitner.de/
>   XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: [hidden email]
>
> _______________________________________________
> 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.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

Saurabh Nanda
In reply to this post by Joachim Breitner-2
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. 

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Inlinable (>>>)

Saurabh Nanda
In reply to this post by Brandon Allbery
.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. 

_______________________________________________
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.
Loading...