Re: Reducing the cost of garbage collecting small arrays
On Thu, Jun 23, 2011 at 12:31 AM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: On Wed, Jun 22, 2011 at 12:33 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi, Now when we can efficiently copy small arrays I've gone back to benchmarking/optimizing my hash array mapped trie data structure. The data structure's performance depends on how efficiently we can allocate/collect/copy Array#s and MutableArrays#s of size =32. Speeding up copying helped quite a bit, but the HAMT is still slower than a Patricia tree for inserts. Is 5 the optimal number of bits to slice off at a time (ie the best fanout)? It sounds like node copy cost on insert argues for a slightly narrower fanout. You'll be evacuating / scanning more words total, but new nodes may equate to less scanning overall (especially if this is running long enough to have some nodes get tenure). I'm experimenting with this. 6 is far too much, making inserts 4-5x slower. 4 doesn't seem to improve things much (which is a bit counter-intuitive given that 6 made things so much work), but I need to experiment some more. Cheers, Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Type function under a forall type
Dimitrios and I don't think there is a fundamental difficulty here, but it involves some work on the constraint solver that we have not yet done, especially concerning the evidence that is constructed for a proof. So it's on the list, but currently not very high priority. Yell if it's important to you. There is a ticket about it: http://hackage.haskell.org/trac/ghc/ticket/4310, so add yourself to the cc list if you care about it. Simon | -Original Message- | From: Stefan Holdermans [mailto:ste...@vectorfabrics.com] | Sent: 21 June 2011 10:51 | To: Simon Peyton-Jones; Tom Schrijvers | Cc: glasgow-haskell-users@haskell.org | Subject: Type function under a forall type | | Simon, Tom, | | I hit this type-error message in GHC 7.0.3: | | Cannot deal with a type function under a forall type: | forall e. El e u | | Is there a fundamental reason why type functions under a forall type are a bad idea? | Of is it just something that hasn't been implemented/thought about yet? | | Cheers, | | Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Reducing the cost of garbage collecting small arrays
On Thu, Jun 23, 2011 at 8:27 AM, Johan Tibell johan.tib...@gmail.com wrote: Is 5 the optimal number of bits to slice off at a time (ie the best fanout)? It sounds like node copy cost on insert argues for a slightly narrower fanout. You'll be evacuating / scanning more words total, but new nodes may equate to less scanning overall (especially if this is running long enough to have some nodes get tenure). I'm experimenting with this. 6 is far too much, making inserts 4-5x slower. 4 doesn't seem to improve things much (which is a bit counter-intuitive given that 6 made things so much work), but I need to experiment some more. After some more testing I can improve the performance of insert by 30% by reducing the array size from 32 to 16. GC still dominates though. Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [GHC] #5051: Typechecker behaviour change
Simon, thank you. Currently, DoCon works under ghc-7.0.1. And as I understand, the next release which is going to support DoCon (with its heavy use of overlapping instances) will be ghc-7.2. Regards, Serge Mechveliani, mech...@botik.ru On Wed, Jun 22, 2011 at 11:01:53AM -, GHC wrote: #5051: Typechecker behaviour change ---+ Reporter: igloo | Owner: simonpj Type: bug | Status: closed Priority: high | Milestone: 7.2.1 Component: Compiler |Version: 7.0.2 Resolution: fixed | Keywords: [..] GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather subtle interaction of overlapping instances with the ill-fated silent superclass parameters I introduced to solve a problem in the typechecker's constraint solver. [..] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: [GHC] #5051: Typechecker behaviour change
I believe that's right. Simon | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Serge D. Mechveliani | Sent: 23 June 2011 11:03 | To: glasgow-haskell-b...@haskell.org | Cc: glasgow-haskell-users@haskell.org | Subject: Re: [GHC] #5051: Typechecker behaviour change | | Simon, | thank you. | | Currently, DoCon works under ghc-7.0.1. | And as I understand, the next release which is going to support DoCon | (with its heavy use of overlapping instances) will be ghc-7.2. | | Regards, | | Serge Mechveliani, mech...@botik.ru | | | On Wed, Jun 22, 2011 at 11:01:53AM -, GHC wrote: | #5051: Typechecker behaviour change | ---+ |Reporter: igloo | Owner: simonpj |Type: bug | Status: closed |Priority: high | Milestone: 7.2.1 | Component: Compiler |Version: 7.0.2 | Resolution: fixed | Keywords: | | [..] | | GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather | subtle interaction of overlapping instances with the ill-fated silent | superclass parameters I introduced to solve a problem in the | typechecker's constraint solver. | [..] | | ___ | Glasgow-haskell-bugs mailing list | glasgow-haskell-b...@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Reducing the cost of garbage collecting small arrays
On Thu, Jun 23, 2011 at 4:54 AM, Johan Tibell johan.tib...@gmail.com wrote: On Thu, Jun 23, 2011 at 8:27 AM, Johan Tibell johan.tib...@gmail.com wrote: Is 5 the optimal number of bits to slice off at a time (ie the best fanout)? It sounds like node copy cost on insert argues for a slightly narrower fanout. You'll be evacuating / scanning more words total, but new nodes may equate to less scanning overall (especially if this is running long enough to have some nodes get tenure). I'm experimenting with this. 6 is far too much, making inserts 4-5x slower. 4 doesn't seem to improve things much (which is a bit counter-intuitive given that 6 made things so much work), but I need to experiment some more. After some more testing I can improve the performance of insert by 30% by reducing the array size from 32 to 16. GC still dominates though. Yes, I'd still expect that; internal node churn with fat nodes exhausts heap more quickly than usual. If large nodes become the norm, cranking up GC nursery size might be in order. It's great to see that fat nodes finally work well in GHC, though. When I first tried this in the 90's it was so bad (due to the extra level of indirection write barrier problems) I gave up in frustration. -Jan Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Reducing the cost of garbage collecting small arrays
On Thu, Jun 23, 2011 at 3:27 PM, Jan-Willem Maessen jmaes...@alum.mit.edu wrote: Yes, I'd still expect that; internal node churn with fat nodes exhausts heap more quickly than usual. If large nodes become the norm, cranking up GC nursery size might be in order. It's great to see that fat nodes finally work well in GHC, though. When I first tried this in the 90's it was so bad (due to the extra level of indirection write barrier problems) I gave up in frustration. I just tested reducing the fanout to 8, which actually makes things slower. Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hoopl: Examples of wrapFR or wrapBR?
Can someone provide an example of how to use wrapFR/wrapBR? I know they are deprecated, but I would really like to see them in action if they are used anywhere at all ... Thanks so much! Justin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Superclass equalities
On 22/06/2011 17:57, Simon Peyton-Jones wrote:
I have long advertised a plan to allow so-called superclass equalities. I've
just pushed patches to implement them. So now you can write
class (F a ~ b) = C a b where { ... }
That is fantastic. I have a question about this feature as compared to the two
methods used to define the TypeCast superclass equality constraint in HList.
Can (~) replace all uses of TypeCast? If not, then can (~) help define TypeCast
in a better way? The two existing ways are a bit fragile.
I will put the TypeCast definitions below so readers of this question need not
go digging. I just refreshed my understanding of TypeCast by re-reading
appendix D of the extended technical report for HList at [1,2].
The class TypeCast should only have instances when x and y are unified:
class TypeCast x y | x - y, y - x where typeCast :: x - y
The first definition for TypeCast is simply
instance TypeCast x x where typeCast = id
But this was fragile since the class and instance have to be kept apart and the
instance has be imported carefully. Quoting [2]:
To keep the compiler from applying the type simplification rule too early, we
should prevent the early inference of the rule from the instance of TypeCast
in the first place. For example, we may keep the compiler from seeing the
instance TypeCast x x until the very end. That is, we place that instance in
a separate module and import it at a higher level in the module hierarchy
than all clients of the class TypeCast.
The second definition of TypeCast can be included normally but is quite curious
looking:
class TypeCast a b | a - b, b-a where typeCast :: a - b
class TypeCast' t a b | t a - b, t b - a where typeCast' :: t-a-b
class TypeCast'' t a b | t a - b, t b - a where typeCast'' :: t-a-b
instance TypeCast' () a b = TypeCast a b where typeCast x = typeCast' () x
instance TypeCast'' t a b = TypeCast' t a b where typeCast' = typeCast''
instance TypeCast'' () a a where typeCast'' _ x = x
The HList authors follow this definition in [2] with:
While this code works in GHC and is logically sound, we have to admit that
we turned the drawbacks of the type-checker to our advantage. This leaves a
sour after-taste. We would have preferred to rely on a sound semantic theory
of overloading rather than on playing games with the type-checker. Hopefully,
the results of the foundational work by Sulzmann and others [32, 23] will
eventually be implemented in all Haskell compilers.
[1] Page: http://homepages.cwi.nl/~ralf/HList/
[2] Pdf: http://homepages.cwi.nl/~ralf/HList/paper.pdf
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
