Hans-Peter Nilsson - [RFA:] Make 23_containers/set/modifiers/16728.cc not time out nonnativel (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

• From: Hans-Peter Nilsson
• To: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
• Date: Tue, 6 Feb 2007 01:34:54 +0100
• Subject: [RFA:] Make 23_containers/set/modifiers/16728.cc not time out nonnatively

:ADDPATCH libstdc++ testsuite:

Whenever I test cris-axis-elf (using a simulator) certain libstdc++ tests time out, some of them depending on the host system load. That's not until now been important enough to worry about, but as I now have an autoregtester in place (no worries, it reports to me only :) those timeouts translate to time wasted that would have been used for the next round (probably more like one or two more full rounds). Currently, about ten tests, all in the libstdc++ testsuite time out for (at a glance) different reasons. Here's a fix that may generally apply to many of them: don't do as much in the cross-test case as in the native case.

Regarding this test, 23_containers/set/modifiers/16728.cc, I'm not even sure what purpose it has. It says "the goal with this application is to compare the performance between different std::allocator implementations" but at least in the testsuite it doesn't (compare any performance). All it seems to do is churning memory allocations, and I don't see any sign of checking that it does anything correctly, other than hopefully trapping miscompilations and bugs in the allocator. The URLs in the test also hint that this test would be used together with "time" to compare allocator performance, but that's not done; all it does in the testsuite is churn churn churn.

It has some interesting nonlinear behaviour: with the src/sim/cris simulator and cris-axis-elf on a Opteron 150 2.4GHz: Iterations Time (user) <=5 0.02s 10 0.03s 100 0.68s 200 2.58s 300 5.59s 400 9.87s 500 15.32s 600 22.27s 700 33.43s 800 58.27s 900 97.01s 1000 (was still running after 5.8h) 10000 (was still running after 10h)

It runs pretty quickly natively on a x86_64 host, so those figures don't translate very well; maybe at 10 M iterations you'd see thrashing there.

Anyway, I can't see why the figure 10000 would be magical, might as well make it 1000 times less for cross environments as follows. Tested x86_64-unknown-linux-gnu native and cross to cris-axis-elf, making sure the -DITERATIONS=10 happens for the latter, not the former.

Ok to commit?

If so, perhaps I can get preapproval for similar changes to other libstdc++ tests?

libstdc++-v3: * testsuite/23_containers/set/modifiers/16728.cc: Use only 10 iterations for non-native targets.

Index: testsuite/23_containers/set/modifiers/16728.cc

--- testsuite/23_containers/set/modifiers/16728.cc (revision 121581) +++ testsuite/23_containers/set/modifiers/16728.cc (working copy) @@ -38,8 +38,14 @@ using namespace std;

typedef int test_type;

+// This can take extremely long on simulators, timing out the test. +// { dg-options "-DITERATIONS=10" { target { ! native } } } +#ifndef ITERATIONS +#define ITERATIONS 10000 +#endif + // The number of iterations to be performed. -int iterations = 10000; +int iterations = ITERATIONS;

// The number of values to insert in the container, 32 will cause 5 // (re)allocations to be performed (sizes 4, 8, 16, 32 and 64)

brgds, H-P

• Follow-Ups:
  • Re: [RFA:] Make 23_containers/set/modifiers/16728.cc not time out nonnatively
    * From: Joseph S. Myers