Bug 116072 - [15 Regression] 4.5% slowdown of 447.dealII on aarch64
Summary: [15 Regression] 4.5% slowdown of 447.dealII on aarch64
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 15.0
: P3 normal
Target Milestone: 15.0
Assignee: Not yet assigned to anyone
URL:
Keywords: needs-bisection
Depends on:
Blocks: spec
  Show dependency treegraph
 
Reported: 2024-07-24 12:04 UTC by Filip Kastl
Modified: 2024-08-09 08:54 UTC (History)
2 users (show)

See Also:
Host: aarch64-gnu-linux
Target: aarch64-gnu-linux
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Kastl 2024-07-24 12:04:42 UTC
As seen here

https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=588.140.0

there was a 4.5% exec time slowdown of the 447.dealII SPEC 2006 benchmark between commits

r15-1803-g038d64f62271dd
r15-1889-gf90ca62566c1d2

when run with -Ofast -march=native -flto on an aarch64 Ampere Altra - Neoverse N1 machine.
Comment 1 Andrew Pinski 2024-07-24 15:55:53 UTC
I am suspecting it is the std::find changes (e.g r15-1857). I did hear that libc++'s usage of memchr was slowering for SPEC 2006 on aarch64 before and dealII is C++ code after all.
Comment 2 Andrew Pinski 2024-07-24 21:48:41 UTC
Also what glibc version is on the system? Since if it is std::find that is causing the regression memchr was improved in the last year or so in glibc.
Comment 3 Filip Kastl 2024-07-25 09:25:21 UTC
The machine in question has glibc 2.36 so the benchmark is running without this memchr improvement. We intend to update that machine sometime in the next 3 months. I can get back to this bug when we do that and see if the update gets rid of this slowdown.
Comment 4 Filip Kastl 2024-08-07 07:26:41 UTC
Hmm. The slowdown disappeared again. The measurements went back to their original values. I'll mark this PR as WORKSFORME if there are no objections.

Btw we upgraded the machine's glibc. That happened after the slowdown disappeared. It didn't seem to affect the benchmark exec time. See the graph I sent originally. The orange line represents the upgrade.
Comment 5 Filip Kastl 2024-08-09 08:54:13 UTC
Marking as WORKSFORME.