new i/o library

[Bulat Ziganshin]

Hello Duncan,

Saturday, January 28, 2006, 3:08:04 PM, you wrote:

>> yes, i want to save exactly this bit of performance - after i
>> optimized all other expenses on the path of text i/o

DC> There is a trade off, using mmap gives you zero-copy access to the page
DC> cache however there is a not-insignificant performance overhead in
DC> setting up and tearing down memory mappings. This is true on unix and
DC> win32. So for small writes (eg 4k blocks) it is likely to be cheaper to
DC> just use read()/write() on page aligned buffers rather than use mmap.

DC> You would need to do benchmarks on each platform to see which method is
DC> quicker. Given the code complexity that other people have mentioned I do
DC> not think it would be worth it.

i use 64k buffers and tried mmapped files last night. it's not easy to
properly implement this and then to ensure good speed. at least
windows very lazily flushes the buffers that was filled using mmap.
when i wrote 1 gb file in this mode, windows tried to swap out all
programs and itself but delayed writing of already unmapped data!

DC> Using page aligned and sized buffers can help read()/write() performance
DC> on some OSes like some of the BSDs.

i will try to cutout aligned 64k buffer inside 128k block and will
publish this code here so anyone can test it on his OS

>> in other words, i interested in having zero-wait operation both for
>> reading and writing,

DC> As I said that is not possible with either read() or mmaped read.
DC> Conversely it works automatically with write() and mmaped writes.

DC> Zero-copy and zero-wait are not the same thing.

i mean that mmap guarantee us zero-copy operation and i wish to use
mmap in such way that zero-wait operation can be ensured

DC> An important factor for optimising IO performance is using sufficiently
DC> large block sizes to avoid making frequent kernel calls. That includes
DC> read()/write() calls and mmap()/unmap() calls.

that's true and easy to implement

DC> Perhaps it is possible to move the complexity needed for the lazy
DC> hPutStr case into the hPutStr implementation rather than the Handle
DC> implementation. For example perhaps it'd be possible for the Handle to
DC> just have one buffer but to have a method for writing out an external
DC> buffer that is passed to it. Then hPutStr would allocate it's own
DC> buffer, evaluate the string, copying it into the buffer. Then it would
DC> call on the Handle to write out the buffer. The Handle would flush its
DC> existing internal buffer and write out the extra buffer.

1) "lazy hPutStr" is not some rare case. we can't distinguish strict
and lazy strings with current GHC and in any hPutStr invocation we
should assume that evaluation of its argument can lead to side
effects. that is the whole problem - we want to optimize hPutStr for
the fast work with strict strings, but need to ensure that it will
work correctly even with slow lazy strings having any side effects

2) the scheme above can be implemented using hPutBuf to write this
additional buffer. it's just less efficient (although is not so much -
memcpy works 10 times faster than traversing of [Char])

on the other side, Simon don't counted that locking itself is rather
slow and using two locks instead of one lead to some slowness of his
scheme, especially on small strings

DC> Perhaps a better solution for your single-threaded operation case is to
DC> have a handle type that is a bit specialised and does not have to deal
DC> with the general case. If we're going to get a I/O system that supports
DC> various layers and implementations then perhaps you could have an one
DC> that implements only the minimal possible I/O class. That could not use
DC> any thread locks (ie it'd not work predictably for multiple Haskell
DC> threads)

moreover - we can implement locking as special "converter" type, that
can be applied to any mutable object - stream, collection, counter.
that allows to simplify implementations and add locking only to those
Streams where we really need it. like these:

h <- openFD "test"
       >>= addUsingOfSelect
       >>= addBuffering 65536
       >>= addCharEncoding utf8
       >>= attachUserData dictionary
       >>= addLocking

DC> and use mmap on the entire file. So you wouldn't get the normal
DC> feature that a file extends at the end as it's written to, it'd need a
DC> method for determining the size at the beginning or extending it in
DC> large chunks. On the other hand it would not need to manage any buffers
DC> since reads and writes would just be reads to/from memory.

yes, i done it. but simple MapViewOfFile/UnMapViewOfFile don't work
well enough, at least on writing. windows don't hurry to flush these
buffers, even after unmap, and using of flushViewOfFile results in
synchronous flushing of buffer to the cache. so i need to try doing
flushViewOfFile in separate thread, like the GHC does for its i/o

DC> So it'd depend on what the API of the low level layers of the new I/O
DC> system are like as to whether such a simple and limited implementation
DC> would be possible.

it's no problem. m/m file just implements API that tells the user the
address/size of the next buffer to fill/read. this interface used also
for plain memory buffers and interprocess communications via shared
memory:

    -- | Receive next buffer which contains data / must be filled with data
    vReceiveBuf :: (Integral size) => h -> ReadWrite -> m (Ptr a, size)
    -- | Release buffer after reading `len` bytes / Send buffer filled with `len` bytes
    vSendBuf    :: (Integral size, Integral len) => h -> Ptr a -> size -> len -> m ()


-- 
Best regards,
 Bulat                            mailto:bulatz at HotPOP.com