Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/compile: add a optimization flag #47174

Closed
lemon37564 opened this issue Jul 13, 2021 · 3 comments
Closed

proposal: cmd/compile: add a optimization flag #47174

lemon37564 opened this issue Jul 13, 2021 · 3 comments
Labels
Projects
Milestone

Comments

@lemon37564
Copy link

@lemon37564 lemon37564 commented Jul 13, 2021

Description

Can we have a flag like //go: optimize that tells the compiler to do more optimizations for a specific function?
(like loop unrolling, tail call optimization and others)
I know the go compiler is concerned with compilation speed, so it doesn't try to generate the most efficient code.
But in my program, there is one function that takes up more than 30% of the total time, according to pprof, and I can reduce that by more than 20% by manually unrolling the loop, but the function inevitably becomes hard to read.
Optimizing a few functions may slightly increase compilation time, but will make the program run faster, especially when flag is passed to the bottleneck, meanwhile keeping the readability of code.

@gopherbot gopherbot added this to the Proposal milestone Jul 13, 2021
@ianlancetaylor ianlancetaylor changed the title proposal: add a optimization flag proposal: cmd/compile: add a optimization flag Jul 13, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Jul 13, 2021
@mpx
Copy link
Contributor

@mpx mpx commented Jul 14, 2021

I think targeted optimizations would be better handled via feedback-directed optimization (FDO) support.

Loading

@rsc
Copy link
Contributor

@rsc rsc commented Jul 14, 2021

As @mpx said, some kind of per-app feedback would work much better than //go:optimize.
Whether a function should be over-optimized depends on how it is used.
You might find that the most costly function is in a package you depend on,
whether a 'go get' package by someone else or a standard library package.
In both cases, you cannot easily edit the source code to add //go:optimize.
On the other hand, a per-build feedback file can list any function from anywhere.
We don't have that as an option today, but neither do we have //go:optimize.
And if we add //go:optimize we are stuck with it forever.
Better to unroll your loops for now and wait for the right long-term solution.

Loading

@lemon37564 lemon37564 closed this Jul 14, 2021
@rsc rsc moved this from Incoming to Declined in Proposals Oct 13, 2021
@rsc
Copy link
Contributor

@rsc rsc commented Oct 13, 2021

This proposal has been declined as retracted.
— rsc for the proposal review group

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants