Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
From: "Ralf Habacker" <Ralf DOT Habacker AT freenet DOT de>
To: "Corinna Vinschen" <cygwin AT cygwin DOT com>
Subject: RE: unix domain socket with shared memory ?
Date: Fri, 8 Feb 2002 14:15:18 +0100
Message-ID: <001f01c1b0a2$a76fd840$651c440a@BRAMSCHE>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <20020208125556.B12075@cygbert.vinschen.de>

> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]On Behalf
> Of Corinna Vinschen
> Sent: Friday, February 08, 2002 12:56 PM
> To: cygwin
> Subject: Re: unix domain socket with shared memory ?
>
>
> On Thu, Feb 07, 2002 at 11:55:31PM +0100, Ralf Habacker wrote:
> > One question: Does unix domain sockets uses localhost address ? net.cc:cygwin_socketpair() seems to
> use first an ip
> > adress of zero and later the loopback address. Could this have an effect ?
>
> Nope.  It's probably more secure to use INADDR_LOOPBACK here but
> it has nothing to do with speed.
>
> > I have tried to replace the locations using INADDR_ANY with htonl (INADDR_LOOPBACK) but recognized no changes.
>
> I would have lost a bet if that had changed anything.

I should add, it does not have any changes relating to the benchmark results. :-)

> > If you look a little deeper you can see, that the read() in unix domain socket benchmark returns only
> 32708 bytes
> >
> >  1966 1981317 [main] bw_unix 1788 _read: 32708 = read (3, 0xA012048, 65536), errno 0
> >
> > while the read() in the tcp benchmark returns 65416
> >
> >  2573 7229513 [main] bw_tcp 1792 _read: 65416 = read (3, 0xA012048, 65536), errno 0
> >
> > and thats may be a reason for the performance difference.
>
> Hmm, perhaps.  I've just checked in a fix which perhaps changes
> that disproportion.  Could you please check with the latest from
> CVS aggain?
>
Yes, i will try.

> > The main difference between the two benchmarks are the used device /dev/sockstream against /dev/tcp.
> > But don't ask me about the reason why, now I'm left
>
> That's easily to see in the sources.  net.cc?
>
I have assumed, that there are perhaps some hided implementation difference, which causes this buffer size
difference. :-

> > returned stable after a few (about 10) returns with the full buffer size of 65536 in the main
> benchmark loop. Could
> > this be a bug in the winsock code or is it be caused by timing differences, because not all data is send early
> > enough ? (There are 119 bytes  missed)
>
> Dunno.  Winsock overhead, perhaps.
>
> > BTW2:
> > > I'm a bit surprised by your results, though.
> > I'm additional surprised that the native unix domain sockets performance under cygwiwn is only 7% of the linux
> > performance with the same hardware, while the tcp performance seems to be acceptable (64% of the linux
> > performance). So my main target is to speed this up. :-)
>
> That's not a surprise.  AF_LOCAL sockets are naturally equaly slow
> or slower than AF_INET sockets on Cygwin (why?  Exercise for the
> reader!) while they are a completely independent implementation
> on Linux or other OSes.
Your're right, it's not a suprise for someone who know how cygwin implements AF_LOCAL :-), but of the sight from
linux, this isn't expected


I'm porting kde, which comes from linux or other unix and the contained libs and apps expects a faster
implementation of AF_LOCAL.
And because I'm trying to speed up kde running, this optimation looks good to me. My question is now, what do you
think about this idea with a shared memory implementation of AF_LOCAL ?

Ralf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/