public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "Mark_B53 at yahoo dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/108487] New: ~20-30x slowdown in populating std::vector from std::ranges::iota_view
Date: Fri, 20 Jan 2023 22:20:32 +0000	[thread overview]
Message-ID: <bug-108487-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108487

            Bug ID: 108487
           Summary: ~20-30x slowdown in populating std::vector from
                    std::ranges::iota_view
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Mark_B53 at yahoo dot com
  Target Milestone: ---

Using -std=c++20 -O3, comparing gcc 12.2 vs. gcc 10.3:
 * fn2 is 20-30x slower on gcc 12.2 (i.e. 2000-3000% more) 
 * fn1 is ~20% slower on gcc 12.2 

This test was run on an 52 core Intel Xeon Gold 6278C CPU.  Tests on
www.godbolt.org directionally align with these findings.  It seems the slowdown
was introduced in 10.4 & 11.1.  The trunk has identical performance to 12.2.

#include <vector>
#include <ranges>
#include <ctime>
#include <iostream>

__attribute__((noinline)) std::vector<int> fn1(int n)
{
    auto v = std::vector<int>(n);
    for(int i = 0; i != n; ++i)
        v[i] = i;
    return v;
}

__attribute__((noinline)) std::vector<int> fn2(int n)
{
    auto rng = std::ranges::iota_view{0, n};
    return std::vector<int>{rng.begin(), rng.end()};
}

int main() {
    int n = 100'000;
    int times = 100'000;

    auto t0 = std::clock();
    for (int i = 0; i < times; ++i)
        fn1(n);            
    auto t1 = std::clock();
    for (int i = 0; i < times; ++i)
        fn2(n);            
    auto t2 = std::clock();
    std::cout << t1 - t0 << '\n';
    std::cout << t2 - t1 << '\n';
    return 0;
}

P.S. 20% slowdown for a common vector population is still significant IMO.  I
am not sure that qualifies as a bug.  I did not file one on account of the
'fn1' slowdown.

             reply	other threads:[~2023-01-20 22:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 22:20 Mark_B53 at yahoo dot com [this message]
2023-01-21 11:48 ` [Bug tree-optimization/108487] [10/11/12/13 Regression] " amonakov at gcc dot gnu.org
2023-01-21 13:32 ` Mark_B53 at yahoo dot com
2023-01-21 15:38 ` [Bug libstdc++/108487] " amonakov at gcc dot gnu.org
2023-01-21 23:45 ` redi at gcc dot gnu.org
2023-01-21 23:50 ` redi at gcc dot gnu.org
2023-01-21 23:50 ` redi at gcc dot gnu.org
2023-01-22  3:07 ` Mark_B53 at yahoo dot com
2023-01-22 10:33 ` Mark_B53 at yahoo dot com
2023-01-22 17:14 ` redi at gcc dot gnu.org
2023-01-23  7:45 ` rguenth at gcc dot gnu.org
2023-03-27 11:03 ` rguenth at gcc dot gnu.org
2023-07-07 10:44 ` [Bug libstdc++/108487] [11/12/13/14 " rguenth at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-108487-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).