On Tue, Sep 4, 2012 at 7:35 AM, Liviu Nicoara <nikko...@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.tele...@gmail.com
