On Fri, 2006-01-27 at 18:01 +0300, Bulat Ziganshin wrote:
Hello Duncan,
Friday, January 27, 2006, 4:00:28 PM, you wrote:
moreover, i have an idea how to implement async i/o without complex burecreacy: use mmapped files, may be together with miltiple buffers. for example, we can allocate four 16kb buffers. when one buffer is filled with written data, the program unmaps it and switches to use the next buffer. i don't tested it, but OS can guess that unmapped buffer now should be asynchronously written to disk. the same for reading - when we completely read one buffer, we can unmap it, switch to the second buffer and map the third so that the OS can asynchronously fill the third buffer while we are reading second. should this work, at least on the main desktop OSes?
DC> On Linux an probably other unix-like OSes I don't think this would be DC> any different from using read/write.
DC> On Linux, read and mmap use the same underlying mechanism - the page DC> cache. The only difference is that with mmap you get zero-copy access to DC> the page cache. However frequent mapping and unmapping may eliminate DC> that advantage. Either way there is no difference in how asynchronous DC> the operations are.
yes, i want to save exactly this bit of performance - after i optimized all other expenses on the path of text i/o
There is a trade off, using mmap gives you zero-copy access to the page cache however there is a not-insignificant performance overhead in setting up and tearing down memory mappings. This is true on unix and win32. So for small writes (eg 4k blocks) it is likely to be cheaper to just use read()/write() on page aligned buffers rather than use mmap. You would need to do benchmarks on each platform to see which method is quicker. Given the code complexity that other people have mentioned I do not think it would be worth it. Using page aligned and sized buffers can help read()/write() performance on some OSes like some of the BSDs.
in other words, i interested in having zero-wait operation both for reading and writing,
As I said that is not possible with either read() or mmaped read. Conversely it works automatically with write() and mmaped writes. Zero-copy and zero-wait are not the same thing.
i.e. that in sequence of getChar or putChar actions there were no waits on any action - of course, if the disk is fast enough. in other words, speed of such i/o programs should be the same as if we just write these data to memory
current GHC's Handle implementation uses rather complex machinery for async reading and writing, and i can even say that most part of Handle's implementation complexity is due to this async machinery. so i wanna know what exactly accomplished by this implementation and can we implement async operation much easier by using mmap?
the word "async" is overloaded here - i'm most interested in having zero-overhead in single-threaded operation, while GHC's optimization, afair, is more about overlapping I/O in one thread with computations in another. so i'm searching for fastest and easiest-to-implement scheme. what you propose?
An important factor for optimising IO performance is using sufficiently large block sizes to avoid making frequent kernel calls. That includes read()/write() calls and mmap()/unmap() calls. Perhaps it is possible to move the complexity needed for the lazy hPutStr case into the hPutStr implementation rather than the Handle implementation. For example perhaps it'd be possible for the Handle to just have one buffer but to have a method for writing out an external buffer that is passed to it. Then hPutStr would allocate it's own buffer, evaluate the string, copying it into the buffer. Then it would call on the Handle to write out the buffer. The Handle would flush its existing internal buffer and write out the extra buffer. Perhaps a better solution for your single-threaded operation case is to have a handle type that is a bit specialised and does not have to deal with the general case. If we're going to get a I/O system that supports various layers and implementations then perhaps you could have an one that implements only the minimal possible I/O class. That could not use any thread locks (ie it'd not work predictably for multiple Haskell threads) and use mmap on the entire file. So you wouldn't get the normal feature that a file extends at the end as it's written to, it'd need a method for determining the size at the beginning or extending it in large chunks. On the other hand it would not need to manage any buffers since reads and writes would just be reads to/from memory. So it'd depend on what the API of the low level layers of the new I/O system are like as to whether such a simple and limited implementation would be possible. Duncan