> Please do - I suspect that GHC structures can become quite large,
> and though they might not be as big as that benchmark, the penalty
> seems substrantial.
I will probably leave it for a short while, til I am on a better
machine to run the necessary benchmarks. But I do want to track it
down
|if I apply this to the SYB traversal, I get the expected speedup.
..
|Now I need to clean up the mess I made of the source while
|experimenting, and see how to extract this adaptation of the
|Uniplate trick for general SYB use.
I've slightly cleaned up my code and posted it, with some
explana
:44
| To: Simon Marlow
| Cc: Simon Peyton-Jones; cvs-ghc@haskell.org; Max Bolingbroke
| Subject: Re: Data/Typeable/Uniplate instances for GHC types
|
| 2008/7/18 Simon Marlow <[EMAIL PROTECTED]>:
| > That approach worries me. We could add generic traversals all over the
| > place,
Hi
>*Main> uni_bill laemmel
>{CompanyDatatypes.Employee}
>{CompanyDatatypes.Salary}
>8000
>*Main> uni_bill laemmel
>{CompanyDatatypes.Employee}
>{CompanyDatatypes.Salary}
>8000
>*Main> (uni_bill laemmel,uni_bill laemmel)
>
While you ignore the explicit parameter, in practice there's an
implicit dictionary parameter that is actually being used in res
(Data/Typeable). At first sight, that might sound okay -we want a caf per
type after all- but what happens is that we get *a caf per dictionary
parameter* instead.
M
Hi
> I think I've figured out what is going on: this technique simply
> doesn't work as well as we might hope it would! Here's why:
>
> While you ignore the explicit parameter, in practice there's an
> implicit dictionary parameter that is actually being used in res
> (Data/Typeable). At first
I couldn't quite figure out how to make a type-dependent CAF in the class
instances, as your paper suggests, so I made my CAF at the top-level
instead
instance Domain a b where
domain = \_ -> res
where res = ... the computed domain ...
class Domain a b where
domain :: (a,b) -> IntSet
ssage-
| From: Chaddaï Fouché [mailto:[EMAIL PROTECTED]
| Sent: 18 July 2008 15:44
| To: Simon Marlow
| Cc: Simon Peyton-Jones; cvs-ghc@haskell.org; Max Bolingbroke
| Subject: Re: Data/Typeable/Uniplate instances for GHC types
|
| 2008/7/18 Simon Marlow <[EMAIL PROTECTED]>:
| > That appro
IntSets of TypeRepKeys!-)
IntSet's are only possible in 6.8 due to API changes :-)
infinite possibilities of combining type-level programming
with efficient execution!-)
I couldn't quite figure out how to make a type-dependent CAF in the class
instances, as your paper suggests, so I made m
Hi
> > That approach worries me. We could add generic traversals all over the
> > place, and while none of them is a "bottleneck", the overall effect could
> be
> > quite significant.
>
> I recently added Data and Typeable instance to all AST datatypes
> directly in the code of GHC, the compi
2008/7/18 Simon Marlow <[EMAIL PROTECTED]>:
> That approach worries me. We could add generic traversals all over the
> place, and while none of them is a "bottleneck", the overall effect could be
> quite significant.
>
> The right approach I believe is to keep an eye on compile times when making
>
Simon Peyton-Jones wrote:
| The thesis suggests that using Uniplate with the fastest instances
| will be around 30% slower than manual operations, but using SYB based
| instances will be 300% slower. In practice, these are benchmarks on
| generic traversals, and may not accurately reflect how peo
Hi
> From your thesis/paper, it seems that queries, such as 'bill' in the
> Paradise benchmark, are the worst offenders, performancewise, and applying
> your techniques for Uniplate to the SYB query for 'bill' seems to achieve a
> similar reduction in runtime.
> 'contains' is interesting, and s
| So far, I still think that SYB for GHC types is a good and necessary
| first step. If adding Uniplate instances as well gives significant
| improvements in efficiency or convenience, I won't argue against.
An alternative viewpoint might be: do the simpler, more efficient,
and easier-to-use thi
| So far, I still think that SYB for GHC types is a good and necessary
| first step. If adding Uniplate instances as well gives significant
| improvements in efficiency or convenience, I won't argue against.
An alternative viewpoint might be: do the simpler, more efficient, and
easier-to-use thi
(skipping redundant types) its fairly complex but doesn't touch gfoldl,
and most of the difficult code can be stolen from Uniplate.
From your thesis/paper, it seems that queries, such as 'bill' in the
Paradise benchmark, are the worst offenders, performancewise,
and applying your techniques fo
Neil Mitchell wrote:
Hi
Might help if library author and user are related?-)
Yes :-) I'd like to think that anyone can use Uniplate in a very
high-level manner, but someone other than me needs to argue that.
That was also my sense when I used Uniplate, but I didn't really use it
enough t
| The thesis suggests that using Uniplate with the fastest instances
| will be around 30% slower than manual operations, but using SYB based
| instances will be 300% slower. In practice, these are benchmarks on
| generic traversals, and may not accurately reflect how people using
| the libraries in
Hi
> Might help if library author and user are related?-)
Yes :-) I'd like to think that anyone can use Uniplate in a very
high-level manner, but someone other than me needs to argue that.
> So far, I still think that SYB for GHC types is a good and necessary
> first step. If adding Uniplate
I find Uniplate to be completely the opposite. I always use the
predefine schemes, and they are nearly always exactly what I want.
Whether this is a difference in the traversals provided by the
library, or in the mindset of the user of the library is still up for
debate.
Might help if library au
Hi
> > too general to allow the Uniplate solution, but it would be easy to
> > add universe/transform to SYB and implement them using them much more
> > efficiently.
> >
>
> It has been a while, and most of my experience was with Strafunski's
> StrategyLib, but I seem to recall using the predefin
in SYB were (a) traversing irrelevant parts of the structure
(because everything is treated generically)
Yes, this is a big one. In particular Haskell String's being defined
as [Char] makes SYB do a lot of redundant work on characters which are
unlikely to be the target. SYB's types for everyt
Hi
> > No boilerplate removal code 1:30min
> > Uniplate with PlateDirect (fastest method) 1:45min
> > Uniplate with PlateData (based on SYB) 5min
> >
> > And I suspect directly using SYB would have been somewhere in the
> > 10-15min range.
> >
>
> It would be useful to have more information about
Hi
> How did you define the Data instances for the abstract types
> (break the abstraction or define the instances abstractly), and how do your
> instances compare to the ones at
> http://hackage.haskell.org/trac/ghc/wiki/GhcApiAstTraversals
> ?
The Uniplate one's can't transform the type, and
> How did you define the Data instances for the abstract types
> (break the abstraction or define the instances abstractly), and how do your
> instances compare to the ones at
> http://hackage.haskell.org/trac/ghc/wiki/GhcApiAstTraversals ?
The instances do not attempt to traverse the abstract dat
The thesis suggests that using Uniplate with the fastest instances
will be around 30% slower than manual operations, but using SYB based
instances will be 300% slower. In practice, these are benchmarks on
generic traversals, and may not accurately reflect how people using
the libraries in practice
I don't know enough about Uniplate to make a judgement on that point,
so I'll just pipe up and say that having Data/Typeable instances for
Expr, Binds and friends would be of much benefit to the GHC plugins
project. I've actually already written my own instances and put them
straight into CoreSyn.
Hi
> You can implement Uniplate on top of Data/Typeable. (It's slightly slower
> than giving Uniplate instances directly, but if my memory serves, not a lot.
> See Neil's theis.) So you can think of Uniplate/Biplate as a rather nice API
> for generic programming, but one that shares a common
| > Neil Mitchell tells me that he and Simon PJ are in favour of adding
| > instances for Data, Typeable, and Uniplate for many of the datatypes used
| > inside GHC. I agree that this should certainly be done for the external
| > interface of GHC, i.e., core-plugins and GHC API. Here they could
2008/7/15 Thomas Schilling <[EMAIL PROTECTED]>:
> Tachchen,
>
> Neil Mitchell tells me that he and Simon PJ are in favour of adding
> instances for Data, Typeable, and Uniplate for many of the datatypes used
> inside GHC. I agree that this should certainly be done for the external
> interface of G
Hi Thomas,
does that mean your project has started at last?-) Judging
from recent Haskell Weekly News issues, I wasn't the only
one who had despaired of ever hearing from you again;-)
Since you've only just joined the discussion, and apparently
haven't yet caught up on recent email here, you mig
Tachchen,
Neil Mitchell tells me that he and Simon PJ are in favour of adding
instances for Data, Typeable, and Uniplate for many of the datatypes
used inside GHC. I agree that this should certainly be done for the
external interface of GHC, i.e., core-plugins and GHC API. Here they
cou
32 matches
Mail list logo
