One more observation... I tried a third variation in which the test program
still uses a single shared IOArray but each thread writes to different
indices in the array. In this case I get good scaling with performance
similar to the use of IOUArray. In detail, I made the following two changes
to
I should have double-checked my work before I sent the last message; I
accidentally benchmarked the wrong program. It turns out that the
modifications I last described do not improve the scaling of the program to
more cores when used with IOArray. And there was a bug: the line startIx
= numixs *
Hi,
I am getting my feet writing concurrent programs in Haskell with GHC for
multicore machines. As a first step I decided to write a program that reads
and writes concurrently to an IOArray, with no synchronization whatsoever.
I'm doing this to establish a baseline to compare with the
On 23/08/2011 09:04 PM, Andreas Voellmy wrote:
I compiled this with ghc --make -rtsopts -threaded -fforce-recomp -O2
DirectTableTest.hs.
Running time ./DirectTableTest 1 +RTS -N1 takes about 1.4 seconds and
running time ./DirectTableTest 2 +RTS -N2 take about 2.0 seconds!
I found that
On Tue, Aug 23, 2011 at 10:04 PM, Andreas Voellmy
andreas.voel...@gmail.com wrote:
data DAT = DAT (IOArray Int32 Char)
Try to make this a newtype instead. The data type adds a level of indirection.
do let p j c = insertDAT a j c lookupDAT a j = \v - v `pseq` return
()
You most likely want
On Tue, Aug 23, 2011 at 16:04, Andreas Voellmy andreas.voel...@gmail.comwrote:
I found that changing the array type used in the implementation of
DirectAddressTable from IOArray to IOUArray fixes this problem.
Since the main observable effect of this change is strictness, I'd
immediately
Thanks for the suggestions. I tried to add strictness in the following
ways:
(1) Changing insertDAT a j c to insertDAT a j $! c
(2) Changing insertDAT a j c to deepseq c (insertDAT a j c)
I also used Int instead of Int32 throughout and changed the DAT data type to
a newtype definition. These
