I have two questions about using Hoopl:
1) I'm debugging some Hoopl transformations that often fall into an infinite
loop. Probably the easiest way to find the cause would be to allow only a
limited number of iterations and then examining the rewritten output. I think
that optimization fuel was
Hi,
in the context of the newtype wrapper I have an instance selection
problem where even IncoherentInstances is not liberal enough. Consider
this example:
Prelude> :set -XFlexibleInstances -XIncoherentInstances -XMultiParamTypeClasses
Prelude> class Class a b where { method :: (a,b); method = u
T5321FD and T5321Fun are failing with HEAD - performance stat is too good.
Looks like the allocation has decreased. Did anyone notice when this
improvement happened?
Janek
___
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/l
OK, let's make it "Three Hoopl questions".
3) Consider this rewriting function:
cpRwMiddle dflags (CmmStore lhs rhs) _ = do
u <- getUniqueUs
let regSize = cmmExprType dflags rhs
newReg = CmmLocal $ LocalReg u regSize
newRegAssign = CmmAssign newReg rhs
newMemAssig
If no one remembers, just accept the new values!
| -Original Message-
| From: ghc-devs [mailto:[email protected]] On Behalf Of Jan
Stolarek
| Sent: 26 July 2013 15:57
| To: ghc-devs
| Subject: T5321FD and T5321Fun performance improvements
|
| T5321FD and T5321Fun are fa
I'm not really concerned that tests improved, but I wonder whether this
improvement was caused by recent fix for #8083 pushed by Simon Marlow. Given
performance changes I reported in #8082 I simply wonder how sensitive is the
code generation. I observed one case where performance improves by 20%
Hello Jan,
Re (1), there is an important invariant that your transformations should
uphold to avoid infinite loops. This invariant is described in the
Hoopl paper:
> • The lattice must have no infinite ascending chains; that is,
> every sequence of calls to fact_join must eventually return
> NoC
Looks like whitehole_spin is _not_ always 0. Contention just seems to be
really rare.
On Thu, Jul 25, 2013 at 1:32 PM, Patrick Palka wrote:
> It seems that the value of the whitehole_spin counter (as viewable by +RTS
> -s) is always zero, which oddly suggests that there is never any contention
Excerpts from Patrick Palka's message of Fri Jul 26 14:21:11 -0700 2013:
> Looks like whitehole_spin is _not_ always 0. Contention just seems to be
> really rare.
I think the paper "Parallel Generational-Copying Garbage Collection with
a Block-Structured Heap" can give some intuition on why conten
Thank you Edward. I am aware of these requirements - my problem is writing the
code in which these
will always hold (I'm optimizing Cmm and hand-written Cmm files tend to cause
many problems that
don't appear in automatically generated Cmm). Having a debugging tool in form
of Fuel would be
he
> Thank you Edward. I am aware of these requirements - my problem is writing
> the code in which these
> will always hold (I'm optimizing Cmm and hand-written Cmm files tend to cause
> many problems that
> don't appear in automatically generated Cmm). Having a debugging tool in form
> of Fuel
Thanks! That was a very informative read.
On Fri, Jul 26, 2013 at 5:31 PM, Edward Z. Yang wrote:
> Excerpts from Patrick Palka's message of Fri Jul 26 14:21:11 -0700 2013:
> > Looks like whitehole_spin is _not_ always 0. Contention just seems to be
> > really rare.
>
> I think the paper "Parall
It's easy to get confused, but in fact the bedrock issues are quite simple.
As Edward says, a function f is monotonic iff
x <= y impliesf(x) <= f(y)
Monotonicity does NOT mean that x <= f(x)!!!
The transfer function, and the 'join' function, must all be monotonic. It's
that
Yes it'll generate two uniques. I think that's fine.
Simon
| -Original Message-
| From: ghc-devs [mailto:[email protected]] On Behalf Of Jan
Stolarek
| Sent: 26 July 2013 16:56
| To: ghc-devs
| Subject: Re: Two Hoopl questions
|
| OK, let's make it "Three Hoopl ques
Joachim
Good point.
There is something odd about this. "IncoherentInstances" is meant to say "I
don't care which path you take to proving this constraint". So if we have
instance C Int a
instance C b Int
and we try to solve (C Int Int) we should arbitrarily pick either. But we
OK, I ticket-ified this conversation, at some point I'll get around
to this.
Excerpts from Ian Lynagh's message of Sun Jul 21 03:25:50 -0700 2013:
> On Sat, Jul 20, 2013 at 11:26:10AM -0700, Edward Z. Yang wrote:
> > These tests have been doing better than expected in the nightlies
> > for some wh
16 matches
Mail list logo
