https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66004
Bug ID: 66004
Summary: [6 Regression]: performance of
26_numerics/random/negative_binomial_distribution/oper
ators/values.cc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: cris-elf
For r221618, this test took 34633750695 "basic clock cycles" in the CRIS
simulator. For r222742 (aka. "now"), it takes 40111446541 (same unit). This
is a performance regression of about 16% in less than 1.5 month! I noticed
because the test started to fail on my autotester machine during times of load,
when it has been previously silent. The cris-elf is a 32-bit soft-float
target.
Note that the situation is the opposite of that in PR65093.
I'm listing the libstdc++ component as the cause, will update as my
(low-intensity) investigation (which I guess will be mostly bisecting)
continues. It is also a likely culprit, with the recent work alluded to in
PR65093 (either further work or another side of the coin, of changes there
improving performance).
My first reaction, before checking for regression, was the test can and should
be split up as in PR65093. I still think it should, after the regression is
fixed.
(Revision r221618 happens to be the last regression-free revision for cris-elf;
after that no components outside the gcc repo have been updated.)
Relative performance numbers for other platforms at svn revisions near those
above would be interesting.
