<p>Let's try to make a rough estimate.</p>

<p>Intel's article <a href="https://software.intel.com/en-us/articles/intel-sha-extensions" rel="noreferrer">Intel SHA Extensions</a> gives some details on these instructions as well as sample code.  The main feature is the <code>sha256rnds2</code> 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 <code>sha256rnds2</code> 128 times to perform one Bitcoin hash.</p>

<p>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 <code>sha256rnds2</code> instructions per clock cycle.  Let's also generously assume that all the ancillary code needed to set up for <code>sha256rnds2</code> can be pipelined and doesn't require any additional clock cycles.  So it takes 64 clock cycles to perform one Bitcoin hash.</p>

<p>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 <a href="http://en.wikipedia.org/wiki/Skylake_%28microarchitecture%29" rel="noreferrer">Wikipedia article on Skylake</a> 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 <a href="http://en.wikipedia.org/wiki/List_of_Intel_Core_M_microprocessors" rel="noreferrer">Core M</a> 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.</p>

<p>So our overall hash rate is</p>

<pre><code> 3x10^9 clocks/sec / 64 clocks/hash * 2 cores =  93.75 MHash/sec
</code></pre>

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

<p>By comparison, according to bitcoin.it's <a href="https://en.bitcoin.it/wiki/Mining_hardware_comparison" rel="noreferrer">Mining hardware comparison</a>, current ASIC miners are able to produce 1000-2000 MHash/J.</p>

<p>Conclusion:</p>

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

CC BY-SA 3.0
2015-03-02T16:01:34.327Z
Because 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
CC BY-SA 3.0
2015-03-02T16:14:26.157Z
@Nick: Good point. I'll try to edit when I have a chance.
Nate Eldredge
CC BY-SA 3.0
2015-03-06T02:18:05.633Z
Assuming Intel is using the implementation outlined in [this patent](http://www.google.com/patents/WO2013147877A1?cl=en), the instruction timing is 3 cycles per execution of `sha256rnds2`.
Mark
CC BY-SA 3.0
2016-11-02T06:25:59.583Z
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](http://stackoverflow.com/questions/20692386/are-there-in-x86-any-instructions-to-accelerate-sha-sha1-2-256-512-encoding#40372485), 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](https://en.wikipedia.org/wiki/Silvermont)).
Peter Cordes
CC BY-SA 3.0
2016-11-02T06:26:08.597Z
Anyway, [SKL's AESENC is 4c latency, pipelined at one per 1c throughput](http://agner.org/optimize).  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
CC BY-SA 3.0
2016-11-02T06:28:02.777Z
With 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
CC BY-SA 3.0
2016-11-02T06:38:19.260Z
@PeterCordes: Thanks for the info.  Meanwhile, since I wrote this, ASIC mining efficiency has improved by a factor of 5.
Nate Eldredge
CC BY-SA 3.0
2015-03-02T15:42:47.787Z
2015-03-02T15:42:47.787Z
Nate Eldredge
<p>Intel is scheduled to release their new x86 <a href="http://en.wikipedia.org/wiki/Skylake_%28microarchitecture%29" rel="noreferrer">SkyLake microarchitecture</a> in Q3 2015. Among other interesting features, it will introduce <a href="http://en.wikipedia.org/wiki/Intel_SHA_extensions" rel="noreferrer">SHA extensions</a> that will allow hardware acceleration of the Secure Hash Algorithm family, including SHA256 as used by Bitcoin.</p>

<p>In terms of SHA crunching speed, it is common lore that:</p>

<p>CPU &lt; GPU &lt; FPGA &lt; ASIC</p>

<p>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?</p>

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

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

<hashpower><mining-hardware><cpu>
What mining performance can we roughly expect from the Intel SHA extensions of the upcoming Skylake processor architecture?
Will
# What mining performance can we roughly expect from the Intel SHA extensions of the upcoming Skylake processor architecture?

(Asked by: username_0 on 2015-02-28)

Intel is scheduled to release their new x86 [SkyLake microarchitecture](http://en.wikipedia.org/wiki/Skylake_%28microarchitecture%29) in Q3 2015. Among other interesting features, it username_0 introduce [SHA extensions](http://en.wikipedia.org/wiki/Intel_SHA_extensions) that username_0 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 username_0 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 username_0 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.

**Tags:** hashpower, mining-hardware, cpu


---

## 1 answers

### Answer by username_1 on 2015-03-02. Score: 7 | Accepted answer

Let's try to make a rough estimate.

Intel's article [Intel SHA Extensions](https://software.intel.com/en-us/articles/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](http://en.wikipedia.org/wiki/Skylake_%28microarchitecture%29) suggests that the SKL-Y-1 model username_0 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](http://en.wikipedia.org/wiki/List_of_Intel_Core_M_microprocessors) 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](https://en.bitcoin.it/wiki/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.

> **Comments:**
> **username_2**: Because 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.  
> **username_1**: @username_2: Good point. I'll try to edit when I have a chance.  
> **username_3**: Assuming Intel is using the implementation outlined in [this patent](http://www.google.com/patents/WO2013147877A1?cl=en), the instruction timing is 3 cycles per execution of `sha256rnds2`.  
> **username_4**: Presumably the SHA instructions username_0 be somewhat similar in performance to AESENC/AESDEC when they do show up in a Skylake successor ([currently only in Goldmont](http://stackoverflow.com/questions/20692386/are-there-in-x86-any-instructions-to-accelerate-sha-sha1-2-256-512-encoding#40372485), 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](https://en.wikipedia.org/wiki/Silvermont)).  
> **username_4**: Anyway, [SKL's AESENC is 4c latency, pipelined at one per 1c throughput](http://agner.org/optimize).  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.)  
> **username_4**: With 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?  
> **username_1**: @username_4: Thanks for the info.  Meanwhile, since I wrote this, ASIC mining efficiency has improved by a factor of 5.  

---

