[Haskell-cafe] [GHC 7.8.4] IO Monad leak space?

[Baojun Wang]

My concerns is ~80% alloc happens in f3, but both array is allocated by
newArray? Since I'm using unboxed array I'm not expecting this kind of
laziness.

And the speed of local go (loopM_ equivalent) > loopM_ > mapM_ really
surprised me, even profiling is turned off.
On Fri, Jul 3, 2015 at 10:27 AM Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:

> I see... ok, it's interesting, but seems to require a long time of
> studying just to understand it. ^^
>
> I am looking for something to solve computer science's complexity problem.
> I believe we should have simple structures at every level, from high-level
> to low-level.
>
> btw I am redefining the levels like this:
>
> Top-level: Your thoughts
> Medium level: Shortened pseudo-code
> Low level: A formerly called "high-level" language like Haskell or Java
>
> So we're then two levels higher than before. ^^
>
> Cheers
>
> On Fri, Jul 3, 2015 at 7:19 PM, Dan Burton <danburton.email at gmail.com>
> wrote:
>
>> It can, if you know the correct magic incantations to give ghc (which I
>> don't, but I know the knowledge is out there). The phrase to Google is
>> "reading ghc core", where "core" refers to an intermediate language that
>> still resembles Haskell.
>>
>>
>> On Friday, July 3, 2015, Stefan Reich <
>> stefan.reich.maker.of.eye at googlemail.com> wrote:
>>
>>> Here's a general question: Can the output of the Haskell compiler be
>>> inspected in some - readable - way?
>>>
>>> Stefan
>>>
>>> On Fri, Jul 3, 2015 at 10:18 AM, Baojun Wang <wangbj at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> First of all, I found it interesting that
>>>>
>>>> loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s)
>>>>
>>>> loopM_ seems faster than mapM_    ( mapM_ f [k, k+s..n]))
>>>>
>>>> I think mapM_ is used very commonly, why it's performance is even lower
>>>> than a hand-written loop function?
>>>>
>>>> 2nd, even I replace mapM_ with loopM_ from above, when chain IO action,
>>>> it still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s''
>>>> updated so that I/O actions can be done in-order? )
>>>>
>>>> Consider below function:
>>>>
>>>> f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO ()
>>>> f3 u r i = let !v = u ! i
>>>>             in go (f31 v) i i
>>>>   where f31 v j = readArray r j >>= \v1 ->
>>>>           writeArray r j (v1 + (fromIntegral i) * (fromIntegral v))
>>>>         f31 :: Int -> Int -> IO ()
>>>>         go g k s = when (k <= maxn) (
>>>>           g k >> go g (s+k) s )
>>>>
>>>> When call f3:
>>>>
>>>>   loopM_ (f3 uu res) 1 1 1000000
>>>>
>>>> Which will have blow profiling output:
>>>>
>>>> individual inherited
>>>> COST CENTRE MODULE no. entries %time %alloc %time %alloc
>>>>
>>>>
>>>> ...
>>>> loopM_ Main 104 4000002 7.4 10.1 100.0 99.3
>>>> f3 Main 113 1000000 1.0 2.0 70.2 69.1
>>>> f3.go Main 116 14970034 32.7 67.1 68.8 67.1
>>>> f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0
>>>> f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0
>>>> f3.f31 Main 114 0 0.3 0.0 0.4 0.0
>>>> f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0
>>>> ...
>>>> Why f3.go consumes so much space (67.1%)? The only reason I can think
>>>> of is IO Monad chain (>>) isn't space free as I thought.
>>>>
>>>> Did I get something fundamentally wrong?
>>>>
>>>> Thanks
>>>> baojun
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>
>>
>> --
>> -- Dan Burton
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150703/9a016f9f/attachment.html>