On Dec 15, 9:30 pm, Daniel Fischer <[email protected]> wrote: > Am Dienstag 15 Dezember 2009 19:30:06 schrieb Maciej Piechotka: > > > > > On Tue, 2009-12-15 at 09:52 -0800, Johann Höchtl wrote: > > > Hello, > > > > I'm still to Haskell, and after I read through > > >http://users.aber.ac.uk/afc/stricthaskell.html#seq > > > > I thought, that these tow fragments after term rewriting are really > > > the same: > > > > myLength :: [a] -> Integer > > > myLength xs = len xs 0 > > > where len [] l = l > > > len (x:xs) l = l `seq` len xs (l+1) > > > > main = print $ myLength [1..10000000] > > > > -- vs. > > > > myLength :: [a] -> Integer > > > myLength xs = len xs 0 > > > where len [] l = l > > > len (x:xs) l = len xs $! (l+1) > > > > main = print $ myLength [1..10000000] > > > > main = print $ myLength [1..10000000] > > > > But the first expression evaluates more then twice as fast as the > > > second one. Tested on GHC 6.10.4 and Windows XP, dual core (for what > > > it's worth) > > Is that > a) interpreted > b) compiled without optimisations > c) compiled with optimisations > ? > It's b, compiled without optimisations. Of what I understand from the explanations so far, the first solution with seq should acutally be slower; In the unoptimised case it's more than two times faster than the version len (x:xs) l = len xs $! (l+1)
> If c), that's a serious bug. With optimisations turned on, both should give > (approximately) identical code, the same as with "len (x:xs) l = len xs > (l+1)". > With -O2, that gives exactly the same core as the first, the second has one > (unnecesary, > because everything is recognized as strict) case expression in otherwise > identical core. > All three perform identically here. > > If a) or b), it's because the second has one more function call per list > element, first > ($!) is called and then seq via that, while the first calls seq directly. > > > Ah, ok, I was not aware that this is realy a function call. I thought this is syntactic sugar only and would be rewritten into a call to `seq`. I think to much of a macro in this case. > > > > > It's onhttp://moonpatio.com/fastcgi/hpaste.fcgi/view?id=5321#a5321 > > > btw. > > > > I can't see the difference, especially as $! is expressed in terms of > > > seq > > > The second one is IMGO: > > myLength :: [a] -> Integer > > myLength xs = len xs 0 > > where len [] l = l > > len (x:xs) l = let l' = l+1 > > in l' `seq` len xs l' > > > So in thew first + is not forced to be evaluated. > > > My results (ghc 6.12.1, Core 2 Duo 2.8 GHz, Linux 2.6.32, Gentoo): > > > Not Optimized & not compiled: > > First: 12.47 secs, 1530911440 bytes > > Second: 17.40 secs, 1929614816 bytes > > Wow. Here, interpreted and not optimised: > First: 10.10 secs (Integer) 10.45 secs (Int) > Second: 11.80 secs (Integer) 11.93 secs (Int) > > ghc 6.12.1, built from source, 3GHz Pentium 4 (2 Cores), Linux linux-mkk1 > 2.6.27.39-0.2- > pae (openSuse 11.1) > > With ghci-6.10.3 > First: 14.58 secs (Integer) 14.53 secs (Int) > Second: 17.05 secs (Integer) 18.31 secs (Int) > > Nowhere near the difference that you have. > > > Optimized & compiled: > > First: 1.24 secs, 966280832 bytes > > Second: 1.11 secs, 966277152 bytes > > Compiled with -O (same with -O2) > First: 0.36 secs (Integer) 0.30 secs (Int) > Second: 0.36 secs (Integer) 0.30 secs (Int) > length: 0.32 secs > > Astonishing that compiling does so much less on your box. > > With ghc-6.10.3 (-O/-O2) > First: 0.23 secs (Integer) 0.17 secs (Int) > Second: 0.26 secs (Integer) 0.17 secs (Int) > length: 0.19 secs > > Ouch! Why is 6.10.3 so much better here? > > Compiled without optimisations > First: 0.48 secs (Integer) 0.49 secs (Int) > Second: 1.07 secs (Integer) 1.01 secs (Int) > > With 6.10.3 > First: 0.38 secs (Integer) 0.36 secs (Int) > Second: 1.47 secs (Integer) 1.46 secs (Int) > > Wait, what? > > _______________________________________________ > Haskell-Cafe mailing list > [email protected]http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
