Boost logo

Boost :

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
> 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...
Testing Win32 critical section...
Testing Win32 mutex...

In a debug build I get the typical results:

Testing Boost mutex...
Testing Win32 critical section...
Testing Win32 mutex...

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
> win32 primitives are getting faster (!!!) critsec go to ~270, mutex
> 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
> 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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at