Re: Threads: Updated Win32_thread.zip

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-13 14:44:07

--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> 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
> ------------------
> boost::mutex is 4.5 x slower than Win32 mutex
> boost::mutex is 320 x slower than Win32 mutex

Wow!  My machine is a Pentium 330Mhz with 128Mb RAM, running Windows 
NT 4.0, SP 5.  I compiled with VC++ 6.0 SP4.  These are the (typical) 
results I recieve:

Testing Boost mutex...
1221
Testing Win32 critical section...
120
Testing Win32 mutex...
7111

In a debug build I get the typical results:

Testing Boost mutex...
7921
Testing Win32 critical section...
200
Testing Win32 mutex...
7201

This shows worse performance for the Boost mutex, but not by much.

Maybe the differences are a result of the OS?  Maybe others should 
run some benchmarks to verify what's going on here?

> 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 ?

Very strange indeed.  I'm not an expert in this area, so I don't know 
what would be causing these discrepencies.
 
> 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).

I used the new iostreams with the project settings at Multithreaded 
not Multithreaded DLL.  So I don't understand your comment here.  
However, switching to Multithreaded DLL produced no significant 
changes to the timings.  So the setting makes little difference.
 
> 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).

The difficult part in porting this to Linux will be porting 
atomic_t.  If you don't use real atomic operations in atomic_t (i.e. 
you instead implement it using a mutex) then the spin lock will be 
very inneficient and you can expect a significant degradation over a 
normal mutex.  When this library is ported the logic within semaphore 
will have to use conditional compilation to choose to use a spinlock 
or not depending on the platforms capabilities (actually, on some 
platforms it may use some completely different implementation, I 
don't know).

Bill Kempf