Small performance regression in x/crypto XChaCha20 implementation

[zp]

When building gocryptfs from current master source 9958b63, there is a small? (might vary cpu to cpu) performance regression with XChaCha20-Poly1305-Go

speed benchmark with 2.4.0

gocryptfs v2.4.0; go-fuse [vendored]; 2023-10-12 go1.21.3 linux/amd64
cpu: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz; no AES acceleration
AES-GCM-256-OpenSSL              228.65 MB/s    (selected in auto mode)
AES-GCM-256-Go                    61.51 MB/s
AES-SIV-512-Go                    46.20 MB/s
XChaCha20-Poly1305-OpenSSL       485.02 MB/s
XChaCha20-Poly1305-Go            728.97 MB/s    (selected in auto mode)

speed benchmark with 9958b63

gocryptfs v2.4.0-15-g9958b63; go-fuse [vendored]; 2024-03-03 go1.22.0 linux/amd64
cpu: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz; no AES acceleration
AES-GCM-256-OpenSSL              232.79 MB/s    (selected in auto mode)
AES-GCM-256-Go                    63.22 MB/s
AES-SIV-512-Go                    48.48 MB/s
XChaCha20-Poly1305-OpenSSL       490.74 MB/s
XChaCha20-Poly1305-Go            616.01 MB/s    (selected in auto mode)

Diagnosing this it appears that x/crypto has locked certain cpu acceleration/optimization behind proper flags, specifically this commit, as it was previously just always enabled (even if it wasn't actually supported by the cpu)

Go seems to build with GOAMD64=v1 by default, for what I assume is maximum compatibility

Building with GOAMD64=v2 re-enables the optimizations bringing it back to 2.4.0 performance

speed benchmark with 9958b63 and GOAMD64=v2

gocryptfs v2.4.0-15-g9958b63; go-fuse [vendored]; 2024-03-03 go1.22.0 linux/amd64
cpu: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz; no AES acceleration
AES-GCM-256-OpenSSL              232.84 MB/s    (selected in auto mode)
AES-GCM-256-Go                    62.21 MB/s
AES-SIV-512-Go                    49.58 MB/s
XChaCha20-Poly1305-OpenSSL       487.09 MB/s
XChaCha20-Poly1305-Go            727.68 MB/s    (selected in auto mode)

I propose to just build gocryptfs going forward with GOAMD64=v2 (at least for the static amd64 build on github releases), possibly providing a default v1 build for legacy support, as according to this chart v2 extensions date back to 2008.

[rfjakob]

GOAMD64=v2 sounds good. Care to add it build.bash and make a PR?

[rfjakob]

Reported to Go upstream as golang/go#67240