Skip to content

runtime: GC performance regression #8625

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

Closed
dvyukov opened this issue Sep 1, 2014 · 3 comments
Closed

runtime: GC performance regression #8625

dvyukov opened this issue Sep 1, 2014 · 3 comments

Comments

@dvyukov
Copy link
Member

dvyukov commented Sep 1, 2014

According to perf dashboard, change "112570044 cmd/gc, runtime: treat slices and
strings like pointers in garbage collection"
(https://golang.org/cl/112570044) has lead to 10-20% GC performance degradation:

http://build.golang.org/perfdetail?commit=caab29a25f686946a383ec31d2ea6408265aa466&;commit0=6d5c17d94e9ddcd8ca450ac62f84cf9ddb436b65&builder=windows-amd64-perf&benchmark=http

It looks like some unlucky code generation issue. Probably replacing the switch with
if-else will restore the performance.
@gopherbot
Copy link
Contributor

Comment 1:

CL https://golang.org/cl/152170043 mentions this issue.

@gopherbot
Copy link
Contributor

Comment 2:

CL https://golang.org/cl/153990043 mentions this issue.

@dvyukov
Copy link
Member Author

dvyukov commented Oct 8, 2014

Comment 3:

This issue was closed by revision b8fdaaf.

Status changed to Fixed.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
The change contains 3 spot optimizations to scan loop:
1. Don't use byte vars, use uintptr's instead.
This seems to alleviate some codegen issue,
and alone accounts to a half of speedup.
2. Remove bitmap cache. Currently we cache only 1 byte,
so caching is not particularly effective anyway.
Removal of the cache simplifies code and positively affects regalloc.
3. Replace BitsMultiword switch with if and
do debug checks only in Debug mode.
I've benchmarked changes separately and ensured that
each of them provides speedup on top of the previous one.
This change as a whole fixes the unintentional regressions
of scan loop that were introduced during development cycle.
Fixes golang#8625.
Fixes golang#8565.

On go.benchmarks/garbage benchmark:
GOMAXPROCS=1
time:		-3.13%
cputime:	-3.22%
gc-pause-one:	-15.71%
gc-pause-total:	-15.71%

GOMAXPROCS=32
time:		-1.96%
cputime:	-4.43%
gc-pause-one:	-6.22%
gc-pause-total:	-6.22%

LGTM=khr, rsc
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/153990043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jun 26, 2018
The change contains 3 spot optimizations to scan loop:
1. Don't use byte vars, use uintptr's instead.
This seems to alleviate some codegen issue,
and alone accounts to a half of speedup.
2. Remove bitmap cache. Currently we cache only 1 byte,
so caching is not particularly effective anyway.
Removal of the cache simplifies code and positively affects regalloc.
3. Replace BitsMultiword switch with if and
do debug checks only in Debug mode.
I've benchmarked changes separately and ensured that
each of them provides speedup on top of the previous one.
This change as a whole fixes the unintentional regressions
of scan loop that were introduced during development cycle.
Fixes golang#8625.
Fixes golang#8565.

On go.benchmarks/garbage benchmark:
GOMAXPROCS=1
time:		-3.13%
cputime:	-3.22%
gc-pause-one:	-15.71%
gc-pause-total:	-15.71%

GOMAXPROCS=32
time:		-1.96%
cputime:	-4.43%
gc-pause-one:	-6.22%
gc-pause-total:	-6.22%

LGTM=khr, rsc
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/153990043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
The change contains 3 spot optimizations to scan loop:
1. Don't use byte vars, use uintptr's instead.
This seems to alleviate some codegen issue,
and alone accounts to a half of speedup.
2. Remove bitmap cache. Currently we cache only 1 byte,
so caching is not particularly effective anyway.
Removal of the cache simplifies code and positively affects regalloc.
3. Replace BitsMultiword switch with if and
do debug checks only in Debug mode.
I've benchmarked changes separately and ensured that
each of them provides speedup on top of the previous one.
This change as a whole fixes the unintentional regressions
of scan loop that were introduced during development cycle.
Fixes golang#8625.
Fixes golang#8565.

On go.benchmarks/garbage benchmark:
GOMAXPROCS=1
time:		-3.13%
cputime:	-3.22%
gc-pause-one:	-15.71%
gc-pause-total:	-15.71%

GOMAXPROCS=32
time:		-1.96%
cputime:	-4.43%
gc-pause-one:	-6.22%
gc-pause-total:	-6.22%

LGTM=khr, rsc
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/153990043
wheatman pushed a commit to wheatman/go-akaros that referenced this issue Jul 30, 2018
The change contains 3 spot optimizations to scan loop:
1. Don't use byte vars, use uintptr's instead.
This seems to alleviate some codegen issue,
and alone accounts to a half of speedup.
2. Remove bitmap cache. Currently we cache only 1 byte,
so caching is not particularly effective anyway.
Removal of the cache simplifies code and positively affects regalloc.
3. Replace BitsMultiword switch with if and
do debug checks only in Debug mode.
I've benchmarked changes separately and ensured that
each of them provides speedup on top of the previous one.
This change as a whole fixes the unintentional regressions
of scan loop that were introduced during development cycle.
Fixes golang#8625.
Fixes golang#8565.

On go.benchmarks/garbage benchmark:
GOMAXPROCS=1
time:		-3.13%
cputime:	-3.22%
gc-pause-one:	-15.71%
gc-pause-total:	-15.71%

GOMAXPROCS=32
time:		-1.96%
cputime:	-4.43%
gc-pause-one:	-6.22%
gc-pause-total:	-6.22%

LGTM=khr, rsc
R=golang-codereviews, khr
CC=golang-codereviews, rlh, rsc
https://golang.org/cl/153990043
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants