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