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

A strange question for bool #39059

Closed
laomz opened this issue May 13, 2020 · 5 comments
Closed

A strange question for bool #39059

laomz opened this issue May 13, 2020 · 5 comments

Comments

@laomz
Copy link

laomz commented May 13, 2020

type BoolStruct struct {
	b1 bool
	b2 bool
	b3 bool
	b4 bool
	b5 bool
	b6 bool
	b7 bool
	b8 bool
	b  byte
}

func (bs *BoolStruct) DoSomething() {
	bs.b = DoSomethingForBool(bs.b1, bs.b2, bs.b3, bs.b4, bs.b5, bs.b6, bs.b7, bs.b8)
}

func DoSomethingForBool(b1 bool, b2 bool, b3 bool, b4 bool, b5 bool, b6 bool, b7 bool, b8 bool) byte {
	var b byte
	if b1 {
		//do something
		b++
	}
	if b2 {
		//do something
		b++
	}
	if b3 {
		//do something
		b++
	}
	if b4 {
		//do something
		b++
	}
	if b5 {
		//do something
		b++
	}
	if b6 {
		//do something
		b++
	}
	if b7 {
		//do something
		b++
	}
	if b8 {
		//do something
		b++
	}

	return b
}

var bsFalse = BoolStruct{
	b1: false,
	b2: false,
	b3: false,
	b4: false,
	b5: false,
	b6: false,
	b7: false,
	b8: false,
}

func BenchmarkBSFalse(b *testing.B) {
	for i := 0; i < b.N; i++ {
		bsFalse.DoSomething()
	}
}

var bsTrue = BoolStruct{
	b1: true,
	b2: true,
	b3: true,
	b4: true,
	b5: true,
	b6: true,
	b7: true,
	b8: true,
}

func BenchmarkBSTrue(b *testing.B) {
	for i := 0; i < b.N; i++ {
		bsTrue.DoSomething()
	}
}

BenchmarkBSFalse-6 502713746 7.17 ns/op 0 B/op 0 allocs/op
BenchmarkBSTrue-6 1000000000 2.17 ns/op 0 B/op 0 allocs/op

all false consume more time than all true, why?

@ianlancetaylor
Copy link
Contributor

When you are down to a few nanoseconds per operation, it could be the exact alignment of the code in memory, it could be the CPU's memory caching algorithm, it could be the branch predictor, it could be the phase of the moon. Microbenchmarking is hard.

We don't use the issue tracker to discuss issues like this. Use a forum instead. If you identify a problem in the compiler or assembler or linker, then by all means open an issue with details. But the odds are that this is effectively chance, and not something that can be fixed.

@randall77
Copy link
Contributor

Might be #35881

@laomz
Copy link
Author

laomz commented May 14, 2020

After a lot of testing, I have determined that it is not a memory alignment or cpu cache problem. And the results of repeated tests are the same, is this not strange?

@davecheney
Copy link
Contributor

I’d be suspicious of that benchmark, I think the compiler is optimising always some or all of the code under test.

@ianlancetaylor
Copy link
Contributor

Please use a forum, as described at https://golang.org/wiki/Questions. Thanks.

@golang golang locked and limited conversation to collaborators May 14, 2021
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

5 participants