- ghc-devs - Haskell.org

Re: Performance degradation when factoring out common code
by Harendra Kumar 10 Sep '17

10 Sep '17

Thanks Mikolaj! I have seen some surprising behavior quite a few times recently and I was wondering whether GHC should do better. In one case I had to use SPECIALIZE very aggressively, in another version of the same code it worked well without that. I have been doing a lot of trial and error with the INLINE/NOINLINE pragmas to figure out what the right combination is. Sometimes it just feels like black magic, because I cannot find a rationale to explain the behavior. I am not sure if there are any more such problems lurking in, perhaps this is an area where some improvement looks possible. -harendra On 8 September 2017 at 17:10, Mikolaj Konarski <mikolaj.konarski(a)gmail.com> wrote: > Hello, > > I've had a similar problem that's been fixed in 8.2.1: > > https://ghc.haskell.org/trac/ghc/ticket/12603 > > You can also use some extreme global flags, such as > > ghc-options: -fexpose-all-unfoldings -fspecialise-aggressively > > to get most the GHC subtlety and shyness out of the way > when experimenting. > > Good luck > Mikolaj > > > > On Fri, Sep 8, 2017 at 11:21 AM, Harendra Kumar > <harendra.kumar(a)gmail.com> wrote: > > Hi, > > > > I have this code snippet for the bind implementation of a Monad: > > > > AsyncT m >>= f = AsyncT $ \_ stp yld -> > > let run x = (runAsyncT x) Nothing stp yld > > yield a _ Nothing = run $ f a > > yield a _ (Just r) = run $ f a <> (r >>= f) > > in m Nothing stp yield > > > > I want to have multiple versions of this implementation parameterized by > a > > function, like this: > > > > bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> > > let run x = (runAsyncT x) Nothing stp yld > > yield a _ Nothing = run $ f a > > yield a _ (Just r) = run $ f a `k` (bindWith k r f) > > in m Nothing stp yield > > > > And then the bind function becomes: > > > > (>>=) = bindWith (<>) > > > > But this leads to a performance degradation of more than 10%. inlining > does > > not help, I tried INLINE pragma as well as the "inline" GHC builtin. I > > thought this should be a more or less straightforward replacement making > the > > second version equivalent to the first one. But apparently there is > > something going on here that makes it perform worse. > > > > I did not look at the core, stg or asm yet. Hoping someone can quickly > > comment on it. Any ideas why is it so? Can this be worked around somehow? > > > > Thanks, > > Harendra > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >

3 8

Re: Performance degradation when factoring out common code
by Harendra Kumar 08 Sep '17

08 Sep '17

I tested my code on GHC 8.2.1, there is a good news and a bad news. The good news is that with 8.2.1 performance of my code has improved by a huge margin of around 20%, I had reported a similar perf improvement earlier in another one of my package with 8.2. The bad news is that the problem that I reported today is not fixed. I am still seeing a 15% difference between automatic and manual inlining. I guess I should raise a ticket. -harendra On 8 September 2017 at 17:10, Mikolaj Konarski <mikolaj.konarski(a)gmail.com> wrote: > Hello, > > I've had a similar problem that's been fixed in 8.2.1: > > https://ghc.haskell.org/trac/ghc/ticket/12603 > > You can also use some extreme global flags, such as > > ghc-options: -fexpose-all-unfoldings -fspecialise-aggressively > > to get most the GHC subtlety and shyness out of the way > when experimenting. > > Good luck > Mikolaj > > > > On Fri, Sep 8, 2017 at 11:21 AM, Harendra Kumar > <harendra.kumar(a)gmail.com> wrote: > > Hi, > > > > I have this code snippet for the bind implementation of a Monad: > > > > AsyncT m >>= f = AsyncT $ \_ stp yld -> > > let run x = (runAsyncT x) Nothing stp yld > > yield a _ Nothing = run $ f a > > yield a _ (Just r) = run $ f a <> (r >>= f) > > in m Nothing stp yield > > > > I want to have multiple versions of this implementation parameterized by > a > > function, like this: > > > > bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> > > let run x = (runAsyncT x) Nothing stp yld > > yield a _ Nothing = run $ f a > > yield a _ (Just r) = run $ f a `k` (bindWith k r f) > > in m Nothing stp yield > > > > And then the bind function becomes: > > > > (>>=) = bindWith (<>) > > > > But this leads to a performance degradation of more than 10%. inlining > does > > not help, I tried INLINE pragma as well as the "inline" GHC builtin. I > > thought this should be a more or less straightforward replacement making > the > > second version equivalent to the first one. But apparently there is > > something going on here that makes it perform worse. > > > > I did not look at the core, stg or asm yet. Hoping someone can quickly > > comment on it. Any ideas why is it so? Can this be worked around somehow? > > > > Thanks, > > Harendra > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >

