You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What version of Go are you using (go version)? go1.5.3
What operating system and processor architecture are you using? Linux, amd64
What did you do? benchmarked == vs bytes.Equal for array types
What did you expect to see? == be as fast as or faster than bytes.Equal
What did you see instead? == is slower than bytes.Equal
Given:
type A [16]byte
var a1, a2 A
a1== a2 is slower than bytes.Equal(a1[:], a2[:]) with the regular gc compiler.
It seems the same optimizations that have been applied to bytes.Equal could be applied to the code generated by the compiler (or the compiler could simply call the equivalent of the bytes.Equal function).
I also ran the test with 8, 128, and 1024 byte arrays (as well as 16 bytes). The source code is a_test.go.txt.
As a side note, with gccgo the results are the opposite, == is faster than bytes.Equal. bytes.Equal with gccgo is also slower than bytes.Equal with the regular gc compiler.
The text was updated successfully, but these errors were encountered:
I think the difference is just call overhead. bytes.Equal directly calls into memeqbody. == calls memequal, which calls memeq, which calls memeqbody. (Both memequal and bytes.Equal have the shortcut check if the slices are aliased.)
We could short-circuit one of those trampolines, sure.
They do the same thing, except memequal also has the short-circuit
check if the two pointers are equal.
A) We might as well always do the short-circuit check, it is only 2 instructions.
B) The extra function call (memequal->memeq) is expensive.
benchmark old ns/op new ns/op delta
BenchmarkArrayEqual-8 8.56 5.31 -37.97%
No noticeable affect on the former memeq user (maps).
Fixesgolang#14302
Change-Id: I85d1ada59ed11e64dd6c54667f79d32cc5f81948
Reviewed-on: https://go-review.googlesource.com/19843
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
What version of Go are you using (go version)? go1.5.3
What operating system and processor architecture are you using? Linux, amd64
What did you do? benchmarked
==
vsbytes.Equal
for array typesWhat did you expect to see?
==
be as fast as or faster thanbytes.Equal
What did you see instead?
==
is slower thanbytes.Equal
Given:
a1== a2
is slower thanbytes.Equal(a1[:], a2[:])
with the regular gc compiler.On my machine, the two benchmarks:
result in times of:
It seems the same optimizations that have been applied to bytes.Equal could be applied to the code generated by the compiler (or the compiler could simply call the equivalent of the bytes.Equal function).
I also ran the test with 8, 128, and 1024 byte arrays (as well as 16 bytes). The source code is
a_test.go.txt.
The results:
As a side note, with gccgo the results are the opposite,
==
is faster thanbytes.Equal
.bytes.Equal
with gccgo is also slower thanbytes.Equal
with the regular gc compiler.The text was updated successfully, but these errors were encountered: