From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 54BE13858D35 for ; Fri, 9 Jun 2023 20:40:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 54BE13858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686343231; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r4u0dhlEfPEVKX+ehQq3aYKKY6/fKw3SDqA5pmKsI6Y=; b=JzYM+trnJXyEATS/TQdt5dlLezLxSZOWHPCFIX7A4g1Wl/g3dVKL+OxEZIRJyEpnc5aiBp 1YQ42xPq+EvEn6bMfGn0euEPWu9ybGI6n7yV3tpvmmAVbmaIr+rwN5gJ+zop8guaKus2KK 1y/wRaNKIfpb3w2ejtT84I+5jSCB6bM= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-501-kIV99aRkPKGsQP4B-CrrXg-1; Fri, 09 Jun 2023 16:40:29 -0400 X-MC-Unique: kIV99aRkPKGsQP4B-CrrXg-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2b1b630bb2bso14751131fa.2 for ; Fri, 09 Jun 2023 13:40:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686343228; x=1688935228; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZPa/qiC6JgZ5Jb94LYQFKizdGuGx/m0XWwHE8xGk2wA=; b=RjB+mZ6Nym0/l6PCAl0SWf/GOBTW0QeEj8+RvmuAsevgC7nQn36tPq3WDGGp7T3rcF FtWePx7ZEu0RKHE0tXX5nNeNgCjXonPplcLn5ykDGISqtyhVCTwLRrRQl6MLLAUxUq3U YyDP2gvCsWNjIvKwR4tVj+Py4abskTvrD+EudGKT7ji0weKlKsuXRpNrgP5eSzshMfo8 6MjDrpplYy3cDt50fn1VUnfr70ok7i0Yn+qwwAAWlf8jvU7E0yI1O0TQUgHK5MfnnQUC yHR4se+B/LWzaJcJ9MosyWHUih/tEGX8/ktkLd54QR1jgwa7w6tJQPyjBETmcRNvqYr8 k3Zw== X-Gm-Message-State: AC+VfDyoRq+NDUjmsdknEAOBIuyvIh7VsGvBD4NMxF7jAtk087npYOyY VPknSeSoDOG9vDMJWq8zAcbSco1oJP3CuSMVacVdnuYX/9N9ek5k2khLjYQdz7RoSCVfjGbK/bH XwVMp1v4/oJLDZdUZMFGpuDXMXLabSF7EbA== X-Received: by 2002:a2e:7c01:0:b0:2b1:e53a:ad4e with SMTP id x1-20020a2e7c01000000b002b1e53aad4emr1602478ljc.45.1686343228379; Fri, 09 Jun 2023 13:40:28 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ42mKcr1jG7ziN5JvsOMQer6EMI8ye3Y5UuU51Vq//j4BxJgOTTbx7tlo2Nf4hdBbd8Ma5RNzbZUGDC1IvV1QI= X-Received: by 2002:a2e:7c01:0:b0:2b1:e53a:ad4e with SMTP id x1-20020a2e7c01000000b002b1e53aad4emr1602471ljc.45.1686343227980; Fri, 09 Jun 2023 13:40:27 -0700 (PDT) MIME-Version: 1.0 References: <20230609162026.CC34320433@pchp3.se.axis.com> In-Reply-To: <20230609162026.CC34320433@pchp3.se.axis.com> From: Jonathan Wakely Date: Fri, 9 Jun 2023 21:40:15 +0100 Message-ID: Subject: Re: Splitting up 27_io/basic_istream/ignore/wchar_t/94749.cc (takes too long) To: Hans-Peter Nilsson Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="00000000000012e79405fdb861af" X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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 List-Id: --00000000000012e79405fdb861af Content-Type: multipart/alternative; boundary="00000000000012e79305fdb861ad" --00000000000012e79305fdb861ad Content-Type: text/plain; charset="UTF-8" On Fri, 9 Jun 2023 at 17:20, Hans-Peter Nilsson wrote: > Hi! > > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes > about 10 minutes to run for cris-elf in the "gdb simulator" > here on my arguably way-past-retirement machine (and it > looks like it gained a minute with LRA). I've seen it > timing out every now and then on busy days with load > > `nproc`. Usually it happens some time after I've forgot > about why. :) > > It has had some performance surgery before (pruning for > simulators, doubling timeout for ilp32). I'd probably just > try cutting along the function boundaries and keep those > parts separate that have >1 min execution time. > 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. test05 extracts INT_MAX characters from a stream, which is a LOT of work. It doesn't actually read those from a file, the "stream" is a custom streambuf that contains a buffer of millions of wchar_t and "reading" from the stream just increments a counter into that buffer. But we do have to allocate memory for that buffer and then zero-init that buffer. That's a lot of cycles. Then once we've done that, we need to keep looping until we overflow a 32-bit counter (we don't increment by 1 every loop, so it overflows pretty quickly). Then we do it again and again and again! Each time takes about half a second for me. 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? 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 test06 is the really slow part, that takes 10+ seconds for me. But that entire function should already be skipped for simulators. 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. --00000000000012e79305fdb861ad-- --00000000000012e79405fdb861af Content-Type: text/plain; charset="US-ASCII"; name="patch.txt" Content-Disposition: attachment; filename="patch.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lip0ufkn0 ZGlmZiAtLWdpdCBhL2xpYnN0ZGMrKy12My90ZXN0c3VpdGUvMjdfaW8vYmFz aWNfaXN0cmVhbS9pZ25vcmUvd2NoYXJfdC85NDc0OS5jYyBiL2xpYnN0ZGMr Ky12My90ZXN0c3VpdGUvMjdfaW8vYmFzaWNfaXN0cmVhbS9pZ25vcmUvd2No YXJfdC85NDc0OS5jYwppbmRleCA2NWUwYTMyNmMxMC4uMDQwZTk0YWE0ZDYg MTAwNjQ0Ci0tLSBhL2xpYnN0ZGMrKy12My90ZXN0c3VpdGUvMjdfaW8vYmFz aWNfaXN0cmVhbS9pZ25vcmUvd2NoYXJfdC85NDc0OS5jYworKysgYi9saWJz dGRjKystdjMvdGVzdHN1aXRlLzI3X2lvL2Jhc2ljX2lzdHJlYW0vaWdub3Jl L3djaGFyX3QvOTQ3NDkuY2MKQEAgLTg5LDcgKzg5LDcgQEAgc3RydWN0IGJ1 ZmYgOiBzdGQ6OmJhc2ljX3N0cmVhbWJ1Zjx0eXBlbmFtZSBUOjpjaGFyX3R5 cGUsIFQ+CiAgIHR5cGVkZWYgc3RkOjpzdHJlYW1zaXplCQkgIHN0cmVhbXNp emU7CiAgIHR5cGVkZWYgc3RkOjpudW1lcmljX2xpbWl0czxzdHJlYW1zaXpl PiBsaW1pdHM7CiAKLSAgYnVmZigpIDogY291bnQoMCksIGJ1ZigpIHsgfQor ICBidWZmKCkgOiBjb3VudCgwKSwgbm9uemVyb19jaGFycygpLCBidWYoKSB7 IH0KIAogICBpbnRfdHlwZSB1bmRlcmZsb3coKQogICB7CkBAIC0xMTIsMTIg KzExMiwyMyBAQCBzdHJ1Y3QgYnVmZiA6IHN0ZDo6YmFzaWNfc3RyZWFtYnVm PHR5cGVuYW1lIFQ6OmNoYXJfdHlwZSwgVD4KICAgICAgIGJ1ZltoZWFkcm9v bSsxXSA9IEwnMyc7CiAgICAgICB0aGlzLT5zZXRnKGJ1ZiwgYnVmLCBidWYg KyBoZWFkcm9vbSArIDIpOwogICAgICAgY291bnQgPSBsaW1pdHM6Om1heCgp OworICAgICAgbm9uemVyb19jaGFycyA9IGhlYWRyb29tIC0gMTsKICAgICB9 CiAKICAgICByZXR1cm4gYnVmWzBdOwogICB9CiAKKyAgdm9pZCByZXNldCgp CisgIHsKKyAgICBidWZbbm9uemVyb19jaGFyc10gPSBjaGFyX3R5cGUoKTsK KyAgICBidWZbbm9uemVyb19jaGFycysxXSA9IGNoYXJfdHlwZSgpOworICAg IGJ1Zltub256ZXJvX2NoYXJzKzJdID0gY2hhcl90eXBlKCk7CisgICAgbm9u emVyb19jaGFycyA9IDA7CisgICAgY291bnQgPSAwOworICB9CisKICAgc3Ry ZWFtc2l6ZSBjb3VudDsKKyAgc3RyZWFtc2l6ZSBub256ZXJvX2NoYXJzOwog CiAgIHN0YXRpYyBjb25zdCBzdHJlYW1zaXplIGJ1ZnN6ID0gMjA0OCA8PCBs aW1pdHM6OmRpZ2l0czEwOwogICBjaGFyX3R5cGUgYnVmW2J1ZnN6ICsgMl07 CkBAIC0xMzIsNyArMTQzLDggQEAgdGVzdDA1KCkKIAogICB0eXBlZGVmIHN0 ZDo6Y2hhcl90cmFpdHM8Qz4gVDsKIAotICBzdGQ6OmJhc2ljX2lzdHJlYW08 QywgVD4gaW4obmV3IGJ1ZmY8VD4pOworICBidWZmPFQ+KiBwYnVmID0gbmV3 IGJ1ZmY8VD47CisgIHN0ZDo6YmFzaWNfaXN0cmVhbTxDLCBUPiBpbihwYnVm KTsKIAogICBpbi5pZ25vcmUoc3RkOjpudW1lcmljX2xpbWl0czxzdGQ6OnN0 cmVhbXNpemU+OjptYXgoKSwgTCcxJyk7CiAgIFZFUklGWShpbi5nb29kKCkp OwpAQCAtMTQxLDcgKzE1Myw5IEBAIHRlc3QwNSgpCiAgIFZFUklGWShpbi5n ZXQoKSA9PSBMJzMnKTsKICAgVkVSSUZZKGluLmdldCgpID09IFQ6OmVvZigp KTsKIAotICBkZWxldGUgaW4ucmRidWYobmV3IGJ1ZmY8VD4pOworICBwYnVm LT5yZXNldCgpOworICBpbi5jbGVhcigpOworICBWRVJJRlkoaW4uZ2NvdW50 KCkgPT0gMCk7CiAKICAgaW4uaWdub3JlKHN0ZDo6bnVtZXJpY19saW1pdHM8 c3RkOjpzdHJlYW1zaXplPjo6bWF4KCksIEwnMicpOwogICBWRVJJRlkoaW4u Z29vZCgpKTsKQEAgLTE1MCw3ICsxNjQsOSBAQCB0ZXN0MDUoKQogICBWRVJJ RlkoaW4uZ2V0KCkgPT0gTCczJyk7CiAgIFZFUklGWShpbi5nZXQoKSA9PSBU Ojplb2YoKSk7CiAKLSAgZGVsZXRlIGluLnJkYnVmKG5ldyBidWZmPFQ+KTsK KyAgcGJ1Zi0+cmVzZXQoKTsKKyAgaW4uY2xlYXIoKTsKKyAgVkVSSUZZKGlu Lmdjb3VudCgpID09IDApOwogCiAgIGluLmlnbm9yZShzdGQ6Om51bWVyaWNf bGltaXRzPHN0ZDo6c3RyZWFtc2l6ZT46Om1heCgpLCBMJzMnKTsKICAgVkVS SUZZKGluLmdvb2QoKSk7CkBAIC0xNTgsNyArMTc0LDkgQEAgdGVzdDA1KCkK ICAgVkVSSUZZKGluLmdjb3VudCgpID09IHN0ZDo6bnVtZXJpY19saW1pdHM8 c3RkOjpzdHJlYW1zaXplPjo6bWF4KCkpOwogICBWRVJJRlkoaW4uZ2V0KCkg PT0gVDo6ZW9mKCkpOwogCi0gIGRlbGV0ZSBpbi5yZGJ1ZihuZXcgYnVmZjxU Pik7CisgIHBidWYtPnJlc2V0KCk7CisgIGluLmNsZWFyKCk7CisgIFZFUklG WShpbi5nY291bnQoKSA9PSAwKTsKIAogICBpbi5pZ25vcmUoc3RkOjpudW1l cmljX2xpbWl0czxzdGQ6OnN0cmVhbXNpemU+OjptYXgoKSwgTCc0Jyk7CiAg IFZFUklGWShpbi5lb2YoKSk7CkBAIC0xNjYsNyArMTg0LDggQEAgdGVzdDA1 KCkKICAgVkVSSUZZKGluLmdjb3VudCgpID09IHN0ZDo6bnVtZXJpY19saW1p dHM8c3RkOjpzdHJlYW1zaXplPjo6bWF4KCkpOwogICBWRVJJRlkoaW4uZ2V0 KCkgPT0gVDo6ZW9mKCkpOwogCi0gIGRlbGV0ZSBpbi5yZGJ1ZigwKTsKKyAg aW4ucmRidWYoMCk7CisgIGRlbGV0ZSBwYnVmOwogfQogCiB2b2lkCkBAIC0x NzcsNyArMTk2LDggQEAgdGVzdDA2KCkKIAogICB0eXBlZGVmIF9fZ251X2N4 eDo6Y2hhcl90cmFpdHM8Qz4gVDsKIAotICBzdGQ6OmJhc2ljX2lzdHJlYW08 QywgVD4gaW4obmV3IGJ1ZmY8VD4pOworICBidWZmPFQ+KiBwYnVmID0gbmV3 IGJ1ZmY8VD47CisgIHN0ZDo6YmFzaWNfaXN0cmVhbTxDLCBUPiBpbihwYnVm KTsKIAogICBpbi5pZ25vcmUoc3RkOjpudW1lcmljX2xpbWl0czxzdGQ6OnN0 cmVhbXNpemU+OjptYXgoKSwgTCcxJyk7CiAgIFZFUklGWShpbi5nb29kKCkp OwpAQCAtMTg2LDcgKzIwNiw5IEBAIHRlc3QwNigpCiAgIFZFUklGWShpbi5n ZXQoKSA9PSBMJzMnKTsKICAgVkVSSUZZKGluLmdldCgpID09IFQ6OmVvZigp KTsKIAotICBkZWxldGUgaW4ucmRidWYobmV3IGJ1ZmY8VD4pOworICBwYnVm LT5yZXNldCgpOworICBpbi5jbGVhcigpOworICBWRVJJRlkoaW4uZ2NvdW50 KCkgPT0gMCk7CiAKICAgaW4uaWdub3JlKHN0ZDo6bnVtZXJpY19saW1pdHM8 c3RkOjpzdHJlYW1zaXplPjo6bWF4KCksIEwnMicpOwogICBWRVJJRlkoaW4u Z29vZCgpKTsKQEAgLTE5NSw3ICsyMTcsOSBAQCB0ZXN0MDYoKQogICBWRVJJ RlkoaW4uZ2V0KCkgPT0gTCczJyk7CiAgIFZFUklGWShpbi5nZXQoKSA9PSBU Ojplb2YoKSk7CiAKLSAgZGVsZXRlIGluLnJkYnVmKG5ldyBidWZmPFQ+KTsK KyAgcGJ1Zi0+cmVzZXQoKTsKKyAgaW4uY2xlYXIoKTsKKyAgVkVSSUZZKGlu Lmdjb3VudCgpID09IDApOwogCiAgIGluLmlnbm9yZShzdGQ6Om51bWVyaWNf bGltaXRzPHN0ZDo6c3RyZWFtc2l6ZT46Om1heCgpLCBMJzMnKTsKICAgVkVS SUZZKGluLmdvb2QoKSk7CkBAIC0yMDMsNyArMjI3LDkgQEAgdGVzdDA2KCkK ICAgVkVSSUZZKGluLmdjb3VudCgpID09IHN0ZDo6bnVtZXJpY19saW1pdHM8 c3RkOjpzdHJlYW1zaXplPjo6bWF4KCkpOwogICBWRVJJRlkoaW4uZ2V0KCkg PT0gVDo6ZW9mKCkpOwogCi0gIGRlbGV0ZSBpbi5yZGJ1ZihuZXcgYnVmZjxU Pik7CisgIHBidWYtPnJlc2V0KCk7CisgIGluLmNsZWFyKCk7CisgIFZFUklG WShpbi5nY291bnQoKSA9PSAwKTsKIAogICBpbi5pZ25vcmUoc3RkOjpudW1l cmljX2xpbWl0czxzdGQ6OnN0cmVhbXNpemU+OjptYXgoKSwgTCc0Jyk7CiAg IFZFUklGWShpbi5lb2YoKSk7CkBAIC0yMTEsNyArMjM3LDggQEAgdGVzdDA2 KCkKICAgVkVSSUZZKGluLmdjb3VudCgpID09IHN0ZDo6bnVtZXJpY19saW1p dHM8c3RkOjpzdHJlYW1zaXplPjo6bWF4KCkpOwogICBWRVJJRlkoaW4uZ2V0 KCkgPT0gVDo6ZW9mKCkpOwogCi0gIGRlbGV0ZSBpbi5yZGJ1ZigwKTsKKyAg aW4ucmRidWYoMCk7CisgIGRlbGV0ZSBwYnVmOwogfQogCiBpbnQK --00000000000012e79405fdb861af--