Navigation Menu

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

Jump to bottom

sync: performance drop with mutex #5183

Closed
egonelbre opened this issue Apr 2, 2013 · 2 comments
Closed

sync: performance drop with mutex #5183

egonelbre opened this issue Apr 2, 2013 · 2 comments
Labels
FrozenDueToAge

Comments

@egonelbre
Copy link
Contributor 

What steps will reproduce the problem?
http://play.golang.org/p/9xuV2BXGoK

1. run the example locally a few times

What do you see?

Channel lock:
rtn=2 cpu=1:     769
rtn=2 cpu=2:     944
rtn=2 cpu=3:     878
rtn=2 cpu=8:     784
rtn=3 cpu=1:     769
rtn=3 cpu=2:     819
rtn=3 cpu=3:     814
rtn=3 cpu=8:     793

Mutex:
rtn=2 cpu=1:     220
rtn=2 cpu=2:     13061
rtn=2 cpu=3:     5917
rtn=2 cpu=8:     788
rtn=3 cpu=1:     219
rtn=3 cpu=2:     1019
rtn=3 cpu=3:     1038
rtn=3 cpu=8:     1101

Quite often you can see a high performance drop (10x) when using a mutex with GOMAXPROCS
= 2/3 and 2 goroutines.

When using "go test" it seems to happen more consistently
(http://play.golang.org/p/5BYS-LEAFY).

Which compiler are you using (5g, 6g, 8g, gccgo)?  6g

Which operating system are you using? Windows 7, 64bit

Which version are you using?  (run 'go version') go version devel +7d736eaa75da Tue Apr
02 15:08:28 2013 +1100 windows/amd64

Please provide any additional information below.

I tested it against go1.0.3 and it seems to work fine.
@dvyukov
Copy link
Member

dvyukov commented Apr 4, 2013

Comment 1:

Looks like contention.
Chaotic performance drops are expected under contention.

Status changed to WorkingAsIntended.

@dvyukov
Copy link
Member

dvyukov commented Apr 4, 2013

Comment 2:

If you are interested why chan does not have the same issue, runtime handles chan's in a
special way (active/passive spinning + thread parking instead of goroutine parking),
because it knowns that the critical section is bounded and small. For sync.Mutex it does
not have any knowledge as to critical section size.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@egonelbre @dvyukov @gopherbot