2008/5/18 Andrew Coppin
unsafeRead/Write
Found in Data.Array.Base, apparently. (I managed to find an example in the Gtk2hs "fastdraw" demo.)
Oddly, this seems to make virtually no performance difference. I find this highly surprising. But then, I perform 16 write to the array, and 64 reads from the ByteString, so maybe that's where I should be worrying about bounds checks...
Hi Andrew, just a profiling suggestion: did you try to use the SCC cost-centre annotations for profiling? If you want to know precisely what takes 60% of time, you can try: bn = {-# SCC "IntegerConversion" #-} 4 * fromIntegral wn b0 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+0) b1 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+1) b2 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+2) b3 = {-# SCC "ByteStringIndexing" #-} B.index bi (bn+3) w = foldl' (\w b -> shiftL w 8 .|. fromIntegral b) 0 [b3,b2,b1,b0] in {-# SCC "ArrayWriting" #-} unsafeWrite temp wn w In profiling the time of all expressions with the same SCC "name" will be summed. You can get more information about SCC here: http://www.haskell.org/ghc/docs/latest/html/users_guide/profiling.html#cost-... Obviously, even ultra-optimizing this function to be 60 times faster (assuming that this is possible) will only make your program go about 2 time faster. One advice: I've seen various md5sum implementations in C, all using about the same algorithms and data structures, and they performed even with 10x time differences between them; md5summing fast is not a really simple problem. If I were you I would drop the comparison with ultra-optimized C and concentrate on "does my high-level-good-looking-super-readable implementation perform acceptably?". What "acceptably" means is left as an exercise to the reader. Salvatore