What mining performance can we roughly expect from the Intel SHA extensions of the upcoming Skylake processor architecture?

11

1

Intel is scheduled to release their new x86 SkyLake microarchitecture in Q3 2015. Among other interesting features, it will introduce SHA extensions that will allow hardware acceleration of the Secure Hash Algorithm family, including SHA256 as used by Bitcoin.

In terms of SHA crunching speed, it is common lore that:

CPU < GPU < FPGA < ASIC

But where will these new extensions fit in this row? And how many orders of magnitude of speed difference can we expect them to have in comparison to the above hardware options?

Would it be useful to compare the extent to which Intel's existing AES extensions speed up AES functions compared to software-only AES?

EDIT: After reading up more on these kinds of special purpose CPU instructions, I realize they will most likely speed things up to be only several times faster than the software baseline; not several orders of magnitude faster, like ASICs, or even FPGAs are. Still, the question might be an interesting reference so I'll leave it.

Will

Posted 2015-02-28T07:18:43.480

Reputation: 327

Answers

7

Let's try to make a rough estimate.

Intel's article Intel SHA Extensions gives some details on these instructions as well as sample code. The main feature is the sha256rnds2 instruction, which performs two rounds of SHA256, out of the 64 rounds that are needed to hash one 64-byte block. A Bitcoin header is 80 bytes long, so that's 2 blocks, and because the mining algorithm is SHA256D, we need to do it twice. So we need to execute sha256rnds2 128 times to perform one Bitcoin hash.

I'm no expert on modern CPU architectures, but I would suspect a complex instruction like this would take more than one clock cycle; nonetheless, let's generously suppose it doesn't. Since each round depends on the outputs of the previous, these rounds probably have to be executed serially (on each core), so not much parallelization can be done. But let's very generously assume there are resources that can be shared, so that the CPU can execute two sha256rnds2 instructions per clock cycle. Let's also generously assume that all the ancillary code needed to set up for sha256rnds2 can be pipelined and doesn't require any additional clock cycles. So it takes 64 clock cycles to perform one Bitcoin hash.

Now, how fast can we run the clock, and more importantly, how much power would be used? Since power consumption is paramount, let's suppose that we would want to use a mobile CPU. The Wikipedia article on Skylake suggests that the SKL-Y-1 model will have 2 cores and a thermal design power (TDP) of 4 W. Let's assume the TDP represents the actual power consumption for our mining application, and furthermore let's neglect the power consumption of all other components of our machine (memory, power supply, etc). There isn't any information given on clock speeds, but Intel's current Core M processors have a base clock speed of up to 1.2 GHz, with "turbo" up to 2.9 GHz. Let's suppose this new Skylake device could run at 3 GHz sustained.

So our overall hash rate is

 3x10^9 clocks/sec / 64 clocks/hash * 2 cores =  93.75 MHash/sec

With a power consumption of 4 W, this gives an efficiency of 23.4 MHash/J.

By comparison, according to bitcoin.it's Mining hardware comparison, current ASIC miners are able to produce 1000-2000 MHash/J.

Conclusion:

Even under extremely optimistic assumptions about the mining performance of the Skylake processors, modern ASIC devices are still 40-80 times more efficient.

Nate Eldredge

Posted 2015-02-28T07:18:43.480

Reputation: 21 420

6Because of the midstate, you only need to hash 16 bytes in the first invocation. You only need to hash 32 bytes in the second invocation, because you're hashing the hash. So you only need sha256rnds2 64 times. Not that it matters, of course. – Nick ODell – 2015-03-02T16:01:34.327

1@Nick: Good point. I'll try to edit when I have a chance. – Nate Eldredge – 2015-03-02T16:14:26.157

1

Assuming Intel is using the implementation outlined in this patent, the instruction timing is 3 cycles per execution of sha256rnds2.

– Mark – 2015-03-06T02:18:05.633

Presumably the SHA instructions will be somewhat similar in performance to AESENC/AESDEC when they do show up in a Skylake successor (currently only in Goldmont, which is low power with limited out-of-order execution capability. Agner Fog doesn't list AESENC timings for Silvermont, unfortunately, even though it does support AES-NI).

– Peter Cordes – 2016-11-02T06:25:59.583

1

Anyway, SKL's AESENC is 4c latency, pipelined at one per 1c throughput. To take advantage of this for a SHA instruction with those timings, you simply work on 4 SHA hashes in parallel, so you keep four sha256rnds2 instructions in flight, bottlenecking on SHA throughput instead of latency. This should work even on Goldmont, assuming its sha256rnds2 execution unit is similarly pipelined. (It might not be: the first CPUs to implement PCLMULUDQ used microcode, and it wasn't until Broadwell that it was down all the way to 1 uop.)

– Peter Cordes – 2016-11-02T06:26:08.597

1With well-tuned code, you can probably saturate port0 in a core with one thread, so hyperthreading won't help. (Unless there are other parts of the code that also take time, and might bottleneck on something else.) BTW, Goldmont TDP=10W for the desktop model (2.0 - 2.5GHz), or 6W for the mobile with the same max turbo. I would guess that a loop doing SHA256 hashes won't generate maximal heat, and might run at max turbo while staying under 6W. So your numbers might be within a factor of 2 or so, maybe? – Peter Cordes – 2016-11-02T06:28:02.777

3@PeterCordes: Thanks for the info. Meanwhile, since I wrote this, ASIC mining efficiency has improved by a factor of 5. – Nate Eldredge – 2016-11-02T06:38:19.260

Asked: 2015-02-28T07:18:43.480

Viewed: 3 896 times

Active: 2017-06-12T13:05:51.623