This is in uvector, right? Then you should probably forward this to the
maintainer, i.e. Don Stewart <[email protected]>.
Cheers,
Simon
Tyson Whitehead wrote:
I believe the arrays for (Word/Int)(8/16/32) are currently taking eight, four,
and two times, respectively, as much memory as actually required. That is,
newMBU n = ST $ \s1# ->
case sizeBU n (undefined::e) of {I# len# ->
case newByteArray# len# s1# of {(# s2#, marr# #) ->
(# s2#, MBUArr n marr# #) }}
sizeBU (I# n#) _ = I# (wORD_SCALE n#)
wORD_SCALE n# = scale# *# n# where I# scale# = SIZEOF_HSWORD
(sizeBU is a class member, but all the instances for (Word/Int)(8/16/32) are
as given above, and SIZEOF_HSWORD is defined as 8 in MachDeps.h on my x86_64)
which would seems to always allocate memory assuming an underlying alignment
that is always eight bytes. It seems like the readWord(8/16/32)Array#
functions may have once operated that way, but, when I dumped the assembler
associated with them under ghc 6.8.2 (both native and C), I get
readWord8Array
leaq 16(%rsi),%rax
movzbl (%rax,%rdi,1),%ebx
jmp *(%rbp)
readWord16Array
leaq 16(%rsi),%rax
movzwl (%rax,%rdi,2),%ebx
jmp *(%rbp)
readWord32Array
leaq 16(%rsi),%rax
movl (%rax,%rdi,4),%ebx
jmp *(%rbp)
readWord64Array
leaq 16(%rsi),%rax
movq (%rax,%rdi,8),%rbx
jmp *(%rbp)
which is using alignments of one, two, four, and eight bytes respectively.
I'll attach a patch (which I haven't tested beyond compiling and looking at
the generated assembler).
Cheers! -Tyson
------------------------------------------------------------------------
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
