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

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@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 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@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 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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- -- Dan Burton

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe