Hi Bulat,
obviously, arrays version should create no temporary cells.
that's why the memory traffic surprised me. i knew there had to be something wrong.
the problems was mainly due to 2 factors: 1) readArray m (i,j)
yes, indeed. since we are dealing in bulk operations, we might as well take advantage of that, so dropping the repeated bounds-checks inside the loops makes a lot of sense. moral/note to self: bulk array operations are your friend (i knew that!-), but you need to use that when defining them (unsafeRead et al are only for library writers, but library writers ought to use them; and i was writing a small inlined library)
2) 'op' in 'l' which was passed as real closure and was not inlined due to weakness of ghc optimizer
it irked me having to write the same loop twice, but i didn't consider the consequences. an INLINE pragma on l almost seems sufficient to regain the loss, so i prefer that; but writing out the loop twice is still a tiny tick faster..
we should help strictness analyzer by marking all the variables used in tight loops as strict.
ah, there were a few surprises in that one. i thought i had considered possible strictness problems, but obviously, i missed a few relevant possibilities. annotating everything is the safe option, and clearly documents the intentions, but i cannot help thinking about which annotations could be omitted: - modArray: a and i are both used anyway - i index in loop is definitely checked (but j isn't, and some others weren't, either; so better safe than sorry) - some of the parameters need not be annotated in this example, but should be if one wanted to reuse the code elsewhere - the one i really don't get yet is the one on the accumulators (!s in l, in dotA/matA); i thought i had covered that by using $! in applying the loop, but annotating the formal loop parameter, apart from being nicer, also seems faster.. moral/note to self: don't try to be clever, try to be clear..; strictness in formal parameters is better than strictness in actual parameters; bang-patterns are good;-)
after that is done, we got 1000 times less temporary data allocated and 5x faster execution. now it's a bit faster than strict lists
is this now anywhere near what the number-crunchers use, when they use Haskell?-) Bulat, thanks for looking into it and for isolating the issues so quickly!-) claus