56
$\begingroup$

I'm getting this strange result that SHA512 is around 50% faster than SHA256. I'm using .net's SHA512Managed and SHA256Managed classes. The code is similar to the one posted here but I'm referring to tests taking caching into account (from the second time reading the file onwards it seems that it's cached completely). I've tested it several times with the same results.

My question is: is this logical or must there be something wrong with my test?

$\endgroup$
60
$\begingroup$

This isn't necessarily unexpected. 32-bit platforms vs 64-bit platforms can make a significant difference, as well as the amount of data you're hashing.

$ uname -m
x86_64

$ openssl speed sha256 sha512
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           29685.74k    79537.52k   148376.58k   186700.77k   196588.36k
sha512           23606.96k    96415.90k   173050.74k   253669.59k   291315.50

As you can see, on my 64-bit machine, SHA-512 beats SHA-256 for hashing anything more than 16 bytes of data at a time. And generally, the more data being hashed at once, the bigger the performance improvement.

Edit: As @MaartenBodewes points out in the comments, there's also SHA-512/256 which does the same computation as normal SHA-512 (with a different initial value) but truncates the output to 256 bits. This is a better option (due to the different IV) than simply truncating the output of SHA-512 to 256 bits by yourself in the case where you need the higher throughput but are limited to 256 bit outputs. Alternatively, if you really need higher throughput, BLAKE2b is an excellent cryptographic hash that is extremely fast and natively supports arbitrarily sized outputs (between 1 and 64 bytes).

$\endgroup$
  • $\begingroup$ Thanks. But isn't the amount of calculations larger for SHA512? (Which is why I was surprised.) $\endgroup$ – ispiro Jun 16 '15 at 20:28
  • 11
    $\begingroup$ SHA-256 performs 64 rounds of its compression function over 512 bits (its blocks size) at a time. SHA-512 on the other hand performs 80 rounds of the compression function, but over 1024 bits at a time. So yes, SHA-512 performs more calculations in a single invocation, but it does so over a larger quantity of data at a time. $\endgroup$ – Stephen Touset Jun 16 '15 at 20:38
  • 4
    $\begingroup$ @StephenTouset A hint about the existence of SHA-512/256 would make a nice addition. $\endgroup$ – Maarten Bodewes Jun 16 '15 at 20:44
  • 2
    $\begingroup$ The crossover point should be at 56 bytes, since SHA256 jumps to 2 blocks of 64 bytes each, at that point. SHA256 might get ahead again at 120 bytes, since then it's 3 blocks for SHA256 and 2 blocks (128 bytes each) for SHA512. $\endgroup$ – CodesInChaos Jun 16 '15 at 20:49
  • 1
    $\begingroup$ Well, there's three blocks of SHA-256 against two block SHA-512 as well, which I forgot about. Lets just conclude that for small inputs you may want to test which one is faster if you want to go purely for speed. $\endgroup$ – Maarten Bodewes Jun 16 '15 at 21:07
39
$\begingroup$

SHA-512 has 25% more rounds than SHA-256. On a 64-bit processor each round takes the same amount of operations, yet can process double the data per round, because the instructions process 64-bit words instead of 32-bit words. Therefore, 2 / 1.25 = 1.6, which is how much faster SHA-512 can be under optimal conditions.

Of course there is memory overhead, instruction latency, and other factors involved; on an Intel Ivy Bridge processor long message SHA-512 is 1.54 x faster, and on an AMD Piledriver it is 1.48 x faster.

For small messages (less than 448 bits) SHA-512 will be approx 1.25 x slower, because only a single hash iteration is performed. There are also various crossover points where one hash will need to process an extra iteration and the other will not, but these numbers are averages, the actual performance graph will be stepped at the iteration increment point.

$\endgroup$
8
$\begingroup$

SHA-512 (and SHA-384) is usually faster on 64-bit platforms, and SHA-256 is usually faster on 32-bit platforms.

$\endgroup$
  • $\begingroup$ Thanks. But isn't the amount of calculations larger for SHA512? (Which is why I was surprised.) $\endgroup$ – ispiro Jun 16 '15 at 20:29
  • $\begingroup$ @ispiro SHA512 does do more calculations. That's why you only see 50% improvement. Had the amount of calculations been the same you would have seen close to 100% improvement. $\endgroup$ – kasperd Jun 17 '15 at 10:46
  • 5
    $\begingroup$ This answer could do with some explanation and references. $\endgroup$ – curiousdannii Jun 18 '15 at 4:49
  • 3
    $\begingroup$ I have to agree with what @curiousdannii noted: currently, this looks more like a comment than an answer. Adding some information about “why” and “under what conditions” platform bitsizes are able to influence SHA2 speeds would be a good starter (if you need an example, just take a look at the answer by @richie-frame) … see, actually explaining things generally differs answers from comments. $\endgroup$ – e-sushi Jun 19 '15 at 2:42
5
$\begingroup$

Benchmarks

I would like to see also some real-life measurements here, so I hope you'll like it ;)


Intel Core i7-7700HQ (7th gen = Kaby Lake); RAM (DDR4)

HW / OS configuration:

  • System: Linux Mint 19.1 Cinnamon 64-bit; intel-microcode package, as well as the latest UEFI/BIOS patch, were installed.

  • Processor: Intel® Core™ i7-7700HQ (Ark Intel), PassMark, 2.80GHz - 3.80GHz, 4 cores, 8 threads, laptop

  • Memory: 16GiB DDR4 2400MHz (single-channel)

  • CPU flags (grep flags /proc/cpuinfo):

    fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d
    

Methodology:

  1. Starting with rebooting the laptop.

  2. For speed measurement the pv utility (man page) has been used:

    pv --average-rate BigFile10GiBinRAM | sha512sum --binary
    pv --average-rate BigFile10GiBinRAM | sha256sum --binary
    
  3. The BigFile10GiBinRAM was with /dev/urandom generated file.

  4. Of course, all unnecessary services and programs were stopped at test time.

  5. The file was located in the RAM (tmpfs).

  6. I ran each test 3 times with the results being the same +/- 1.

Test results:

  1. SHA-512 resulted in speed of 344MiB/s ~ about 60% faster!

  2. SHA-256 resulted in speed of 215MiB/s.


Intel Core i7-4700HQ (4th gen = Haswell); SSD (SATA)

HW / OS configuration:

  • System: Linux Mint 18.2 Cinnamon 64-bit; intel-microcode package, as well as the latest UEFI/BIOS patch, were installed.

  • Processor: Intel® Core™ i7-4700HQ (Ark Intel), PassMark, 2.40GHz - 3.40GHz, 4 cores, 8 threads, laptop

  • Memory: 16GiB DDR3 1600MHz (dual-channel)

  • CPU flags (grep flags /proc/cpuinfo):

    fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts
    

Methodology:

  1. Starting with rebooting the laptop.

  2. For speed measurement the pv utility (man page) has been used:

    pv --average-rate BigFile103GiB | sha512sum --binary
    pv --average-rate BigFile103GiB | sha256sum --binary
    
  3. The BigFile103GiB was a virtual disk containing real data (VirtualBox).

  4. Of course, the virtual machine wasn't running at test time, and all unnecessary services and programs were stopped at test time.

  5. The file was located on a 2.5" SATAIII SSD drive.

  6. I ran each test 3 times with the results being the same +/- 1.

Test results:

  1. SHA-512 resulted in speed of 275MiB/s ~ about 50% faster!

  2. SHA-256 resulted in speed of 183MiB/s.


Intel Xeon E3-1225 v3 (4th gen = Haswell); RAM (DDR3)

HW / OS configuration:

  • System: GNU/Linux Debian 9 64-bit; intel-microcode package, as well as the latest UEFI/BIOS patch, were installed.

  • Processor: Intel® Xeon® E3-1225 v3 (Ark Intel), PassMark, 3.20GHz - 3.60GHz, 4 cores, 4 threads, server

  • Memory: 32GiB DDR3 1600MHz (dual-channel) UDIMM ECC

  • CPU flags (grep flags /proc/cpuinfo):

    fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts
    

Methodology:

  1. Starting with rebooting the server.

  2. For speed measurement the pv utility (man page) has been used:

    pv --average-rate BigFile24GiBinRAM | sha512sum --binary
    pv --average-rate BigFile24GiBinRAM | sha256sum --binary
    
  3. The BigFile24GiBinRAM was with /dev/urandom generated file.

  4. Of course, all unnecessary services and programs were stopped at test time.

  5. The file was located in the RAM (tmpfs).

  6. I ran each test 3 times with the results being the same +/- 1.

Test results:

  1. SHA-512 resulted in speed of 315MiB/s ~ about 53% faster!

  2. SHA-256 resulted in speed of 206MiB/s.

$\endgroup$
  • $\begingroup$ Note that Goldmond, the successor to Skylake (including Kaby Lake), which in turn succeeds Haswell, has SHA-extensions that provide instructions to speed up SHA-1 and SHA-256 but not SHA-512. This may again turn the advantage to SHA-256, if the instructions are used of course. AMD Ryzen also supports these instructions. $\endgroup$ – Maarten Bodewes Mar 17 at 20:58
  • $\begingroup$ @MaartenBodewes Thank you for the information! $\endgroup$ – Vlastimil Mar 18 at 2:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.