On 03/10/2012 07:50 PM, Thiago Negri wrote:
I see. Thanks for the answers.
Any data structure or source annotation that would prevent that?
For example, if I try the same program to run on a
[1..] list, I'll get an out of memory error for the
single-threaded version. Any way
Hi all.
I wrote a very simple program to try out parallel Haskel and check how
it would look like to make use of more than one core in this language.
When I tried the program with RTS option -N1, total time shows it took
2.48 seconds to complete and around 65% of that time was taken by GC.
Then
On Sat, Mar 10, 2012 at 4:21 PM, Thiago Negri evoh...@gmail.com wrote:
c:\tmp\hspar +RTS -s -N1
par +RTS -s -N1
2000
803,186,152 bytes allocated in the heap
859,916,960 bytes copied during GC
233,465,740 bytes maximum residency (10 sample(s))
30,065,860 bytes maximum
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
I see. Thanks for the answers.
Any data structure or source annotation that would prevent that?
For example, if I try the same program to run on a
[1..] list, I'll get an out of memory error for the
single-threaded version. Any way to prevent it without declaring two
different
I'm afraid without uniqueness or linear typing it would be hard to avoid.
2012/3/10 Thiago Negri evoh...@gmail.com
I see. Thanks for the answers.
Any data structure or source annotation that would prevent that?
For example, if I try the same program to run on a
[1..] list,
(Sorry for the double post)
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
Hi,
Am Samstag, den 10.03.2012, 15:50 -0300 schrieb Thiago Negri:
I see. Thanks for the answers.
Any data structure or source annotation that would prevent that?
For example, if I try the same program to run on a
[1..] list, I'll get an out of memory error for the
