using ghc with make

[Simon Marlow]

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,
>>though.
> 
> 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.

Cheers,
	Simon