Hello Simon, Wednesday, April 19, 2006, 12:15:55 PM, you wrote:
It's been on my todo list for a while to benchmark the various Binary
my lib anyway will be fastest :)))
libraries, since there's a consensus that we need some kind of Binary functionality in Haskell'.
Streams library includes AltBinary functionality and also emulation of two versions of NewBinary library - byte-aligned and bit-aligned one. as long as you search for nhc-style serialization library (i.e., with `get` and `put_` functions) my lib should be the best beast around. to be exact, it was started as fast serialization library when it become obvious that Joel Reymont's program is bound by serialization speed. and when fast serialization routines was written, i added Streams functionality to make this lib more useful :) it will be great to add all these libs i written last months to GHC and then Haskell' - AltBinary, Streams, unboxed references and refreshed implementation of Arrays library (in particular, it supports resizable arrays, i.e. implements one of GHC's tickets) my problem is that i still don't documented most of these libs and what i'm not too enthusiastic about them's cabalizing and all other forms of maintenance. also, for Streams lib i implemented most of things that i know how to implement, but such things as I/O multiplexing and network support is beyond of my knowledge. btw, what you think about network-alt lib by Einar? is it better than ghc's bundled libs for networking? if so, i will cowork with him to add his lib to Streams framework
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,
this will be faster only for ghc 6.6
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?
buffer handling is part of buffering stream transformer. yes, memory freed explicitly on vClose. the AltBinary lib (and NewBinary, which is emulated via AltBinary) just implements get/put_ for many types via vGetByte/vPutByte, so serialization part of library don't know anything about memory handling. btw, my lib implements even pure (de)serialization functions - encode::a->String and decode. they just use Streams working in ST monad - StringBuffer/StringReader
instance Binary Word16 where get h = do w1 <- getWord8 h w2 <- getWord8 h return $! ((fromIntegral w1 `shiftL` 8) .|. fromIntegral w2)
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.
yes, Word8->Word16 and other conversions are handled by special rules for `fromIntegral`. i don't looked in GHC/Word.hs when i wrote previous letter btw, one more drawback of ghc's Binary is what on each getWord8 operation, type of handle should be tested (whether it is file or memory buffer). in my lib, when all operations are inlined, such test is not required -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com