using ghc with make
simonmarhaskell at gmail.com
Wed Apr 19 04:15:55 EDT 2006
Bulat Ziganshin wrote:
> Hello Simon,
> Tuesday, April 18, 2006, 3:02:20 PM, you wrote:
>>>if that is due to the time of reading .hi files, my alternative Binary
>>>library should help in some future
>>I'd be suprised if you could improve on GHC's binary library. Using
>>BinMem (reading/writing directly to memory), GHC's binary library is
>>about as fast as it gets. I'm sure yours wins when dealing with files,
> sorry, Simon, but when i found 10x difference in speed (6mb/s vs 60
> mb/s) it was on membufs :) although i can't say that the difference
> anyway will be 10 times. for so fast lib the time required to traverse
> lists is essential. there are also a lot of other possible problems. i
> just asking - whether the time required for reading these (or any
> other binary) files is essential for compilation speed?
It's been on my todo list for a while to benchmark the various Binary
libraries, since there's a consensus that we need some kind of Binary
functionality in Haskell'.
I said I'd be surprised if GHC's could be improved on. And indeed, I am
now surprised :-) You do point out some places where it could be
improved. The first thing I would do is replace the IOUArray with a
ForeignPtr now, since that lets you unbox the Ptr without losing garbage
collection of the memory, and retains the ability to re-allocate the
storage. How does your library handle memory allocation, do you have to
explicitly free the memory used for the buffer?
To answer your question, reading interface files isn't a bottleneck in
GHC (although improving its speed is definitely worthwhile).
> instance Binary Word16 where
> get h = do
> w1 <- getWord8 h
> w2 <- getWord8 h
> return $! ((fromIntegral w1 `shiftL` 8) .|. fromIntegral w2)
> first possible problem here is what getWord8 is not inlined. second -
> using of checked arithmetic (operations on Ints may have additional
> checks, unlike operations on Int#)
yes, using uncheckedShiftL would be better.
> third - it's better to make all
> operations on Int and only then pack all data to Int16 constructor
An Int16 is represented using an Int with sign-extension, so it should
be the same.
I agree that making the format independent of word size would also be
good for a general purpose Binary library, although it wouldn't be
helpful for GHC.
More information about the Glasgow-haskell-users