Re: single task postgresql - Mailing list pgsql-hackers

Seems I'm replying rather quickly but I thought I'd point out that I
went back and started looking at the cygipc code again.  I'm now
starting to suspect that that the majority of the performance impact we
are seeing has to do with the semaphore implementation versus the shared
memory implementation.

Basically, the version which is using local memory is not having to
contend with a significant amount of semaphore negotiations while the
shared memory version must contend with this issue each and every time
memory is accessed.

It's worth noting that based on what I've seen so far (pointing out that
lots still need to be reviewed), the semaphore implementation on via the
cygipc library is going to yield an absolute worse case semaphore
performance on Win32 platforms.  That is, of all the natve
synchronization mechanisms available for Win32, the use of a generic
Semaphore is going to deliver the worst performance whereby one would
expect it to be perhaps an order of magnitude or slower than an ideal
Win32 semaphore implementation.

So, if you have the time, perhaps you can write some quick benchmarks on
Win32.  One which simply allocates a shared memory region and randomly
reads and writes to it.  Same thing for the shared/memory mapped file
implementation.  Next, create a multi-process implementation based on
each of your previous two tests.  In these test, try using the cygwin
library, native Win32 Mutex implementation (warning, this has some
issues because on Win32 Mutexs are optimized for threading and not
multi-process implementations), a Win32 Critical section (warning SMP
scaling issues -- absolute fastest for uni-processor systems on Win32)
and a native Win32 Semaphore implementation (horrible performance).  Of
course, timing each.

If my *guess* is correct, this will tell you that the significant
performance issues are directly associated with the use of Semaphores.

As I am starting to understand things, it looks like performance suffers
because the Win32 platforms are significantly biased toward threaded IPC
implementations and significantly suffer when forced into a
multi-process architecture (very Unix like).

Greg


On Wed, 2002-03-06 at 09:36, Oleg Bartunov wrote:
> Mark,
>
> I've found
> "Fast synchronized access to shared memory for Windows and for i86 Unix-es"
> http://www.ispras.ru/~knizhnik/shmem/Readme.htm
> Would't be useful ?
>
>
>     Regards,
>
>         Oleg
>
>
> On Wed, 27 Feb 2002, mlw wrote:
>
> > Oleg Bartunov wrote:
> > >
> > > On Wed, 27 Feb 2002, mlw wrote:
> > >
> > > > Greg Copeland wrote:
> > > > >
> > > > > Windows does not really have shared memory support.  This has been a
> > > > > beef with the Win32 API for a long time now.  Because it has been a long
> > > > > time complaint, it was finally added in Win2000 and later.  Likewise,
> > > > > I'd like to point out that thinks like sims, shared memory, pipes, etc,
> > > > > and other entities commonly used for concurrent programming strategies
> > > > > are slower in XP.  So, because shared memory really isn't well
> > > > > supported, they elected to have what is, in essense, memory mapped
> > > > > files.  Multiple processes then map the same file and read/write to it
> > > > > as needed, more or less as you would shared memory.  Unless you plan on
> > > > > only targetting on Win 2000 and XP, it sounds like a waste of time.
> > > >
> > > > This is not really true. Under DOS windows, i.e. 95,98, etc. Shared memory can
> > > > be done in 16 bit land with a touch of assembly and a DLL. Allocate, with
> > > > globalalloc, a shared memory segment. The base selector is a valid 32 bit
> > > > selector, and the memory is mapped in the above 2G space shared and mapped to
> > > > all 32bit processes.
> > > >
> > > > Under NT through 2K, yes using a memory mapped files is the way to do it, but
> > > > you do not actually need to create a file, you can use (HANDLE)0xFFFFFFFF,
> > > > which is the NT equivilent of the system memory file. The handle returned is a
> > > > system global object which can be shared across processes.
> > > >
> > >
> > > Mark,
> > >
> > > do you consider to work on this issue ?
> >
> > Yea, let me think about it. What is your time frame? When I offered to work on
> > it, I thought it could be a leasurely thing. I have to get a machine running
> > some form of Windows on which to develop and test.
> >
> > I want to say yes, and if no one else does it, I will, but I'm not sure what
> > your timeframe is. If it is the mystical 7.3, then sure I can do it easily. If
> > you need something quickly, I can help, but I don't think I could shoulder the
> > whole thing.
> >
> > I have a couple things I have promised people. Let me get those done. I will
> > try to write an equivilent set of functions for shget, shmat, etc. as soon as I
> > can. Anyone wanting to run with them can hack and test PostgreSQL on Windows.
> >
> > How does that sound?
> >
>
>     Regards,
>         Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83
>