At the very least, this may be a useful data point for #27400.

Yep, this is in part #27400. When I sprinkle the benchmarks with go:noinline fairy dust, the dramatic difference in one direction becomes a smaller difference in the other direction:

package main

import (
	"bytes"
	"runtime"
	"testing"
	"unicode/utf8"
)

//go:noinline
func utf8EncodeRune(b []byte, r rune) int {
	return utf8.EncodeRune(b[:], r)
}

//go:noinline
func stringEncodeRune(b []byte, r rune) int {
	return copy(b[:], string(r))
}

func BenchmarkEncodeRune(b *testing.B) {
	b.ReportAllocs()

	const r = '💩'
	for n := b.N; n > 0; n-- {
		b := [utf8.UTFMax]byte{}
		n := utf8EncodeRune(b[:], r)
		runtime.KeepAlive(b)
		runtime.KeepAlive(n)
	}
}

func BenchmarkCopyConvertedRune(b *testing.B) {
	b.ReportAllocs()

	const r = '💩'
	for n := b.N; n > 0; n-- {
		b := [utf8.UTFMax]byte{}
		n := stringEncodeRune(b[:], r)
		runtime.KeepAlive(b)
		runtime.KeepAlive(n)
	}
}

$ go test -bench=. .
goos: linux
goarch: amd64
pkg: example
cpu: Intel(R) Xeon(R) CPU E5-1650 v4 @ 3.60GHz
BenchmarkEncodeRune-12          154603531                7.458 ns/op           0 B/op          0 allocs/op
BenchmarkByteConvert-12         112319052               10.42 ns/op            0 B/op          0 allocs/op
PASS
ok      example 3.815s

I don't think this is a fair benchmark. Most of BenchmarkByteConvert compiles away.
In particular, BenchmarkByteConvert never needs to compute the number of bytes in the encoded rune.

KeepAlive isn't really doing what you think it is doing. It doesn't force its argument to be calculated. It only forces any pointers it contains to be treated as live. When the argument is a stack-allocated pointer-free thing (like b) it is a no-op.

KeepAlive isn't really doing what you think it is doing. It doesn't force its argument to be calculated. It only forces any pointers it contains to be treated as live. When the argument is a stack-allocated pointer-free thing (like b) it is a no-op.

That's fair — but is also a pretty strong argument that testing.B is not measuring what it appears to be measuring, which is certainly a usability issue with the benchmarking API. Writing a correct benchmark should not require users to sprinkle their code with magic comments.

I'm sympathetic, but not sure what the fix might be. Sometimes you want to benchmark the fully-optimized code, including any dead code elimination.

Generally any benchmark with "_ = " in it is ripe for dead code elimination that maybe wasn't intended. Certainly fixing #27400 would help.

@randall77 For a few years I have been under the impression that runtime.KeepAlive could be used exactly for this purpose based on your comment here.

I think we need a testing.Use(v interface{}) or something (with compiler coordination).

@cespare So I think I misspoke a bit here:

It doesn't force its argument to be calculated.

It does force its argument to be generated, in the sense that the value must be available at the KeepAlive point. But when the thing it is calculating is a compile-time constant (like len(b) or the contents of b in OP's code), it doesn't really mean the value must be calculated. For instance, everything in BenchmarkByteConvert could be lifted outside the loop.

In this case I suspect that the problem may be on the input side rather than the output side.

The input r is a constant, so if the compiler applies enough constant-propagation it can just stick the results directly into the destination variables.