Boost logo

Boost :

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

If I compile in Debug I get typical results:

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

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

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