From patchwork Sat Jun 10 04:05:28 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans-Peter Nilsson X-Patchwork-Id: 70858 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0D4403857353 for ; Sat, 10 Jun 2023 04:05:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D4403857353 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1686369959; bh=gl1RypKdmbCj45d3DHcPR7NrFwWCzzup7GtzJ+ex5Bk=; h=To:CC:In-Reply-To:Subject:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=jG4I6Gd9f/Y5oNL2kTiNgZ1A0L7I3nKOIRRZB3OZBfEeHiK8nunwPgvJBjTt8Fyly ZhpB7BuYsX0dJRVHzKtf4jvYDCZmbuxljZxNwGclT5BcMkIXy/aAj1Dd3ELwiQcASv T18lxIf9Bg4uVVDBtgc7jTpcsKWzQHnmbQoFUous= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from smtp2.axis.com (smtp2.axis.com [195.60.68.18]) by sourceware.org (Postfix) with ESMTPS id EE5303858D35; Sat, 10 Jun 2023 04:05:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EE5303858D35 To: Jonathan Wakely CC: , In-Reply-To: (message from Jonathan Wakely on Fri, 9 Jun 2023 21:40:15 +0100) Subject: [PATCH] (Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long)) MIME-Version: 1.0 References: <20230609162026.CC34320433@pchp3.se.axis.com> Message-ID: <20230610040528.1058420420@pchp3.se.axis.com> Date: Sat, 10 Jun 2023 06:05:28 +0200 X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Hans-Peter Nilsson via Gcc-patches From: Hans-Peter Nilsson Reply-To: Hans-Peter Nilsson Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Thank you for your consideration. (Or is that phrase only used negatively?) > From: Jonathan Wakely > Date: Fri, 9 Jun 2023 21:40:15 +0100 > test01, test02, test03 and test04 should run almost instantly. On my system > they take about 5 microseconds each. So I don't think splitting those up > will help. Right. > I thought it would help to avoid re-allocating the buffer and zeroing it > again. If we reuse the same buffer, then we just have to loop until we > overflow the 32-bit counter. That would make the whole test run much > faster, which would reduce the total time for a testsuite run. Splitting > the file up into smaller files would not decrease the total time, only > decrease the time for that single test so it doesn't time out. > > I've attached a patch that does that. I makes very little difference for > me, probably because allocating zero-filled pages isn't actually expensive > on linux. Maybe it will make a differene for your simulator though? Nope, just some five seconds down (from about 10min 21s). > You could also try reducing the size of the buffer: > +#ifdef SIMULATOR_TEST > + static const streamsize bufsz = 16 << limits::digits10; > +#else > static const streamsize bufsz = 2048 << limits::digits10; > +#endif Was that supposed to be with or without the patch? Anyway; both: 606s. Only smaller bufsz: 614s. (All numbers subject to usual system jitter.) > test06 is the really slow part, that takes 10+ seconds for me. But that > entire function should already be skipped for simulators. Yep, we may have been here before... I certainly get a deja-vu feeling here, but visiting old email conversations of ours, it seems I easily conflate several similar ones. I see that here, test06 was always #ifndef SIMULATOR_TEST. > We can probably skip test05 for simulators too, none of the code it tests > is platform-specific, so as long as it's being tested on x86 we don't > really need to test it on cris-elf too. Thanks. Let's do that, then. The similar s/wchar_t/char/ test clocks in at "only" 3m30s, but I suggest treating it the same, if nothing else than for symmetry. Ok as below? -- >8 -- Subject: [PATCH] testsuite: Cut down 27_io/basic_istream/.../94749.cc for simulators The test wchar_t/94749.cc can take about 10 minutes on some simulator/host combinations with char/94749.cc at a third of that time. The cause is test05 which is quite heavy and includes wrapping a 32-bit counter. Run it only for native setups. * testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc (main) [! SIMULATOR_TEST]: Also exclude running test05. * testsuite/27_io/basic_istream/ignore/char/94749.cc: Ditto. --- libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc | 2 +- .../testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc index 6416863983b7..9160995c05ec 100644 --- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc +++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/char/94749.cc @@ -221,8 +221,8 @@ main() test02(); test03(); test04(); - test05(); #ifndef SIMULATOR_TEST + test05(); test06(); #endif } diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc index 65e0a326c109..a5b9eb71a389 100644 --- a/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc +++ b/libstdc++-v3/testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc @@ -221,8 +221,8 @@ main() test02(); test03(); test04(); - test05(); #ifndef SIMULATOR_TEST + test05(); test06(); #endif }