-
Notifications
You must be signed in to change notification settings - Fork 257
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
Go crypto faster than OpenSSL on AES-NI systems #23
Comments
That would be defininitely interesting. You can run the built-in benchmark using
On my machine, I get this (StupidGCM = simple OpenSSL wrapper, GoGCM = built-in Go crypto):
My cpu does not have AES-NI,
|
My machine (i5-4690K) is still not fully idle, but I think the results are clear enough:
Results from the old openssl_benchmark.bash from v0.9:
I am not sure what causes the difference in Go crypto performance (but I also didn't look into the code). |
The old benchmarks use a 12-byte IV, which is Go's default. Since v0.7, gocryptfs actually uses 16 bytes and the new benchmarks reflect that. |
In any case, the performance difference between Go and OpenSSL is huge. I will add autodection that switches to Go crypto if AES-NI is available. |
Ah okay, that explains it. |
I am rather new to Go. Do you know if there is an easy way to compile the benchmark as binary? |
Similar results here on an i5 core that has AES-NI instructions.
|
@lxp Run
|
Ugh. Looks like it is going to be more complicated than checking for the "aes" flag.
|
Ok here we go, Go seems to use the AES instructions from v1.6. This is on the same box as above.
|
Hi guys, if you are interested I ran some benchmarks on my desktop machine and a fresh SSD comparing plain, gocryptfs (openssl on/off), encfs, securefs, truecrypt & dm-crypt. |
@rfjakob Thank you, I didn't expect a that simple solution :)
AES-NISkylake (Launch: Q3'15)
Haswell (Launch: Q2'14)
Ivy Bridge (Launch: Q2'12)
Sandy Bridge (Launch: Q1'11)
Westmere (Launch: Q1'10)
no AES-NIIvy Bridge (Launch: Q1'13)
Nehalem (Launch: Q3'09)
Core (Launch: Q1'08)
Maybe, I will add two older AMD processors (without AES-NI), when I have time. |
Wow! Awesome work, thank you!
|
@rfjakob While most of gocryptfs operations outperformed encfs (even in standard mode) in the quick benchmark I posted earlier, why is the rm operation a bit behind ? |
Hi @alphazo, I read your comparison with great interest, thank you! Yes, we are 15% behind EncFS for rm, hmm. To be honest, I'm not sure why. I'll have to profile this! |
Go GCM is faster than OpenSSL if the CPU has AES instructions and you are running Go 1.6+. See #23 for details.
Go GCM is faster than OpenSSL if the CPU has AES instructions and you are running Go 1.6+. See #23 for details.
Go GCM is faster than OpenSSL if the CPU has AES instructions and you are running Go 1.6+. Run "gocryptfs -debug -version" to display the result of the autodetection. See #23 for details and benchmarks.
Go GCM is faster than OpenSSL if the CPU has AES instructions and you are running Go 1.6+. The "-openssl" option now defaults to "auto". "gocryptfs -debug -version" displays the result of the autodetection. See #23 for details and benchmarks.
Go GCM is faster than OpenSSL if the CPU has AES instructions and you are running Go 1.6+. The "-openssl" option now defaults to "auto". "gocryptfs -debug -version" displays the result of the autodetection. See #23 for details and benchmarks.
Autodetection has been added to master in 49b597f , the You can run "gocryptfs -debug -version" to see the result of the autodetection, I get
because my CPU does not support AES-NI. |
Great! Thank you, for integrating it so fast 👍
While on the 3 non AES-NI CPUs I get:
I compiled again with Go 1.6 and all systems are running on amd64. |
Great! Do you want to put the benchmarks into the wiki? Something like https://github.com/rfjakob/gocryptfs/wiki/CPU-Benchmarks ? I think it's valuable information and deserves some visibility. Same thing for you, @alphazo ! Maybe https://github.com/rfjakob/gocryptfs/wiki/Performance-Comparison ? |
Released as v0.10-rc3. |
On my system Go crypto seems to be a lot faster than OpenSSL crypto.
I started to investigate this with gocryptfs 0.9 and perf on Linux 4.4. Under heavy load (multiple rsync's ongoing) perf attributed 60% overhead to the Go runtime's native call checks (runtime.cgoCheckArg), which were caused by OpenSSL calls.
I will provide proper benchmarks with gocryptfs 0.10-rc1, once my system is idle again.
The text was updated successfully, but these errors were encountered: