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 <danburton.email@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@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@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@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