Re: [Haskell-cafe] deepSeq vs rnf
Björn Bringert wrote: Cale Gibbard wrote: On 22/10/06, Chad Scherrer [EMAIL PROTECTED] wrote: Hi, I had posted this question a while back, but I think it was in the middle of another discussion, and I never did get a reply. Do we really need both Control.Parallel.Strategies.rnf and deepSeq? Should we not always have x `deepSeq` y == rnf x `seq` y ? Maybe there's a distinction I'm missing, but it seems to me they're basically the same. I agree, they are the same. The Strategies library also gives much more general operations for working with strictness and parallelisation. That library seems to need more love, I think it's a great idea, but it doesn't really get noticed all that much. The Hierarchical libraries documentation for it is a little lacking -- it doesn't even provide a reference or link to the paper, and many of the combinators, as well as the general idea of how to use it are undocumented from there. It also spuriously contains an Assoc datatype, which if I recall correctly, was an example from the paper, but doesn't really belong in the library as far as I can tell. It would also be really nice to see the list of instances for the NFData class expanded to include other datatypes in the libraries, possibly also with compiler support for deriving, since it's mostly boilerplate. I wanted to use the Strategies library and didn't understand much of it, so I sat down and documented it. The darcs version, http://darcs.haskell.org/packages/base/Control/Parallel/Strategies.hs has my changes. If noone objects, I could do some more clean-up, including: - Add NFData instances for common data types, such as - Maybe - Either - Data.Map.Map - Data.Set.Set - Data.Tree.Tree - All Data.Int and Data.Word types - Deprecate sSeq and sPar, as the code comments say that you should use demanding and sparking instead. - Deprecate these defintions, which seem to be examples or Lolita-specific: - Assoc - fstPairFstList - force - sforce If anyone has objections or further suggestions, let me know. Looks good to me. I didn't really look closely at this code before enabling it, except to check that it compiled and appeared to work with a couple of the old Parallel Haskell benchmarks in nofib/par. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepSeq vs rnf
Cale Gibbard wrote: On 22/10/06, Chad Scherrer [EMAIL PROTECTED] wrote: Hi, I had posted this question a while back, but I think it was in the middle of another discussion, and I never did get a reply. Do we really need both Control.Parallel.Strategies.rnf and deepSeq? Should we not always have x `deepSeq` y == rnf x `seq` y ? Maybe there's a distinction I'm missing, but it seems to me they're basically the same. I agree, they are the same. The Strategies library also gives much more general operations for working with strictness and parallelisation. That library seems to need more love, I think it's a great idea, but it doesn't really get noticed all that much. The Hierarchical libraries documentation for it is a little lacking -- it doesn't even provide a reference or link to the paper, and many of the combinators, as well as the general idea of how to use it are undocumented from there. It also spuriously contains an Assoc datatype, which if I recall correctly, was an example from the paper, but doesn't really belong in the library as far as I can tell. It would also be really nice to see the list of instances for the NFData class expanded to include other datatypes in the libraries, possibly also with compiler support for deriving, since it's mostly boilerplate. I wanted to use the Strategies library and didn't understand much of it, so I sat down and documented it. The darcs version, http://darcs.haskell.org/packages/base/Control/Parallel/Strategies.hs has my changes. If noone objects, I could do some more clean-up, including: - Add NFData instances for common data types, such as - Maybe - Either - Data.Map.Map - Data.Set.Set - Data.Tree.Tree - All Data.Int and Data.Word types - Deprecate sSeq and sPar, as the code comments say that you should use demanding and sparking instead. - Deprecate these defintions, which seem to be examples or Lolita-specific: - Assoc - fstPairFstList - force - sforce If anyone has objections or further suggestions, let me know. /Björn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] deepSeq vs rnf
Hello Cale, Monday, October 23, 2006, 7:19:14 AM, you wrote: Speaking of boilerplate and the scrapping thereof, Data.Generics could theoretically also be used to write a relatively generic rnf/deepSeq, but in my attempts, it seems to be much much slower than using a specific normal form class. Here's my code from quite a while back. As I recall, it's semantically correct, but ran about an order of magnitude slower. There might be a much better way to do it, I don't really know Data.Generics all that well. by no means it's surprising - syb library works slower than hand-written or compile-time generated code because it implements _run-time_ polymorphism - data types are tested at run-time and then coerced to their actual types. there is also syb4 approach by Oleg where type classes used for polymorphism - it should have average speed, in theory -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] deepSeq vs rnf
Hi, I had posted this question a while back, but I think it was in the middle of another discussion, and I never did get a reply. Do we really need both Control.Parallel.Strategies.rnf and deepSeq? Should we not always have x `deepSeq` y == rnf x `seq` y ? Maybe there's a distinction I'm missing, but it seems to me they're basically the same. -- Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepSeq vs rnf
On 22/10/06, Chad Scherrer [EMAIL PROTECTED] wrote: Hi, I had posted this question a while back, but I think it was in the middle of another discussion, and I never did get a reply. Do we really need both Control.Parallel.Strategies.rnf and deepSeq? Should we not always have x `deepSeq` y == rnf x `seq` y ? Maybe there's a distinction I'm missing, but it seems to me they're basically the same. I agree, they are the same. The Strategies library also gives much more general operations for working with strictness and parallelisation. That library seems to need more love, I think it's a great idea, but it doesn't really get noticed all that much. The Hierarchical libraries documentation for it is a little lacking -- it doesn't even provide a reference or link to the paper, and many of the combinators, as well as the general idea of how to use it are undocumented from there. It also spuriously contains an Assoc datatype, which if I recall correctly, was an example from the paper, but doesn't really belong in the library as far as I can tell. It would also be really nice to see the list of instances for the NFData class expanded to include other datatypes in the libraries, possibly also with compiler support for deriving, since it's mostly boilerplate. Speaking of boilerplate and the scrapping thereof, Data.Generics could theoretically also be used to write a relatively generic rnf/deepSeq, but in my attempts, it seems to be much much slower than using a specific normal form class. Here's my code from quite a while back. As I recall, it's semantically correct, but ran about an order of magnitude slower. There might be a much better way to do it, I don't really know Data.Generics all that well. rnf :: (Data a) = a - () rnf x = everything (\x y - x `seq` y) (\x - x `seq` ()) x deepSeq x y = rnf x `seq` y f $!! x = rnf x `seq` f x - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] deepSeq vs rnf
Interesting, I hadn't thought of the SYB approach. I still need to get through those papers. Actually, I wonder if this idea would help with something else I was looking into. It seems like it might occasionally be useful to have a monad that is the identity, except that it forces evaluation as it goes. Something like: instance Monad Strict where return = Strict Strict x = f = rnf x `seq` f x The problem is, this won't typecheck as-is, since not everything is an instance of class NFData. I had been thinking of making a default instance, something like instance NFData a where rnf = id and then using overlapping instances. But maybe boilerplate-scrapping would make this cleaner? I'm still not sure what it can and can't do. -Chad I agree, they are the same. The Strategies library also gives much more general operations for working with strictness and parallelisation. That library seems to need more love, I think it's a great idea, but it doesn't really get noticed all that much. The Hierarchical libraries documentation for it is a little lacking -- it doesn't even provide a reference or link to the paper, and many of the combinators, as well as the general idea of how to use it are undocumented from there. It also spuriously contains an Assoc datatype, which if I recall correctly, was an example from the paper, but doesn't really belong in the library as far as I can tell. It would also be really nice to see the list of instances for the NFData class expanded to include other datatypes in the libraries, possibly also with compiler support for deriving, since it's mostly boilerplate. Speaking of boilerplate and the scrapping thereof, Data.Generics could theoretically also be used to write a relatively generic rnf/deepSeq, but in my attempts, it seems to be much much slower than using a specific normal form class. Here's my code from quite a while back. As I recall, it's semantically correct, but ran about an order of magnitude slower. There might be a much better way to do it, I don't really know Data.Generics all that well. rnf :: (Data a) = a - () rnf x = everything (\x y - x `seq` y) (\x - x `seq` ()) x deepSeq x y = rnf x `seq` y f $!! x = rnf x `seq` f x - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] deepSeq vs. rnf?
Now and again I see references to deepSeq, and I've never understood how this could be any different than using rnf from Control.Parallel.Strategies. Is there really any difference? When is it better to use one or the other? Thanks, -- Chad Scherrer Time flies like an arrow; fruit flies like a banana -- Groucho Marx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
