Re: readv/writev

[Robert Collins <rbcollins at cygwin dot com>]

On Thu, 2002-08-22 at 09:55, Conrad Scott wrote:
> "Robert Collins" <rbcollins@cygwin.com> wrote:
> >
> > Conrad Scott wrote:
> > >
> > > On my m/c, a 900Mhz Pentium III (?), the same test
> > > program I was using for the __stdcall / regparm testing
> > > (read 16Mb from /dev/zero one byte at a time and write
> > > to /dev/zero) takes about 3 seconds longer with the
> > > readv/writev changes.  That is, ~38.6 seconds rather
> > > than ~35.6 seconds.  So, it's measurable but it's a
> > > pretty extreme test.
> >
> > how long does it take if you read in a readv block of,
> > say 1000 elements? Faster or slower?
> 
> I'm not clear quite what you're asking here, which probably means
> I've not explained very well what I was up to in the first place
> :-(  The slow down I'm reporting is a constant overhead per
> read/write call (of approx. a tenth of a microsecond?).  So the
> speed of the two implementations will always differ by:
> 
>     no. of reads and writes * 0.1 microsecond

Yes but: you are only testing half of the changes. How much
slower/faster has readv /writev gotten? So I'm suggesting a 'race'
between read and readv on /dev/zero. If readv has gotten at least 0.5us
faster (say) then overall it should be good.

> > 2) *IF* the readv->read code is fairly short,
> > put it in a header so it can inline when appropriate.
> 
> I think 72 lines with several conditionals and loops is not short
> (whether "fairly" or otherwise).
> 
> > 3) Implement 'native' Overlapped IOw/  scatter-gather
> > for NT OS's on disk files. :}.
> 
> Well, yes, I would do but it's all a bit complex and stuff, you
> know?

I've some C++ code for async completion port access using Overlapped IO
with readv (v=1) support. It'd be trivial for me to make it support
arbitrary V sizes. I'm happy to send you that offline to use as
inspiration (it's not publicly visible just yet, for a couple of weird
reasons.)
 
> For binary-mode files we could get close, since ReadFile and
> WriteFile take an array of WSABUF structures which are isomorphic
> to readv/writev's iovec structures.  The problem is then mapping
> NT's overlapped mode into some vaguely plausible Posix interface,

Uh, overlapped maps nicely onto select/poll -for the most part-. It's
ZeroCopy that is the real challenge. And one (not the only) POSIX api
that does this is aio_write and aio_read. You may find this
<http://www.kegel.com/c10k.html> an interesting read.

Cheers,
Rob

Attachment: signature.asc
Description: This is a digitally signed message part