Performance

Performance

[Erik Hensema]

Sorry if this question has been asked before on this list, but the archives
seem te be offline.

I'm preparing to port a 110 kloc application from Unix to NT. It's very
performance critical, so we don't want to use API's like Nutcracker or
Cygwin.
The application extensively uses multithreading, and we want to maximise the
performance. How does the pthread-win32 performance compare to the regular
win32 threads? And, if we aren't going to use pthreads-win32, how much
effort would it take to port our pthreads application to win32?


Erik Hensema, erik.hensema@group2000.nl

Re: [pthread-win32] Performance

[Tristan Savatier]

Erik Hensema wrote:
> 
> Sorry if this question has been asked before on this list, but the archives
> seem te be offline.
> 
> I'm preparing to port a 110 kloc application from Unix to NT. It's very
> performance critical, so we don't want to use API's like Nutcracker or
> Cygwin.
> The application extensively uses multithreading, and we want to maximise the
> performance. How does the pthread-win32 performance compare to the regular
> win32 threads?

very small overhead. we are also using pthread-win32 for a very cpu
and thread intensive multimedia application.

You can also look at the source code, and you will
see that the pthread-win32 library does not do much processing.

> And, if we aren't going to use pthreads-win32, how much
> effort would it take to port our pthreads application to win32?

it really depends on what your application does, and if
it has to interact with the windows messaging API (e.g.
WaitForMultipleEvents etc), which does not exist on
unix.

on unix, there are two distinct ways to synchronize tasks:
using select to wait for data available on a pipe or
socket, and using mutex and signal conditions.  both
systems are completely orthogonals and do not mix well,
but sometimes unix applications have to use both, wich
is possible but requires contortions and is not elegant.

on win32, there is a unique way to synchronize, using
events and messages. it is possible to wait until either
an even or a message arrives.  it simplify the
design of win32 applications, but does not simplify porting
from unix.

There is some support for select on win32, but it does not
work well and you cannot rely on it.  for example, win32
select does not work with pipes and files.  it seems to
only work with sockets.

-t


> 
> Erik Hensema, erik.hensema@group2000.nl

RE: Performance

[Bossom, John]

The pthreads-win32 library maps the pthreads interface and semantics
to the win32 threads interface.

The overhead depends upon what features of PThreads you are using. Many
features directly map to Win32 threads, whereas, others must be simulated.
For instance, mutexes can be mapped directly (and, in fact, the
pthreads-win32
library lets you choose to map to either CRITICAL_SECTION or kernel based
mutexes... CRITICAL_SECTION is about 100 times faster than kernel mutexes,
at
the expense of some functionality), whereas TSD keys that specify a destroy
routines requires simulation.

If you are using simple threading (create a thread) and simple use of
synchronization mechanisms (mutexes, semaphores) then the mapping to
win32 threads is straight forward.

If, however, you make extensive use of condition variables, and other
PThread features that do not exist on Win32, you will have to write
your own simulation code or change to use a different mechanism...
(or simply use pthreads-win32)

John.


-----Original Message-----
From: Erik Hensema [ mailto:erik.hensema@group2000.nl ]
Sent: Wednesday, September 22, 1999 10:29 AM
To: 'Pthreads-win32'
Subject: Performance


Sorry if this question has been asked before on this list, but the archives
seem te be offline.

I'm preparing to port a 110 kloc application from Unix to NT. It's very
performance critical, so we don't want to use API's like Nutcracker or
Cygwin.
The application extensively uses multithreading, and we want to maximise the
performance. How does the pthread-win32 performance compare to the regular
win32 threads? And, if we aren't going to use pthreads-win32, how much
effort would it take to port our pthreads application to win32?


Erik Hensema, erik.hensema@group2000.nl