Re: Threads: Updated Win32_thread.zip

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-13 15:40:27

--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> William Kempf wrote:

I replied to this once before, but it seems to have disappeared in 
the ether.  If I wind up double posting I appologize.

> my timings are VERY different. my machine is a 450Mhz PIII with 
128Mb RAM,
> with windows98 4.10.1998. with VC++ 6.0 SP4 (Release version of the 
test
> program) the average times from 5 runs:
> ------------------
> Testing Boost mutex...
> 102600
> Testing Win32 critical section...
> 320
> Testing Win32 mutex...
> 22800
> ------------------

I'm on a Pentium 330Mhz machine with 128Mb RAM.  I compiled using 
VC++ 6.0 SP4.  I'm running Windows NT 4.0 SP 5.  Typical results I 
get are:

Testing Boost mutex...
1552
Testing Win32 critical section...
160
Testing Win32 mutex...
7781

If I compile in Debug I get typical results:

Testing Boost mutex...
10304
Testing Win32 critical section...
231
Testing Win32 mutex...
7991

(If my first response gets through you'll see some discrepencies, 
especially in Debug.  I don't have the original timings I used for 
that response so I ran the tests again.  This time, however, I have 
an extensive build running, resulting in much worse performance for 
the Boost mutex in Debug.  The rest of the timings however were 
similar enough to this run.)

> anyway it's when nothing else is running (ie. everything is idle) 
on the
> machine, BUT when something else is running (ie. devstudio is 
compiling)
> win32 primitives are getting faster (!!!) critsec go to ~270, mutex 
~11000
> I don't know why ?

I can't explain the discrepencies.  I'm no expert on this.  I assume 
the speed discrepencies are due to the OS since the rest of our stats 
are similar, but with out other's running some timings this is just a 
guess.  Why the native types would become faster when other processes 
are running is beyond me.
 
> ps. if you switch the
> C/C++ / Code Generation / Use run-time library 
> to the (Debug) Multithreaded DLL (which is better anyway is you'd 
like to 
> use more dll and new iostream) that it's help a little (the above 
number
> are with this settings).

The example uses the new iostreams and is compiled with the static 
runtime, so I don't quite follow your comment.  However, a quick test 
compiling with the DLL version shows no significant difference in 
timings, so this is a non-issue.
 
> ps. if I've got some time I tye to implement it on linux and make 
the
> mesaurement at the same machine (I've got RH 6.2 too).

Careful if you port to Linux.  If you don't provide native support 
for atomic operations in atomic_t (i.e. you use a mutex instead) then 
the spin lock will be highly ineficient.  This means you'll need a 
different implementation for semaphore in order to have any hope to 
even match the speed of the native mutex.  Whether or not the Boost 
implementation will be faster than the native pthread_mutex_t is 
dependant both on the spin lock issue and whether or not your 
specific platform uses a spin lock internally to pthread_mutex_t.

The interface is portable, the implementation is far from it, 
especially if performance is taken into consideration.

Bill Kempf