Mail Archives: cygwin/2002/02/08/08:20:14
> -----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/
- Raw text -