This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: unix domain socket with shared memory ?

> -----Original Message-----
> From: []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 ? 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.
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 ?


Unsubscribe info:
Bug reporting:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]