(Sorry for the double post)<br>A good practice would be to always factorize your list treatments [*] (using a single fold to compute in the same time max & min), and be sure never to keep a plain reference to the list and embed that list into a function that returns it (to enforce its evaluation each time you need to access it).<br>
But I can't think of a way to check that property (list never accessed twice) statically in Haskell.<br><br>[*] But wouldn't GHC do in that specific case do something about that with -O2 activated?<br><br><div class="gmail_quote">
2012/3/10 Yves Parès <span dir="ltr"><<a href="mailto:yves.pares@gmail.com">yves.pares@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm afraid without uniqueness or linear typing it would be hard to avoid.<div class="HOEnZb">
<div class="h5"><br><br><div class="gmail_quote">2012/3/10 Thiago Negri <span dir="ltr"><<a href="mailto:evohunz@gmail.com" target="_blank">evohunz@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see. Thanks for the answers.<br>
<br>
Any data structure or source annotation that would prevent that?<br>
<br>
For example, if I try the same program to run on a<br>
[1..9999999999999999] list, I'll get an out of memory error for the<br>
single-threaded version. Any way to prevent it without declaring two<br>
different versions of "list"?<br>
<br>
<br>
2012/3/10 Anthony Cowley <<a href="mailto:acowley@gmail.com" target="_blank">acowley@gmail.com</a>>:<br>
<div><div>> From that profiling data, I think you're just seeing a decrease in sharing. With one thread, you create the list structure in memory: the first fold could consume it in-place, but the second fold is still waiting for its turn. The list is built on the heap so the two folds can both refer to the same list.<br>
><br>
> With two threads, GHC is being clever and inlining the definition you give for list, which is then optimized into two parallel loops. No list on the heap means there's not much for the GC to do.<br>
><br>
> Sharing of index lists like this is a common source of problems. In particular, nested loops can make it even trickier to prevent sharing as there may not be an opportunity for parallel evaluation.<br>
><br>
> Anthony<br>
><br>
> On Mar 10, 2012, at 10:21 AM, Thiago Negri <<a href="mailto:evohunz@gmail.com" target="_blank">evohunz@gmail.com</a>> wrote:<br>
><br>
>> Hi all.<br>
>><br>
>> I wrote a very simple program to try out parallel Haskel and check how<br>
>> it would look like to make use of more than one core in this language.<br>
>><br>
>> When I tried the program with RTS option -N1, total time shows it took<br>
>> 2.48 seconds to complete and around 65% of that time was taken by GC.<br>
>><br>
>> Then I tried the same program with RTS options -N2 and total time<br>
>> decreased to 1.15 seconds as I expected a gain here. But what I didn't<br>
>> expect is the GC time to drop to 0%.<br>
>><br>
>> I guess I'm having trouble to understand the output of the RTS option -s.<br>
>> Can you enlighten me?<br>
>><br>
>><br>
>> The source for the testing program:<br>
>><br>
>>> module Main where<br>
>>><br>
>>> import Data.List (foldl1')<br>
>>> import Control.Parallel (par, pseq)<br>
>>> import Control.Arrow ((&&&))<br>
>>><br>
>>> f `parApp` (a, b) = a `par` (b `pseq` (f a b))<br>
>>> seqApp = uncurry<br>
>>><br>
>>> main = print result<br>
>>> where result = (+) `parApp` minMax list<br>
>>> minMax = minlist &&& maxlist<br>
>>> minlist = foldl1' min<br>
>>> maxlist = foldl1' max<br>
>>> list = [1..19999999]<br>
>><br>
>><br>
>> The results on a Windows 7 64bits with an Intel Core 2 Duo, compiled<br>
>> with GHC from Haskell Platform:<br>
>><br>
>> c:\tmp\hs>par +RTS -s -N1<br>
>> par +RTS -s -N1<br>
>> 20000000<br>
>> 803,186,152 bytes allocated in the heap<br>
>> 859,916,960 bytes copied during GC<br>
>> 233,465,740 bytes maximum residency (10 sample(s))<br>
>> 30,065,860 bytes maximum slop<br>
>> 483 MB total memory in use (0 MB lost due to fragmentation)<br>
>><br>
>> Generation 0: 1523 collections, 0 parallel, 0.80s, 0.75s elapsed<br>
>> Generation 1: 10 collections, 0 parallel, 0.83s, 0.99s elapsed<br>
>><br>
>> Parallel GC work balance: nan (0 / 0, ideal 1)<br>
>><br>
>> MUT time (elapsed) GC time (elapsed)<br>
>> Task 0 (worker) : 0.00s ( 0.90s) 0.00s ( 0.06s)<br>
>> Task 1 (worker) : 0.00s ( 0.90s) 0.00s ( 0.00s)<br>
>> Task 2 (bound) : 0.86s ( 0.90s) 1.62s ( 1.69s)<br>
>><br>
>> SPARKS: 1 (0 converted, 0 pruned)<br>
>><br>
>> INIT time 0.00s ( 0.00s elapsed)<br>
>> MUT time 0.86s ( 0.90s elapsed)<br>
>> GC time 1.62s ( 1.74s elapsed)<br>
>> EXIT time 0.00s ( 0.00s elapsed)<br>
>> Total time 2.48s ( 2.65s elapsed)<br>
>><br>
>> %GC time 65.4% (65.9% elapsed)<br>
>><br>
>> Alloc rate 936,110,032 bytes per MUT second<br>
>><br>
>> Productivity 34.6% of total user, 32.4% of total elapsed<br>
>><br>
>> gc_alloc_block_sync: 0<br>
>> whitehole_spin: 0<br>
>> gen[0].sync_large_objects: 0<br>
>> gen[1].sync_large_objects: 0<br>
>><br>
>><br>
>> c:\tmp\hs>par +RTS -s -N2<br>
>> par +RTS -s -N2<br>
>> 20000000<br>
>> 1,606,279,644 bytes allocated in the heap<br>
>> 74,924 bytes copied during GC<br>
>> 28,340 bytes maximum residency (1 sample(s))<br>
>> 29,004 bytes maximum slop<br>
>> 2 MB total memory in use (0 MB lost due to fragmentation)<br>
>><br>
>> Generation 0: 1566 collections, 1565 parallel, 0.00s, 0.01s elapsed<br>
>> Generation 1: 1 collections, 1 parallel, 0.00s, 0.00s elapsed<br>
>><br>
>> Parallel GC work balance: 1.78 (15495 / 8703, ideal 2)<br>
>><br>
>> MUT time (elapsed) GC time (elapsed)<br>
>> Task 0 (worker) : 0.00s ( 0.59s) 0.00s ( 0.00s)<br>
>> Task 1 (worker) : 0.58s ( 0.59s) 0.00s ( 0.01s)<br>
>> Task 2 (bound) : 0.58s ( 0.59s) 0.00s ( 0.00s)<br>
>> Task 3 (worker) : 0.00s ( 0.59s) 0.00s ( 0.00s)<br>
>><br>
>> SPARKS: 1 (1 converted, 0 pruned)<br>
>><br>
>> INIT time 0.00s ( 0.00s elapsed)<br>
>> MUT time 1.15s ( 0.59s elapsed)<br>
>> GC time 0.00s ( 0.01s elapsed)<br>
>> EXIT time 0.00s ( 0.00s elapsed)<br>
>> Total time 1.15s ( 0.61s elapsed)<br>
>><br>
>> %GC time 0.0% (2.4% elapsed)<br>
>><br>
>> Alloc rate 1,391,432,695 bytes per MUT second<br>
>><br>
>> Productivity 100.0% of total user, 190.3% of total elapsed<br>
>><br>
>> gc_alloc_block_sync: 90<br>
>> whitehole_spin: 0<br>
>> gen[0].sync_large_objects: 0<br>
>> gen[1].sync_large_objects: 0<br>
>><br>
>> _______________________________________________<br>
>> Haskell-Cafe mailing list<br>
>> <a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
>> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>