1 0

Performance degradation when factoring out common code
by Harendra Kumar 08 Sep '17

08 Sep '17

Hi, I have this code snippet for the bind implementation of a Monad: AsyncT m >>= f = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a <> (r >>= f) in m Nothing stp yield I want to have multiple versions of this implementation parameterized by a function, like this: bindWith k (AsyncT m) f = AsyncT $ \_ stp yld -> let run x = (runAsyncT x) Nothing stp yld yield a _ Nothing = run $ f a yield a _ (Just r) = run $ f a `k` (bindWith k r f) in m Nothing stp yield And then the bind function becomes: (>>=) = bindWith (<>) But this leads to a performance degradation of more than 10%. inlining does not help, I tried INLINE pragma as well as the "inline" GHC builtin. I thought this should be a more or less straightforward replacement making the second version equivalent to the first one. But apparently there is something going on here that makes it perform worse. I did not look at the core, stg or asm yet. Hoping someone can quickly comment on it. Any ideas why is it so? Can this be worked around somehow? Thanks, Harendra

2 1

Help with #14140
by David Feuer 08 Sep '17

08 Sep '17

Could you maybe point me toward where the constant folding is happening in this context? I'd like to take a glance and see if I can guess how to upgrade it to deal with what we know things *aren't*. Thanks in advance. David FeuerWell-Typed, LLP

1 0

A newcomer: how to start
by Sergey Bykov 07 Sep '17

07 Sep '17

Hi, my name is Sergey and I'm recently joined to this mailing list. I would like to help GHC's community and start contributing to the GHC project. Could someone recommend a few tasks, which seems to be suitable for a beginner? About myself: I'm pretty experienced Research Scientist/Software Developer in such areas like discrete optimization and machine learning. Thanks in advance!

3 2

Re: [GHC] #13716: Move CI to Jenkins
by davean 07 Sep '17

07 Sep '17

Thats actually how this project started. On Wed, Sep 6, 2017 at 7:05 PM, GHC <ghc-devs(a)haskell.org> wrote: > #13716: Move CI to Jenkins > -------------------------------------+---------------------- > --------------- > Reporter: bgamari | Owner: (none) > Type: task | Status: new > Priority: normal | Milestone: > Component: None | Version: 8.0.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: 13897 | Blocking: > Related Tickets: #11958 | Differential Rev(s): > Wiki Page: | > -------------------------------------+---------------------- > --------------- > > Comment (by refold): > > Is there any chance Cabal/cabal-install could piggyback on this effort? > We've outgrown free services like Travis and AppVeyor and could use > support for additional platforms (OpenBSD and maybe ARM) too. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13716#comment:6> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

3 2

GHC staus
by Simon Peyton Jones 04 Sep '17

04 Sep '17

Ben, Simon, and ghc-devs I have to write slides for the GHC status talk in the Haskell Implementor's meeting. Usually we have 1. Current status (current release) 2. What's cooking for the next release 3. GHC community comments As background we have * Our Apr 17 status page<https://ghc.haskell.org/trac/ghc/wiki/Status/Apr17> * Our 8.2 release notes<https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/8.2.1-notes.…> * Our 8.4 status page<https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.4.1> What would you put under (1-3)? Anything you'd like to see highlighted? Simon

11 13

Re: Type-level generics
by Ryan Scott 03 Sep '17

03 Sep '17

