Hi
I didn't say I agree, I most certainly don't. What I meant with my
comment was that a slowdown of 10x, just to preserve laziness, is
perfect fuel for those who claim that laziness is good in theory but
bad in practice.
A bad implementation of laziness will always be slower than a bad
| 1) Why is the Prelude mapM so slow? It seems like running 10x slower
| than mapM_ when generating only 50,000 return values is a problem.
All this does seem odd. I've submitted a ticket so we don't forget it
http://hackage.haskell.org/trac/ghc/ticket/2236
It appears to be some bad (possibly
2008/4/25, Niklas Broberg [EMAIL PROTECTED]:
Wow. A 10x slowdown for a very commonly used function that in 99.8% of
all use cases has no need for the extra laziness at all. No wonder
some people say Haskell is a toy language...
A toy language that is still much faster than many currently
Wow. A 10x slowdown for a very commonly used function that in 99.8% of
all use cases has no need for the extra laziness at all. No wonder
some people say Haskell is a toy language...
A toy language that is still much faster than many currently popular
languages so... Is
Hello Luke and other Haskellers,
Thanks for the reply, but as I noted before, the amount of memory
allocated (and resident) is roughly the same. Anyhow it's definitely
not a GC issue because I wrote an accumulating version of mapM and got
close to mapM_ 's performance.
In the code below, main1
Hello Ben,
Friday, April 25, 2008, 1:14:17 AM, you wrote:
mapM2 :: Monad m = (a - m b) - [a] - m [b]
{-# INLINE mapM2 #-}
mapM2 fn lst = mapM2accum fn lst []
where mapM2accum _ [] accum = return accum
mapM2accum fn (x:xs) accum = do
r - fn x
mapM2accum
Hi Ben,
mapM2 :: Monad m = (a - m b) - [a] - m [b]
{-# INLINE mapM2 #-}
mapM2 fn lst = mapM2accum fn lst []
where mapM2accum _ [] accum = return accum
mapM2accum fn (x:xs) accum = do
r - fn x
mapM2accum fn xs (r:accum)
Not that it should matter for
Hello Niklas,
Friday, April 25, 2008, 1:25:39 AM, you wrote:
Not that it should matter for performance any, but you really ought to
reverse the result list too, or compute the accumulator in the right
order. :-)
unfortunately, this affects performance too. reverse costs one more scan
through
On the test case i'm running the performance impacts of reversing the
return list are negligible:
mapM3 :: Monad m = (a - m b) - [a] - m [b]
{-# INLINE mapM3 #-}
mapM3 fn lst = mapM3accum fn lst []
where mapM3accum _ [] accum = return $ reverse accum
mapM3accum fn (x:xs) accum = do
On Thu, Apr 24, 2008 at 11:28 PM, Ben [EMAIL PROTECTED] wrote:
2) Is there a reason to not use mapM3 above?
Yes, there certainly is. mapM3 is not equivalent to mapM; it is too strict:
*Main take 3 $ head $ mapM return [1,2,3,4,undefined]
[1,2,3]
*Main take 3 $ head $ mapM3 return
Luke,
Thanks for the nice answer. So maybe I'll give mapM3 the name mapM'
and put it in my personal library.
But I'm still a bit curious about the performance profile of mapM.
The profiler is telling me they're allocating around the same amount
of memory, so I am not clear what is making it
On Fri, Apr 25, 2008 at 12:02 AM, Ben [EMAIL PROTECTED] wrote:
Luke,
Thanks for the nice answer. So maybe I'll give mapM3 the name mapM'
and put it in my personal library.
Except the answer was wrong. I forgot the reverse in my
implementation, so that undefined we were seeing was just the
2) Is there a reason to not use mapM3 above?
Yes, there certainly is. mapM3 is not equivalent to mapM; it is too strict:
*Main take 3 $ head $ mapM return [1,2,3,4,undefined]
[1,2,3]
*Main take 3 $ head $ mapM3 return [1,2,3,4,undefined]
[*** Exception: Prelude.undefined
So,
niklas.broberg:
2) Is there a reason to not use mapM3 above?
Yes, there certainly is. mapM3 is not equivalent to mapM; it is too strict:
*Main take 3 $ head $ mapM return [1,2,3,4,undefined]
[1,2,3]
*Main take 3 $ head $ mapM3 return [1,2,3,4,undefined]
[*** Exception:
14 matches
Mail list logo
