On Sep 4, 2012, at 10:34 AM, Stefan Teleman wrote:
> 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).
That is good, right?
>
> 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.
Ok, so that clears (this build at least), maybe inefficient but runs to
completion with no crashes.
>
> The timeouts can also be a symptom of race conditions/deadlocks or
> attempting to access invalid thread stacks, or partially written data.
I would look at timeouts from the standpoint of the progression of the run: if
the run does not progress at all, as in threads are deadlocked, then I would
consider that a defect. If the run progresses, it is a mere inefficiency,
however bad.
> 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.
Could not get an Intel build off the ground on the account of the LIMITS.cpp
test not running to completion because of a possible compiler bug. I posted
earlier an account of it. Do you have a support account that allows posting bug
reports for Intel's C++ compiler?
>
> I am not sure what an explicit run timeout would add, except hiding
> the hang/deadlock/memory corruption problem behind a timeout.
The timeout option allowed me to run the program with a larger value, such that
the alarm would not trigger and allow the program to run to completion. Before
enlarging the timeout value, the individual tests would time out.
I did not have access to a Solaris box since I left Rogue Wave. Does Sun/Oracle
have any program that would allow one to test drive their compiler on a shared
box somewhere? I vaguely remember that HP had something like that a while ago.
Thanks!
Liviu
