#2817 Change proposal: Add -fno-omit-frame-pointer to default compilation flags
Opened 2 months ago by bcotton. Modified 3 days ago

Fedora will add -fno-omit-frame-pointer to the default C/C++ compilation flags, which will improve the effectiveness of profiling and debugging tools.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed.
See the FESCo ticket policy and the Changes policy for more information.


I am open to the possibility that the system-wide performance impact may be negligible, but I am concerned that we do not really know if that is the case or not. Some benchmarks for similar changes are mentioned in the proposal, but they are specialized (Firefox JIT) and/or difficult to reproduce (proprietary internal workloads).

I am not sure we should commit to this change without something like a mini mass rebuild into COPR as suggested in the devel thread, with a well-documented benchmarking effort across various applications and workloads.

Allowing individual packagers to opt out after the real mass rebuild is a welcome and important part of the proposal, but it does not really address the risk of system-wide performance regressions—most individual packagers won’t be prepared to organize their own private package-specific benchmarks.

I’m just now catching up on devel list discussion regarding a recent Phoronix article on the topic. I haven’t formed an opinion on the results yet, but I’m happy to see some concrete benchmarking efforts and will continue to follow the discussion closely.

The performance side worries me on this one, but it ends up being a trade off that we must weigh. A performance reduction, even a small one, affects every user in some way. I would venture to guess that profiling and debugging is done by a relatively small percentage of Fedora users.

If someone was having difficulty with debugging/profiling an application, couldn't they temporarily add -fno-omit-frame-pointer to the spec file and rebuild it? (I'm absolutely not an expert in compilers, so someone please correct me if I am missing something important.)

If someone was having difficulty with debugging/profiling an application, couldn't they temporarily add -fno-omit-frame-pointer to the spec file and rebuild it? (I'm absolutely not an expert in compilers, so someone please correct me if I am missing something important.)

I hope the change owners will correct me if I’m wrong, but as I understand it the goal is to better support profiling of large applications with perf and similar sampling profilers, without having to rebuild the entire dependency tree in order to get detailed insight into time spent in libraries.

On behalf of the Red Hat GCC team: we are strongly against this change (chiefly for performance reasons). Sorry.

On behalf of the Red Hat GCC team: we are strongly against this change (chiefly for performance reasons). Sorry.

Your input is appreciated!

This is what I worry about most: a performance reduction that affects nearly everyone that makes debugging and profiling more difficult for a smaller number of users. I've been on both ends of these issues before and I lean towards maintaining our current performance.

After a week, there are no votes, but the two FESCo members who have commented appear to be leaning toward -1, so I'm tagging this for the next meeting.

Metadata Update from @bcotton:
- Issue tagged with: meeting

2 months ago

On behalf of the Red Hat GCC team: we are strongly against this change (chiefly for performance reasons). Sorry.

It'd be great if you could provide some extra context here. Can you quantify the performance reasons? Is there a specific performance threshold where this change would be acceptable?

After a week, there are no votes...

Let me explicitly vote -1 for now to avoid autoapproval.

It'd be great if you could provide some extra context here. Can you quantify the performance reasons? Is there a specific performance threshold where this change would be acceptable?

I believe the proof that -fno-omit-frame-pointer does not hurt generated code performance should be done by people who are proposing this feature. The performance impact should have been reported with the proposal from the start.

SPEC2017 is the most credible benchmark for compiler people to measure the performance. For the context, according to my observations 1% performance improvement for SPEC usually requires 1 year of work for all GCC community.

One can say that we can ignore 1% performance improvement because it is insignificant. I can give a counter-argument: assuming 10% of all electricity is consumed by computers 1% performance improvement in energy proportiinal computing would mean saving 20TWH annually.

This was discussed during today's FESCo meeting:
ACTION: DaanDeMeyer to add more information to the proposal

See the logs for lots of interesting discussion (https://meetbot.fedoraproject.org/fedora-meeting/2022-07-05/fesco.2022-07-05-17.00.log.html).

Metadata Update from @zbyszek:
- Issue untagged with: meeting

a month ago

Some benchmarks for similar changes are mentioned in the proposal, but they are specialized (Firefox JIT) and/or difficult to reproduce (proprietary internal workloads).

As @decathorpe has pointed out on the mailing list, the benchmarks also only build the leaf applications with frame pointers and not the entire distribution, so they do not actually measure the complete performance impact (but in fact most likely significantly underestimate it).

Added more details to the proposal on the different use cases. Will focus on a more thorough benchmark of Fedora next, now that I've finished trying to reproduce the phoronix results.

Status update, I'm working on the benchmarks but I'll likely need until next week to finish them properly (https://github.com/DaanDeMeyer/fpbench)

In addition to his comments on the mailing list, Christian (sysprof maintainer) posted a very concise summary of the problem for profilers in this comment.

Shall we check in on this in the meeting? If there's no new info we can revisit another week out.

Metadata Update from @kevin:
- Issue tagged with: meeting

a month ago

I'm still working on the benchmarks, I'm going to do my best to finish them by next week's meeting

Given that @daandemeyer needs more time, but the F37 mass rebuild is scheduled to start tomorrow, would it make sense to withdraw this Change proposal for Fedora 37, and resubmit it for Fedora 38, with more complete data wrt/ performance impact? I don't think it would make much sense to push a change in default compiler flags after the mass rebuild.

That seems like the best way to go, I still plan to finish the benchmarks, but the proposal itself can be moved to F38.

Will remove meeting keyword and review this when more data is available.

Metadata Update from @kevin:
- Issue untagged with: meeting

a month ago

Metadata Update from @bcotton:
- Issue set to the milestone: Fedora Linux 38 (was: Fedora Linux 37)

a month ago

Metadata Update from @churchyard:
- Issue tagged with: stalled

3 days ago

Login to comment on this ticket.

Metadata