-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use crypto/sha256
#29386
Use crypto/sha256
#29386
Conversation
but the improvement is only for amd64? |
IIRC it lacks arm64 optimization. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would still use stdlib over a dependency even if it means slightly worse perf on the other archs as those are bound to eventually improve on other archs. amd64 likely accounts for 95%+ of installations. Also, is sha256 really a bottleneck for gitea? |
I didn't mean objection or blocker (I could be neutral for it). Yes, sha256 is not a bottleneck for gitea, but I just didn't find a reason worth to do so:
So, I just didn't know whether it is worth to use stdlib to replace minio version. |
Comparing https://github.com/minio/sha256-simd/blob/master/sha256block_arm64.s with https://cs.opensource.google/go/go/+/refs/tags/go1.22.0:src/crypto/sha256/sha256block_arm64.s they use the same intrinsics so they could have similar performance. Does someone have an arm64 machine and could do a benchmark? |
Is it a new enhancement in Go 1.22? In Go 1.21, they only mentions "amd64". If the stdlib also have the same performance, then I don't have any question. |
I would prefer stdlib because it will likely be better maintained long-term and they also have better processes in place for security issues and such. |
No, minio announced 2016 their improved ARM64 support. A year later hardware support for ARM64 was added to Go too (https://cs.opensource.google/go/go/+/7b8a7f8272fd1941a199af1adb334bd9996e8909) So both should have similar performance since Go 1.10 (?) With Go 1.21 they just added support for sha-ni for x64 cpus. |
* giteaofficial/main: (45 commits) Include resource state events in Gitlab downloads (go-gitea#29382) Add API to get PR by base/head (go-gitea#29242) [skip ci] Updated translations via Crowdin Improve Documentation for Restoration from backup (go-gitea#29321) Refactor "user/active" related logic (go-gitea#29390) Remove jQuery AJAX from the archive download links (go-gitea#29380) Add tailwindcss (go-gitea#29357) Add missing space (go-gitea#29393) Integrate alpine `noarch` packages into other architectures index (go-gitea#29137) enforce maxlength in frontend (go-gitea#29389) Remove incorrect and unnecessary Escape from templates (go-gitea#29394) Make actions animation rotate counterclockwisely (go-gitea#29378) Use `crypto/sha256` (go-gitea#29386) Add `io.Closer` guidelines (go-gitea#29387) Remove jQuery AJAX from the notice selection deletion button (go-gitea#29381) Refactor Safe modifier (go-gitea#29392) Add attachment support for code review comments (go-gitea#29220) Refactor modules/git global variables (go-gitea#29376) Remove jQuery from the code diff expansion buttons (go-gitea#29385) Remove jQuery AJAX from the markdown editor preview (go-gitea#29384) ...
Go 1.21 improved the performance of
crypto/sha256
. It's now similar tominio/sha256-simd
, so we should just use the standard libs.https://go.dev/doc/go1.21#crypto/sha256
https://go-review.googlesource.com/c/go/+/408795
multiformats/go-multihash#173