incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <stefan.tele...@gmail.com>
Subject Re: STDCXX-1056 [was: Re: STDCXX forks]
Date Tue, 04 Sep 2012 14:34:46 GMT
On Tue, Sep 4, 2012 at 7:35 AM, Liviu Nicoara <nikkoara@hates.ms> wrote:

> By no means I am dismissing it. It is at the very least an issue of
> efficiency. I will try an Intel C++ build on x86_64 at some point today.
> What build type was that? I also notice that you have 4.2.1 in your path?
> Are you building out of 4.2.1. tag? I built off 4.2.x branch which also has
> support for custom timeouts (--soft-timeout) in rw_test.

Yes, this is 4.2.1 with all the Solaris  patches which can be applied
on Linux. The environment is:

# INFO (S1) (10 lines):
# TEXT:
# COMPILER: Intel C++, __INTEL_COMPILER = 1210,
__INTEL_COMPILER_BUILD_DATE = 20111011, __EDG_VERSION__ = 403
# ENVIRONMENT: pentiumpro running linux-elf (Fedora release 17 (Beefy
Miracle) (3.5.0-2.fc17.x86_64)) with glibc 2.15
# FILE: 22.locale.numpunct.mt.cpp
# COMPILED: Sep  4 2012, 09:11:36
# COMMENT: thread safety
############################################################

# CLAUSE: lib.locale.numpunct

[ ... snip ... ]

With all the thread-safety Solaris patches for 1056 applied. The test
runs to completion:

# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-Cej8JU"
# CLAUSE: lib.locale.numpunct
# FILE: process.cpp
# LINE: 276

# INFO (S1) (3 lines):
# TEXT: testing std::numpunct<charT> with 8 threads, 200000 iterations
each, in 32 locales { "C" "aa_DJ" "aa_DJ.iso88591" "aa_DJ.utf8"
"aa_ER" "aa_ER@saaho" "aa_ER.utf8" "aa_ER.utf8@saaho" "aa_ET"
"aa_ET.utf8" "af_ZA" "af_ZA.iso88591" "af_ZA.utf8" "am_ET"
"am_ET.utf8" "an_ES" "an_ES.iso885915" "an_ES.utf8" "ar_AE"
"ar_AE.iso88596" "ar_AE.utf8" "ar_BH" "ar_BH.iso88596" "ar_BH.utf8"
"ar_DZ" "ar_DZ.iso88596" "ar_DZ.utf8" "ar_EG" "ar_EG.iso88596"
"ar_EG.utf8" "ar_IN" "ar_IN.utf8" }
# CLAUSE: lib.locale.numpunct

[ ... snip ... ]

# +-----------------------+----------+----------+----------+
# | DIAGNOSTIC            |  ACTIVE  |   TOTAL  | INACTIVE |
# +-----------------------+----------+----------+----------+
# | (S1) INFO             |       11 |       11 |       0% |
# | (S2) NOTE             |        1 |        1 |       0% |
# | (S8) ERROR            |        0 |        3 |     100% |
# | (S9) FATAL            |        0 |        1 |     100% |
# +-----------------------+----------+----------+----------+
real 2139.31
user 2406.09
sys 155.61
[steleman@darthvader][/src/steleman/programming/stdcxx-intel/stdcxx-4.2.1-thread-safe/build/tests][09/04/2012
9:50:14][1300]>>

These tests running to completion (with the patches applied) are 100%
reproducible on every single run, on Linux and Solaris (Intel and
SPARC).

The timings are the output of /usr/bin/time -p.

Yes, ~40 minutes wall clock run time for one test is quite a lot. But
it runs to completion, with zero errors. And when taking into
consideration that there are 8 threads with 200000 iterations, maybe
it's not that much. FWIW, SELinux is also fully enabled in my
environment.

This is on an Intel Core i7 with 8 cores @2.3GHz and 16GB RAM, FSB
1066. The compiler is Intel 12.10 (free for non-commercial use,
downloadable from Intel).

The timeouts can also be a symptom of race conditions/deadlocks or
attempting to access invalid thread stacks, or partially written data.
It's very platform specific. On Solaris SPARC (either 32-bit or
64-bit) I never get timeouts, I always get either SEGV or SIGBUS. On
Intel it appears that timeouts are the prevailing symptom.

I am not sure what an explicit run timeout would add, except hiding
the hang/deadlock/memory corruption problem behind a timeout.

--Stefan

-- 
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com

Mime
View raw message