If you're willing to go a completely different route from GHC.Generics, then you might be interested in the paper Generic Programming with Multiple Parameters [1] (whose existence I just learned of—thanks to Pedro, the author, for pointing it out to me). It does present a single Generic class that is capable of working over any number of type parameters, although the interface presented is significantly more complex than the current GHC.Generics. The only reason I mention backwards compatibility is that if we are going to introduce a GHC.Generics 2.0 some day, it'd be nice to have a way to subsume the old interface with the new one, and fortunately, the aforementioned paper includes an algorithm for doing so. My hope was that we'd be able to incorporate these ideas into a design that also grants the ability to write Generic instances for GADTs, but I don't think GHC has a fancy enough type system to do this satisfactorily at the moment. Ryan S. ----- [1] http://dreixel.net/research/pdf/gpmp_colour.pdf

2 1

Re: Type-level generics
by David Feuer 03 Sep '17

03 Sep '17

Ah, nice. I was actually exploring the vague general idea behind that approach earlier this evening. Magalhães (unsurprisingly) has developed it much much further. David FeuerWell-Typed, LLP -------- Original message --------From: Ryan Scott <ryan.gl.scott(a)gmail.com> Date: 9/2/17 10:36 PM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: Re: Type-level generics If you're willing to go a completely different route from GHC.Generics, then you might be interested in the paper Generic Programming with Multiple Parameters [1] (whose existence I just learned of—thanks to Pedro, the author, for pointing it out to me). It does present a single Generic class that is capable of working over any number of type parameters, although the interface presented is significantly more complex than the current GHC.Generics. The only reason I mention backwards compatibility is that if we are going to introduce a GHC.Generics 2.0 some day, it'd be nice to have a way to subsume the old interface with the new one, and fortunately, the aforementioned paper includes an algorithm for doing so. My hope was that we'd be able to incorporate these ideas into a design that also grants the ability to write Generic instances for GADTs, but I don't think GHC has a fancy enough type system to do this satisfactorily at the moment. Ryan S. ----- [1] http://dreixel.net/research/pdf/gpmp_colour.pdf _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Re: Type-level generics
by Ryan Scott 02 Sep '17

02 Sep '17

Several good points were brought up. Let me go through them and try to make sense of what I can: > When I looked at it the last time, there were some apparent leftovers in the form of types or type parameters never used. Are you referring to the `p` type parameters that are found in most of the data types in GHC.Generics? If so, they are most definitely used—try deriving Generic1 to see this in action! It's true that in the context of Generic (without the 1 at the end) the `p` isn't used, but this is by design, as this allows us to share the same representation types across Generic and Generic1. > there is no possibility to work with types with more than one parameter. Quite true. But I posit that engineering GHC.Generics to work with more than one type parameter at a time is much harder than it sounds. After all, to profitably work with even a *single* type parameter (what Generic1 does), we must bring in three additional representation types: Par1, Rec1, and (:.:), depending on where in the datatype the last type parameter occurs. If we wanted to have, say, Generic2, we'd similarly need to be able to work with many more combinations of type parameter positions, such as: * data Foo1 a b = Foo1 a b * data Foo2 a b = Foo2 (Either a b) * data Foo3 a b = Foo3 (Either b a) * etc. A naïve approach would be to tack on another type parameter at the end of every representation type, and introduce more types to deal with all the combinations of the first and second type parameter that could arise. But this approach doesn't scale well—after all, at what number N do you stop introducing new representation types? So extending GHC.Generics to deal with more than one type parameter is far from obvious to me (let alone whether it could be made backwards compatible with the current API). > the GHC.Generics module looks a bit unpolished and ad-hoc at the moment. Yes, quite literally everything in GHC.Generics is one large, ad hoc hack. But it's also a darn useful one :) > It looks like there's still one confusing reference to Par0: "Note how Par0 and Rec0 both being mapped to K1 allows us to define a uniform instance here. " but at least it's not tangled up in the already very confusing examples and signatures. I think that sentence can be deleted entirely now? Indeed, an earlier part of the documentation in that module mentions that Par0 was deprecated (and removed, in fact), so we really shouldn't be mentioning it elsewhere. I'll remove that sentence. Ryan S.

2 1