Comments on: Learning Haskell and Number Theory: The End of GCD http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/ software, programming languages, and other ideas Fri, 13 Nov 2009 13:07:15 +0000 http://wordpress.com/ hourly 1 By: Don Stewart http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-103 Don Stewart Sat, 07 Jul 2007 04:56:50 +0000 http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-103 See <a href="http://haskell.org/haskellwiki/GCD_inlining_strictness_and_CSE" rel="nofollow">http://haskell.org/haskellwiki/GCD_inlining_strictness_and_CSE</a> for an analysis of how CSE, strictness, inlining and specialisation interact to get the best code from this example. :-) See http://haskell.org/haskellwiki/GCD_inlining_strictness_and_CSE for an analysis of how CSE, strictness, inlining and specialisation interact to get the best code from this example. :-)

]]> By: Cale Gibbard http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-101 Cale Gibbard Sat, 07 Jul 2007 04:30:03 +0000 http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-101 While your solution with "(gcd1 p x) `seq` gcdmany' (gcd1 p x) xs" will work to stop the stack overflow, it will also cause GHC to evaluate gcd1 twice as many times. GHC is *not* going to do CSE here -- it only does a particularly trivial form of CSE that this isn't covered by. The reason that it causes the stack not to overflow is that evaluating that gcd1 will inadvertently force the evaluation of p (supposing that your number type is strict), like the bang patterns do, but at a far greater expense. You'll effectively cut the number of times gcd1 runs in half by forcing it to share, using the "let g = gcd1 p x in g `seq` gcdmany' g xs" variant. To see this, try profiling the code and looking at what happens to the "entries" column when you make the change. While your solution with “(gcd1 p x) `seq` gcdmany’ (gcd1 p x) xs” will work to stop the stack overflow, it will also cause GHC to evaluate gcd1 twice as many times. GHC is *not* going to do CSE here — it only does a particularly trivial form of CSE that this isn’t covered by. The reason that it causes the stack not to overflow is that evaluating that gcd1 will inadvertently force the evaluation of p (supposing that your number type is strict), like the bang patterns do, but at a far greater expense.

You’ll effectively cut the number of times gcd1 runs in half by forcing it to share, using the “let g = gcd1 p x in g `seq` gcdmany’ g xs” variant.

To see this, try profiling the code and looking at what happens to the “entries” column when you make the change.

]]> By: cdsmith http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-99 cdsmith Fri, 06 Jul 2007 18:59:32 +0000 http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-99 Paul, at least with GHC 6.6 and GHC 6.7 latest development version, the seq works as shown in the article. At least on [1 .. 1000000], gcdmany fails with a stack overflow without the seq, and succeeds with it. I'd be interested if you have a source for the need to use a let binding, but it doesn't match what I see. Paul, at least with GHC 6.6 and GHC 6.7 latest development version, the seq works as shown in the article. At least on [1 .. 1000000], gcdmany fails with a stack overflow without the seq, and succeeds with it. I’d be interested if you have a source for the need to use a let binding, but it doesn’t match what I see.

]]> By: sorear http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-98 sorear Fri, 06 Jul 2007 16:07:05 +0000 http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-98 There is a third possibility: Adding seqs can make your program vastly slower and use vastly more memory. After all - laziness is usually a good thing! rot13 ch | ch >= 'a' && ch = 'n' && ch = 'A' && ch = 'N' && ch There is a third possibility: Adding seqs can make your program vastly slower and use vastly more memory. After all – laziness is usually a good thing!

rot13 ch
| ch >= ‘a’ && ch = ‘n’ && ch = ‘A’ && ch = ‘N’ && ch

]]> By: Paul Johnson http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-94 Paul Johnson Fri, 06 Jul 2007 08:19:37 +0000 http://cdsmith.wordpress.com/2007/07/05/learning-haskell-and-number-theory-the-end-of-gcd/#comment-94 (gcd1 p x) `seq` gcdmany’ (gcd1 p x) xs As I understand it GHC doesn't do common subexpression elimination. So surely this will compute (gcd1 p x) eagerly, then throw away the result and do it again lazily. What you would need to do is more like: let g = gcd1 p x in g `seq` gcdmany’ g xs But I may have misunderstood. Paul (gcd1 p x) `seq` gcdmany’ (gcd1 p x) xs

As I understand it GHC doesn’t do common subexpression elimination. So surely this will compute (gcd1 p x) eagerly, then throw away the result and do it again lazily.

What you would need to do is more like:

let g = gcd1 p x in g `seq` gcdmany’ g xs

But I may have misunderstood.

Paul

]]>