Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Subject: Re: readv/writev
From: Robert Collins <rbcollins AT cygwin DOT com>
To: Conrad Scott <Conrad DOT Scott AT dsl DOT pipex DOT com>
Cc: cygwin-developers AT cygwin DOT com
In-Reply-To: <00c501c2496e$39ae2720$6132bc3e@BABEL>
References: <019701c2494f$614e4a40$6132bc3e AT BABEL>
	<1029971194 DOT 28132 DOT 16 DOT camel AT lifelesswks> 
	<00c501c2496e$39ae2720$6132bc3e AT BABEL>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-VaF+VAEYlrQtlEDtkpui"
Date: 22 Aug 2002 10:35:36 +1000
Message-Id: <1029976536.27825.46.camel@lifelesswks>
Mime-Version: 1.0


--=-VaF+VAEYlrQtlEDtkpui
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-08-22 at 09:55, Conrad Scott wrote:
> "Robert Collins" <rbcollins AT cygwin DOT 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?
>=20
> 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:
>=20
>     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.
>=20
> I think 72 lines with several conditionals and loops is not short
> (whether "fairly" or otherwise).
>=20
> > 3) Implement 'native' Overlapped IOw/  scatter-gather
> > for NT OS's on disk files. :}.
>=20
> 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=3D1) 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.)
=20
> 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




--=-VaF+VAEYlrQtlEDtkpui
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9ZDHXI5+kQ8LJcoIRAtIxAKCAW88NrK5LBIOpfal4NnMqodISggCfcRMW
73wl8mkkp9G/1cEQLkLRdlE=
=Ty8E
-----END PGP SIGNATURE-----

--=-VaF+VAEYlrQtlEDtkpui--