Switch back to upstream minio/sha256-simd

[lrettig]

We forked https://github.com/minio/sha256-simd into https://github.com/spacemeshos/sha256-simd to add spacemeshos/sha256-simd#2 but it was added upstream. We should probably switch back to the upstream repo - is there any reason to maintain a fork?

[fasmat]

I checked the following repositories:

• go-spacemesh
• merkle-tree
• poet

All have been updated recently to use the newest version of https://github.com/minio/sha256-simd. None of their dependencies use minio/sha256-smid or spacemeshos/sha256-smid.

Only post uses crypto/sha256 instead of minio/sha256-smid for its FastOracle function. If you agree I would update this to use the optimized library and then consider this ticket as done?

[fasmat]

As for why we are using https://github.com/minio/sha256-simd over crypto/sha256 in our code base:

On some systems we tested (specifically Mac M1) there is little to no performance gain over using the custom library (tests were performed by hashing 100 bytes of data):

goos: linux
goarch: arm64
BenchmarkHash/golang-6         	15897987	        75.88 ns/op	1317.93 MB/s	       0 B/op	       0 allocs/op
BenchmarkHash/minio-6          	16463313	        72.87 ns/op	1372.26 MB/s	       0 B/op	       0 allocs/op

on other systems (here AMD64) there was a significant performance difference between the two libraries:

goos: linux
goarch: amd64
cpu: 12th Gen Intel(R) Core(TM) i9-12900KF
BenchmarkHash/golang-24         	 5231113	       222.2 ns/op	 450.14 MB/s	       0 B/op	       0 allocs/op
BenchmarkHash/minio-24          	14489305	        81.75 ns/op	1223.20 MB/s	       0 B/op	       0 allocs/op 

Since there are still at least some platforms where minio performs considerably better than the standard library, but none that we tested were worse, we will keep using https://github.com/minio/sha256-simd