函数 crypto/cipher.xorBytes
实现字节切片之间的异或操作,并在CTR模式下的加密中被大量使用。标准库中的版本已经进行了大量优化,但仍有一些简单的优化缺失:
- 在 xor_generic.go 中的变量
supportUnaligned
应设置为与arm64
相等的 GOARCH。 - 该变量应设置为与 ARM 和 GOARM 等于 6 或 7(而不是 5)相等的 GOARCH。
- 当
supportsUnaligned
未设置时,当 src 和 dst 都是 wordSize 的倍数时,仍应调用快速版本(实际上这种情况发生得相当频繁,例如在加密一个新分配的切片时); - 当
supportsUnaligned
未设置,且 src 和 dst 对 wordSize 取模相等时,则应先对初始字节进行异或操作,然后在数组的其余部分上调用快速版本; - 理想情况下,应该有一个适用于 ARMv7 的 NEON 实现。
要点1到3相对简单,可以带来显著的好处。这与 #53021 有关。
5条答案
按热度按时间qqrboqgw1#
@jech - 第1点是不必要的,因为
xor_generic.go
中的go:build行已经排除了arm64(由于存在arm64 neon汇编实现)。但是对于其他几点,我非常肯定。尤其是第2点,我们目前在ARMv6/7上的一个性能关键函数上留下了显著的收益,而在这个函数中对齐访问是可以的。
关于golang在arm32上的慢速加密性能,有很多帖子提到,这是一个低风险的改进,可以带来很大的收益。
4xy9mtcn2#
CC @bradfitz
t40tm48m3#
See also #35381 .
mpbci0fu4#
@bcmills / @bradfitz / @jech - 我为32位ARM编写了NEON和非NEON版本的xorBytes。在xor_generic.go中,性能提高幅度很大,介于4倍到20倍之间。
鉴于32位ARM仍然是最受欢迎的物联网设备平台之一,遗憾的是,在加密库的xorBytes中,32位ARM是唯一未优化的平台,这可能是一个瓶颈函数。
因此,我非常愿意在这里创建一个PR,贡献优化后的32位NEON和非NEON ARM实现的xorBytes。这对于32位ARM上的一般加密性能来说可能是一个重大突破。但我希望首先得到一个信号,表明有接受这种PR的意愿,以免最终被丢进/dev/null。
sbdsn5lh5#
https://go.dev/cl/409394提到了这个问题:
crypto/cipher: add optimized assembly xorBytes for ARM (NEON + non-NEON)