Return to

What's the fastest processor for single threaded/single process of running sha256sum?

1 question:

  • what is the speed of your data source?

You may find that the speed of your data source is the limiting factor on modern CPUs. Unless you can fit 6.5 TB into RAM it is going to have to be streamed from somewhere (and even if you can, it’s going to have to be loaded from somewhere into RAM still?) and I doubt you’ll have more than a few GB/sec of bandwidth to load it from?

You might not need the “fastest” CPU for sha256 if you’re bandwidth limited anyway.


checking file integrity as the file is being moved over the network.

It’s being read from my RAID0 array consisting of four HGST 6 TB 7200 rpms HDDs, which are capable of a total of somewhere around 750 MB/s read speed for the entire array. (~187.5 MB/s per drive based on iotop).

Currently, best case scenario (using an Intel Core i7-3930K, a single thread can only read at around 311 MB/s with 64 GB of DDR3-1600 memory I think, I forget the timings).

But if I am reading the file over the network, I’m reading it over 4x EDR 100 Gbps Infiniband (which has a theorectical peak bandwidth of 12.5 GB/s, which I should be able to obtain if I move to U.2 NVMe SSDs).

But at the current rate, I think that I am definitely CPU bound.

When I run openssl speed sha256, I get around 350 MB/s for 8 kiB block sizes.


1 Like

Here’s what I got with my i5 8250U with a (probably cheap, mediocre) ssd and 8GB ddr4 ram:


What OS are you running?

Kubuntu 20.04 with Linux kernel version 5.6.14

This is what I get with Intel Core i7-3930K, on Asus P9X79-E WS, with 64 GB of DDR3-1600, running CentOS 7.7.1908 running Linux 3.10.0-1062.el7.x86_64 kernel, running openssl 1.0.2k-fips.

Time to update your kernel?

Not sure if it is the kernel, openssl, the RAM, the motherboard, and/or the CPU.

This is part of what makes running this test so difficult in order to come up with some kind of a meaningful answer/conclusion.

The more variables there are, the complexity and the number of permutations of the test that will need to be run out.


One of the biggest reasons why I haven’t updated a lot of stuff on the system is because I also don’t want to break other stuff that’s already working (e.g. NFSoRDMA).

Support for that is rather “fragile”.

There are no kernel updates for rhel based distributions only patches. While could update to 7.8 this still would not pull a newer kernel. He would have to update to CentOS 8 which runs the 4.18 kernel.

1 Like

Yeah…which, I’m not sure if that would cause other problems for me. (Hardware compatibility issues with NFSoRDMA or software compatibility issues for the CAE programs that I use that hasn’t been certified to run on CentOS 8 yet.)

It’s one of those “you fix one problem, but break or create many other problems.”

Yayyyy Linux!!!


It’s not a unique problem to Linux but yeah I feel your pain.

For a true apples to apples comparison it needs to stay with your exact hardware setup.

@alpha754293 why don’t you just get a live USB of some newer version of fedora running the 5.x kernel, and then run the test?

1 Like

My bad, i’m relatively new to linux

No you’re fine. It’s one of those things you pick up.

Rhel freezes their kernel and backports patches.

Each major release is supported for 10 years which is why it’s used so much in the enterprise.

1 Like

Could it be that comparing my result to OP’s is “flawed”? My OpenSSL version is newer.

Your hardware, and software versions are different than his.

It would be interesting if you spun up a CentOS 7.8 live USB and ran the test again to see your performance delta.

I downloaded the centos-kde iso from here but on installation it asked me to install a kernel and I don’t know how to do that (lol noob)

lots of googling later i maybe found something but currently booted to windows not linux =/

1 Like

I don’t know, that’s why I gave the disclaimer. It is a pretty solid way to judge maximum single core performance between CPUs in general. And when averaging out a couple runs back to back it is also very consistent. But I have no experience with benchmarking hashing algorithms and most of my systems are packed up for moving currently. So I can’t even run stuff myself right now.

In case its relevant, here’s what my 2700x puts out

OpenSSL 1.1.1d FIPS  10 Sep 2019
built on: Thu Oct  3 00:00:00 2019 UTC
options:bn(64,64) md2(char) rc4(8x,int) des(int) aes(partial) idea(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -Wa,--noexecstack -Wa,--generate-missing-build-notes=yes -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DZLIB -DNDEBUG -DPURIFY -DDEVRANDOM="\"/dev/urandom\"" -DSYSTEM_CIPHERS_FILE="/etc/crypto-policies/back-ends/openssl.config"
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha256          248651.25k   634125.85k  1311330.13k  1773534.55k  1985853.13k  1996559.70k

IIRC, Zen is really good at hashing…