Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of Farid_Zaripov@epam.com
 designates 217.21.63.3 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: atomic tests timing out on Windows
Date: Thu, 26 Jul 2007 12:28:51 +0300
Message-ID: <7BDB2168BEAEF14C98F1901FD2DE6438BB07DB@epmsa009.minsk.epam.com>
In-Reply-To: <46A8123C.6010109@roguewave.com>
Thread-Topic: atomic tests timing out on Windows
Thread-Index: AcfPM4sUJs+xmsS2SZOX1iZREVNvbwAFQSJQ
References: <7BDB2168BEAEF14C98F1901FD2DE6438BB0751@epmsa009.minsk.epam.com>
 <46A8123C.6010109@roguewave.com>
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <stdcxx-dev@incubator.apache.org>

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Thursday, July 26, 2007 6:17 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: atomic tests timing out on Windows
>=20
> >   That tests works fine, but slow. This is because of using=20
> critical=20
> > section for synchronization for all types except=20
> signed/unsigned int=20
> > and long for which are used InterlockedXXX functions.
>=20
> That doesn't explain why the test runs so much faster in=20
> other builds on the same architecture (x86). Even with gcc on=20
> CygWin it runs to completion, as well as with MSVC on Windows 2003.
> All of these complete in under 30 seconds.

  The test on gcc uses pthreads, which could be implemented without
using system critical sections.

> >   For example on my computer the one execution of the=20
> run_test<> takes=20
> > about 25 seconds when used critical section and only 3.5=20
> seconds when=20
> > used InterlockedXXX functions. The full test takes 445=20
> seconds. And a=20
> > big strange is that CPU load only ~40% during the test.
>=20
> Is it a 2 CPU or dual core machine? If so, that might explain=20
> (some of) it. The CPU must wait for for the other one updates=20
> the variable.

  It's a 1.5 CPU machine :) (Pentium4 with HT).

  And seems that the timing out problem in HT enabled.

  I have played with atomic_xchg test:

=20
Test1      Test2      Test3
HT disabled:                                                        9735
9765       9765
HT enabled, process affinity mask =3D 3 (default):      202250       -
-
HT enabled, process affinity mask =3D 1:                  10625      =
10750
10782
HT enabled, process affinity mask =3D 2:                  10062      =
10047
10047

  The numbers is the time in milliseconds.

  And if you look into the night tests results: the all platforms where
atomic_xxx tests
are timed out has Pentium4 with HT processor.

Farid.