Re: Haskell-Cafe Digest, Vol 39, Issue 6

Lemmih wrote:
Using 'seq' is generally a bad idea. It can worsen the performance if not used carefully and GHCs strictness analyser is usually good enough.
Is GHC.Conc.pseq any better? Usually the whole point of making things more strict is to optimize performance for pieces you know will be evaluated anyway. It's frustrating if there's not a consistent way to do this that works well. Lately, I've been using lots of strictness annotations and bang patterns - are there non-obvious places this could slow things down? Would it be possible for the type system to distinguish at compile time whether something would need to be evaluated, and optimize away redundant `seq`s? Maybe this is what the strictness analyzer does already. Chad

Hello Chad, Thursday, November 2, 2006, 8:49:17 PM, you wrote:
Would it be possible for the type system to distinguish at compile time whether something would need to be evaluated, and optimize away redundant `seq`s? Maybe this is what the strictness analyzer does already.
afaik, seq cost is zero (except for evaluating expressions, of course) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 11/2/06, Chad Scherrer
Lemmih wrote:
Using 'seq' is generally a bad idea. It can worsen the performance if not used carefully and GHCs strictness analyser is usually good enough.
Is GHC.Conc.pseq any better? Usually the whole point of making things more strict is to optimize performance for pieces you know will be evaluated anyway. It's frustrating if there's not a consistent way to do this that works well.
pseq is just as bad. The problem is excessive use of strictness annotations in the hope of a magical performance improvement. Strictness annotations should be used with care and only placed where they're needed.
Lately, I've been using lots of strictness annotations and bang patterns - are there non-obvious places this could slow things down?
In the case of the MersenneTwister, forcing 'y4' from 'next32' would evaluate it almost 10,000,000 times more than needed.
Would it be possible for the type system to distinguish at compile time whether something would need to be evaluated, and optimize away redundant `seq`s? Maybe this is what the strictness analyzer does already.
Evaluating the seq's isn't costly, afaik. -- Cheers, Lemmih

On Sat, Nov 04, 2006 at 17:22:31 +0100, Lemmih wrote: [..]
pseq is just as bad. The problem is excessive use of strictness annotations in the hope of a magical performance improvement. Strictness annotations should be used with care and only placed where they're needed.
Premature annotations for strictness is the root of all evil? :-) How do one find "good" places to use strictness annotations? (Is using a profiler the answer, just like it's the answer for manual optimisation in non-lazy languages?) Oh, just in case you didn't guess it already, I'm a Haskell n00b who has yet to achieve enlightenment... /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus Software is not manufactured, it is something you write and publish. Keep Europe free from software patents, we do not want censorship by patent law on written works. "And wow! Hey! What's this thing coming towards me very fast? Very very fast. So big and flat and round, it needs a big wide sounding word like... ow... ound... round... ground! That's it! That's a good name - ground! I wonder if it will be friends with me?" -- For the sperm whale, it wasn't.

Hello Magnus, Monday, November 6, 2006, 1:08:44 PM, you wrote:
How do one find "good" places to use strictness annotations? (Is using a profiler the answer, just like it's the answer for manual optimisation in non-lazy languages?)
the only way i know is to plug & pray :) btw, a few weeks ago Andrea Rosatto has memory leak problem and we (especially me :) tried to explain devil in details. look in archives, this may be very useful -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (4)
-
Bulat Ziganshin
-
Chad Scherrer
-
Lemmih
-
Magnus Therning