This is in uvector, right? Then you should probably forward this to the maintainer, i.e. Don Stewart . 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 Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Ah ha! Excellent! Much apprciated. twhitehead:

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 Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users