Tag Archives: SSE

Pcompress 1.3 released

Parallel Compression RevisitedI have put up a new release of Pcompress on the Google Code download page. This release focusses primarily on performance enhancements across the board and a few bug fixes. The changes are summarized below:

  1. Deduplication performance has improved by at least 2.5X as a result of a variety of tweaks to the core chunking code.
    • One of the interesting changes is to use a 16-byte SSE register as the sliding window since I am using a window size of 16. This avoids a lot of memory accesses but requires SSE4.
    • The perf utility allowed me to see that using the window position counter as a context variable causes a spurious memory store for every byte! Using a local variable allows optimization via a register. This optimization affects the situation where we do not have SSE4.
    • Compute the full fingerprint only when at least minimum chunk length bytes have been consumed.
  2. Delta Compression performance and effectiveness have both been improved. I have tweaked the minhash approach to avoid storing and using fingerprints. That approach was causing memory write amplification and significant slowdown. Rather I am just treating the raw data as a sequence of 64-bit integers and heapifying them. Bsdiff performance has been improved along with RLE encoding. I also tweaked the matching approach. It now checks for similar blocks that are some distance apart depending on the compression algorithm. This actually causes long range similar blocks to be delta-ed eventually helping the overall compression.
  3. One of the big changes is the inclusion of the BLAKE2 checksum algorithm and making it the default. BLAKE2 is one of the highest-performing cryptographic checksums, exceeding even MD5 in performance on 64-bit platforms. It is derived from BLAKE, one of the NIST SHA3 runner ups with a large security margin.
  4. I have tweaked Yann Collet’s xxHash algorithm (non-cryptographic hash) to vectorize it and make it work with 32-byte blocks. Performance is improved for both vectorized and non-vectorized versions. I have covered this in detail in my previous post: Vectorizing xxHash for fun and profit.
  5. I have tweaked the AES CTR mode implementation to vectorize it. CTR mode encrypts a 16-byte block consisting of a 64-bit nonce or salt value and a 64-bit block counter value concatenated together. This is then XOR-ed with 16 bytes of plaintext to generate 16 bytes of ciphertext. The block counter is then incremented and the process repeated. This XOR handling with 16-bytes can be nicely done in an XMM register. The result is faster even when using unaligned SSE2 loads helped a little with data prefetch instructions.
  6. Apart from BLAKE2 I also included Intel’s optimized SHA512 implementation for x86 processors and moved to using SHA512/256. This improves SHA2 performance significantly on x86 platforms.
  7. BLAKE2 includes a parallel mode. I also included simple 2-way parallel modes for other hashes including KECCAK when compressing a single file in a single chunk. This is essentially a single-threaded operation so other forms of parallelism need to be employed.
  8. With all the vectorization being thrown around with SSE2/3/4 and AVX1/2 versions of various stuff, I have also added runtime CPU feature detection to invoke the appropriate version for the CPU. At least SSE2 capability is assumed. At this point I really have no intention of supporting Pentium and Atom processors! This also requires one to use at least the Gcc 4.4 compiler so that things like SSE4.2 and AVX intrinsics can be compiled even if CPU support for them is not available.
  9. In addition to all the above some bug fixes have also gone into this release.

However this is in no way the full gamut of optimizations possible. There are more changes to be done. For example I need to add support for optimized AES GCM mode. This is a block cipher mode of operation which combines encryption and authentication avoiding the need to for a separate HMAC. HMAC is still useful for situations where one may want to authenticate but not encrypt. Deduplication performance can be further improved by at least 2X. The current chunking code has a silly oversight.  HMAC needs to support parallel modes. I also need to enable parallel operation for LZP in single-chunk modes. In addition I want to explore use of GPGPUs and CUDA for hashing, chunking etc.

Vectorizing xxHash for Fun and Profit

Update: Thanks to Yann Collet’s comment I have fixed the mistaken reference to Hyperthreading while in fact I was referring to Instruction Level Parallelism via Superscalar processing.

I was doing various  performance optimizations in Pcompress for the last few days and the xxHash piece caught my eye. This non-cryptographic hash implementation is one of the fastest 32 bit hashes available today. I use it in Pcompress to hash data chunks for deduplication. The hash value is used to insert the chunk-id into a hashtable for lookups. xxHash is already extremely fast working at 5.4 GB/s on a fast processor however it’s inner loop looked very interesting.

 do
 {
     v1 += XXH_LE32(p) * PRIME32_2; v1 = XXH_rotl32(v1, 13); v1 *= PRIME32_1; p+=4;
     v2 += XXH_LE32(p) * PRIME32_2; v2 = XXH_rotl32(v2, 13); v2 *= PRIME32_1; p+=4;
     v3 += XXH_LE32(p) * PRIME32_2; v3 = XXH_rotl32(v3, 13); v3 *= PRIME32_1; p+=4;
     v4 += XXH_LE32(p) * PRIME32_2; v4 = XXH_rotl32(v4, 13); v4 *= PRIME32_1; p+=4;
 } while (p<=limit);

 h32 = XXH_rotl32(v1, 1) + XXH_rotl32(v2, 7) + XXH_rotl32(v3, 12) + XXH_rotl32(v4, 18);

There are 4 independent compute streams consuming data into 4 separate accumulators which are then combined into a single hash value later. These 4 independent but identical compute streams look like a perfect fit for vectorizing using the SSE instructions on modern x86 processors. The SSE registers can hold multiple packed integers or floats and a single operation, for example addition, applied to two SSE registers affect all the package values in parallel. The image below shows this behavior diagrammatically when the SSE registers are populated with 4 32-bit quantities.

simd

An SSE register is 128-bit and can perfectly hold four 32-bit packed integers. I had to use at least SSE 4.1 to get the parallel multiply of packed 32-bit values. The rotate (XXH_rotl32) operation is easily doable with 2 bitwise shifts and a bitwise or (as is done in xxHash original code as well). Without having to deal with inline assembly language we can fairly easily  use the compiler SSE intrinsics. These appear to the programmer as functions but in fact they result in specific CPU instructions being emitted. SSE intrinsics also provide the benefit of letting the compiler handle optimizations like instruction scheduling. Using inline assembly leaves all that optimization burden to the programmer which is often tricky to get right except for short segments. In addition some of the intrinsic functions are composite intrinsics. They result in emitting a collection of CPU instructions encapsulating some commonly used operation (like _mm_set_epi32(…)).

You can get a good overview of SSE programming from the CodeProject article. So my initial effort led to the following code shown below.

#include <smmintrin.h>
static inline __m128i _x_mm_rotl_epi32(const __m128i a, int bits)
{
    __m128i tmp1 = _mm_slli_epi32(a, bits);
    __m128i tmp2 = _mm_srli_epi32(a, 32 - bits);
    return (_mm_or_si128(tmp1, tmp2));
}
...
...
 __m128i accum = _mm_set_epi32(v4, v3, v2, v1);
 __m128i prime1 = _mm_set1_epi32(PRIME32_1);
 __m128i prime2 = _mm_set1_epi32(PRIME32_2);
 do {
     __m128i mem = _mm_loadu_si128((__m128i *)p);
     mem = _mm_mullo_epi32(mem, prime2);
     accum = _mm_add_epi32(accum, mem);
     accum = _x_mm_rotl_epi32(accum, 13);
     accum = _mm_mullo_epi32(accum, prime1);
     p += 16;
 } while (p<=limit);
 _mm_storeu_si128((__m128i *)vx, accum);
 v1 = vx[0]; v2 = vx[1];
 v3 = vx[2]; v4 = vx[3];
 h32 = XXH_rotl32(v1,1) + XXH_rotl32(v2,7) + XXH_rotl32(v3,12) + XXH_rotl32(v4,18);
...

It worked perfectly. However there was a big problem. It was slower than before, and by a good margin! Look at the benchmarks below using the standard silesia test dataset.

Original
========
~/xxhash-read-only $ ./bench silesia.tar
*** Benchmark utility using xxHash algorithm ,by Yann Collet (Jan 19 2013) ***
silesia.tar      :  206612480 ->  3571.1 MB/s   0x61B1160F

Modified
========
~/xxhash-read-only $ ./bench silesia.tar
*** Benchmark utility using xxHash algorithm ,by Yann Collet (Jan 19 2013) ***
silesia.tar      :  206612480 ->  3013.3 MB/s   0x61B1160F

It is 15% slower after vectorizing. This seemed ridiculous to me. I was expecting at the minimum a 10% speedup and here we have parallelized code that is in fact slower! If you notice, my initial code does unaligned loads via “_mm_loadu_si128((__m128i *)p)”. Fearing that to be the cause of latency I did some tweaks to ensure aligned access and processing the initial unaligned bytes separately. The performance difference still remained!

I first thought that SSE instructions were having higher latency compared to the ordinary integer processing ones. So I did some measurements using the Perf tool. The results are shown below.

Original
========
1) Annotation from perf record:
 10.42 │ 30:   mov    (%rdi),%r10d                                                                                                                                     
 14.03 │       imul   $0x85ebca77,%r10d,%r10d                                                                                                                          
  0.34 │       add    %r10d,%r8d                                                                                                                                       
  0.21 │       mov    0x4(%rdi),%r10d                                                                                                                                  
 10.53 │       rol    $0xd,%r8d                                                                                                                                        
  0.23 │       imul   $0x9e3779b1,%r8d,%r8d                                                                                                                            
  0.77 │       imul   $0x85ebca77,%r10d,%r10d                                                                                                                          
  0.02 │       add    %r10d,%ecx                                                                                                                                       
 10.54 │       mov    0x8(%rdi),%r10d                                                                                                                                  
  0.06 │       rol    $0xd,%ecx                                                                                                                                        
  0.34 │       imul   $0x9e3779b1,%ecx,%ecx                                                                                                                            
 10.38 │       imul   $0x85ebca77,%r10d,%r10d                                                                                                                          
  0.30 │       add    %r10d,%edx                                                                                                                                       
  0.02 │       mov    0xc(%rdi),%r10d                                                                                                                                  
  0.07 │       add    $0x10,%rdi                                                                                                                                       
 10.07 │       rol    $0xd,%edx                                                                                                                                        
  0.32 │       imul   $0x9e3779b1,%edx,%edx                                                                                                                            
 10.30 │       imul   $0x85ebca77,%r10d,%r10d                                                                                                                          
  0.12 │       add    %r10d,%eax                                                                                                                                       
  0.22 │       rol    $0xd,%eax                                                                                                                                        
  0.15 │       imul   $0x9e3779b1,%eax,%eax                                                                                                                            
 20.52 │       cmp    %rdi,%r11                                                                                                                                        
  0.03 │     ↑ jae    30

2) Performance counters from perf stat:
*** Benchmark utility using xxHash algorithm , by Yann Collet (Jan 19 2013) ***
silesia.tar      :  206612480 ->  3541.4 MB/s   0x61B1160F

 Performance counter stats for './bench silesia.tar':

    6260.562213 task-clock                #    0.996 CPUs utilized
            544 context-switches          #    0.087 K/sec
              4 CPU-migrations            #    0.001 K/sec
         50,624 page-faults               #    0.008 M/sec
 13,278,187,173 cycles                    #    2.121 GHz                     [83.41%]
  3,657,672,543 stalled-cycles-frontend   #   27.55% frontend cycles idle    [83.30%]
  6,834,837,811 stalled-cycles-backend    #   51.47% backend  cycles idle    [66.70%]
 31,374,782,178 instructions              #    2.36  insns per cycle
                                          #    0.22  stalled cycles per insn [83.40%]
  1,384,012,974 branches                  #  221.068 M/sec                   [83.30%]
         95,141 branch-misses             #    0.01% of all branches         [83.30%]

    6.288590138 seconds time elapsed
Modified
========
1) Annotation from perf record:
  9.38 │ 70:┌─→movdqu (%rdi),%xmm0
  9.52 │    │  add    $0x10,%rdi
  0.00 │    │  cmp    %rdi,%r9
  0.00 │    │  pmulld %xmm3,%xmm0
  9.04 │    │  paddd  %xmm1,%xmm0
  0.15 │    │  movdqa %xmm0,%xmm1
  0.04 │    │  psrld  $0x13,%xmm0
  9.19 │    │  pslld  $0xd,%xmm1
  0.27 │    │  por    %xmm0,%xmm1
  8.95 │    │  pmulld %xmm2,%xmm1
 53.44 │    └──jae    70

2) Performance counters from perf stat:
 Performance counter stats for './bench silesia.tar':

    6265.021121 task-clock                #    0.996 CPUs utilized
            546 context-switches          #    0.087 K/sec
              2 CPU-migrations            #    0.000 K/sec
         50,625 page-faults               #    0.008 M/sec
 13,288,539,258 cycles                    #    2.121 GHz                     [83.36%]
  8,562,225,224 stalled-cycles-frontend   #   64.43% frontend cycles idle    [83.31%]
  3,763,596,002 stalled-cycles-backend    #   28.32% backend  cycles idle    [66.72%]
 12,813,511,969 instructions              #    0.96  insns per cycle
                                          #    0.67  stalled cycles per insn [83.41%]
  1,176,939,765 branches                  #  187.859 M/sec                   [83.31%]
        102,390 branch-misses             #    0.01% of all branches         [83.30%]

    6.292536751 seconds time elapsed

There are a few interesting observations here. Perf annotation tells us that there is not much difference in combined instruction latencies between the normal C and the SSE implementations. However performance counter statistics have a story to tell. I have highlighted the interesting entries in bold. Backend cycles decreased but Frontend cycles increased 2.3x. What is more interesting is that the normal C version issued 2.36 instructions per cycle while in the SSE version it reduced to 1/3rd of that. There is not much code in the small loop to cause stalls so the only explanation for increased Frontend stalls is memory read latency which also cause fewer instructions to get issued.

The big question was why was there so much of memory access latency in the SSE version compared to the normal C version? I pondered this for some time while trying out a variety of experiments to no avail.  I tried things like hand optimized assembly, trying to hide memory latency by loop hoisting etc. Then looking at the disassembly from the perf annotate of the original code again, something looked  interesting. The instructions from the 4 independent computation lines are all interleaved. More precisely instructions from independent computation sequences were interleaved in two pairs. Suddenly a bulb lit up somewhere. We have a gotcha named Superscalar processing and the key thing here is “independent computations”. Intel and AMD x86 CPUs can execute multiple instructions per clock cycle, not necessarily in chronological order, if they are independent of each other and utilize separate processing resources within the core. This is a form of instruction level parallelism that is different to vector processing. Within the core some resources are duplicated and some shared.

I was using a Core i5 from the Nehalem generation which typically has 4 decoders in the front-end pipeline and a superscalar out-of-order execution engine than can dispatch upto 6 micro-ops per cycle. The advantage of doing this is if some instruction from one stream stalls due to some resource being fetched, like memory, then independent instructions from the other streams can be processed. In addition if two compute operations require different resources they can be operated on simultaneously.

superscalarThe original xxHash code fully utilizes this feature helped by the Gcc compiler that recognizes this capability and interleaves independent instructions together to help the superscalar engine achieve maximum instruction level parallelism. In my SSE version I was utilizing a vector parallel unit that can handle four 32-bit integers in a single instruction. So there was only a single vectorized instruction stream to handle all 4 independent operations. The whole Frontend, or in other words fetch-decode unit had to stall during a memory fetch.

So next question was could we improve this situation? How about multiple independent SIMD SSE streams to better utilize the ILP capabillity? It turns out that this is doable but results in a slight change in the hashing approach. I implemented 2 independent SSE streams each processing 16 bytes in an accumulator. There are enough SSE registers available to do this without spurious memory accesses. The accumulators are then combined at the end to the final hash result. This changes the resulting hash value since there are now 2 independent streams processing data in independent strides without combining them. Even then xxHash properties are retained due to the way the final combination is done. My new code is shown below.

#include <smmintrin.h>
static inline __m128i _x_mm_rotl_epi32(const __m128i a, int bits)
{
     __m128i tmp1 = _mm_slli_epi32(a, bits);
     __m128i tmp2 = _mm_srli_epi32(a, 32 - bits);
     return (_mm_or_si128(tmp1, tmp2));
}
...
...
 unsigned int vx[4], vx1[4];
 __m128i accum = _mm_set_epi32(v4, v3, v2, v1);
 __m128i accum1 = _mm_set_epi32(v4, v3, v2, v1);
 __m128i prime1 = _mm_set1_epi32(PRIME32_1);
 __m128i prime2 = _mm_set1_epi32(PRIME32_2);

 /*
  * 4-way SIMD calculations with 4 ints in two blocks for two
  * accumulators will interleave to some extent on a superscalar
  * processor(instruction level parallelism) providing 10% - 14%
  * speedup over original xxhash depending on processor. We could
  * have used aligned loads but we actually want the unaligned
  * penalty. It helps to interleave better for a slight benefit
  * over aligned loads here!
  */
do {
     __m128i mem = _mm_loadu_si128((__m128i *)p);
     p += 16;
     mem = _mm_mullo_epi32(mem, prime2);
     accum = _mm_add_epi32(accum, mem);
     accum = _x_mm_rotl_epi32(accum, 13);
     accum = _mm_mullo_epi32(accum, prime1);

     mem = _mm_loadu_si128((__m128i *)p);
     p += 16;
     mem = _mm_mullo_epi32(mem, prime2);
     accum1 = _mm_add_epi32(accum1, mem);
     accum1 = _x_mm_rotl_epi32(accum1, 13);
     accum1 = _mm_mullo_epi32(accum1, prime1);
 } while (p<=limit);

 _mm_storeu_si128((__m128i *)vx, accum);
 _mm_storeu_si128((__m128i *)vx1, accum1);

 /*
  * Combine the two accumulators into a single hash value.
  */
 v1 = vx[0]; v2 = vx[1];
 v3 = vx[2]; v4 = vx[3];
 v1 += vx1[0] * PRIME32_2; v1 = XXH_rotl32(v1, 13); v1 *= PRIME32_1;
 v2 += vx1[1] * PRIME32_2; v2 = XXH_rotl32(v2, 13); v2 *= PRIME32_1;
 v3 += vx1[2] * PRIME32_2; v3 = XXH_rotl32(v3, 13); v3 *= PRIME32_1;
 v4 += vx1[3] * PRIME32_2; v4 = XXH_rotl32(v4, 13); v4 *= PRIME32_1;
 h32 = XXH_rotl32(v1, 1) + XXH_rotl32(v2, 7) + XXH_rotl32(v3, 12) + XXH_rotl32(v4, 18);

Functionally this is processing data in interleaved blocks or 16 bytes per block. This gives us two independent processing streams which should leverage the superscalar out-of-order execution capabilities on x86 processors and give a speedup. Diagrammatically this processing can be depicted as below.

sse_hash_small

Now lets look at the performance metrics of this new approach.

1) xxHash benchmark tool:
~/xxhash-read-only $ ./bench silesia.tar
*** Benchmark utility using xxHash algorithm , by Yann Collet (Jan 19 2013) ***
silesia.tar      :  206612480 ->  4028.9 MB/s   0x140BD4B4

2) Perf annotate output:
  5.95 │ 70:   movdqu (%rdi),%xmm1
  0.16 │       movdqu 0x10(%rdi),%xmm0
 14.91 │       pmulld %xmm5,%xmm1
  5.97 │       paddd  %xmm3,%xmm1
  0.05 │       movdqa %xmm1,%xmm3
  0.14 │       psrld  $0x13,%xmm1
  5.51 │       add    $0x20,%rdi
  0.60 │       pmulld %xmm5,%xmm0
  0.86 │       paddd  %xmm2,%xmm0
  5.32 │       movdqa %xmm0,%xmm2
  0.80 │       pslld  $0xd,%xmm3
  2.57 │       psrld  $0x13,%xmm0
  9.24 │       por    %xmm1,%xmm3
  0.05 │       pslld  $0xd,%xmm2
  5.94 │       por    %xmm0,%xmm2
  5.92 │       cmp    %rdi,%rax
  0.08 │       pmulld %xmm4,%xmm3
 27.12 │       pmulld %xmm4,%xmm2
  8.82 │     ↑ jae    70

3) Perf stat output:
*** Benchmark utility using xxHash algorithm , by Yann Collet (Jan 19 2013) ***
silesia.tar      :  206612480 ->  3997.0 MB/s   0x140BD4B4

 Performance counter stats for './bench silesia.tar':

    6183.451857 task-clock                #    0.995 CPUs utilized
            531 context-switches          #    0.086 K/sec
              7 CPU-migrations            #    0.001 K/sec
         50,625 page-faults               #    0.008 M/sec
 13,114,838,000 cycles                    #    2.121 GHz                     [83.28%]
  7,687,625,582 stalled-cycles-frontend   #   58.62% frontend cycles idle    [83.32%]
  2,157,403,461 stalled-cycles-backend    #   16.45% backend  cycles idle    [66.68%]
 14,508,523,299 instructions              #    1.11  insns per cycle
                                          #    0.53  stalled cycles per insn [83.34%]
    783,565,815 branches                  #  126.720 M/sec                   [83.32%]
        109,017 branch-misses             #    0.01% of all branches         [83.40%]
    6.211583495 seconds time elapsed

As you can notice there is a reduction in the Frontend cycles idle parameter and a good increase in the instructions per cycle. What is more significant is that throughput has increased from 3571 MB/s in the original to 4028 MB/s in the new one. A good 12.8% improvement over the original. I also did another benchmark using SMhasher, a hash function test suite. The results are below.

Original
========
Bulk speed test - 262144-byte keys
Alignment  0 -  1.865 bytes/cycle - 5335.63 MiB/sec @ 3 ghz
Alignment  1 -  1.863 bytes/cycle - 5329.93 MiB/sec @ 3 ghz
Alignment  2 -  1.863 bytes/cycle - 5329.93 MiB/sec @ 3 ghz
Alignment  3 -  1.863 bytes/cycle - 5329.94 MiB/sec @ 3 ghz
Alignment  4 -  1.868 bytes/cycle - 5345.33 MiB/sec @ 3 ghz
Alignment  5 -  1.864 bytes/cycle - 5334.29 MiB/sec @ 3 ghz
Alignment  6 -  1.864 bytes/cycle - 5334.27 MiB/sec @ 3 ghz
Alignment  7 -  1.864 bytes/cycle - 5334.28 MiB/sec @ 3 ghzModified
========
Bulk speed test - 262144-byte keys
Alignment  0 -  2.144 bytes/cycle - 6132.86 MiB/sec @ 3 ghz
Alignment  1 -  2.123 bytes/cycle - 6074.16 MiB/sec @ 3 ghz
Alignment  2 -  2.123 bytes/cycle - 6074.21 MiB/sec @ 3 ghz
Alignment  3 -  2.133 bytes/cycle - 6102.57 MiB/sec @ 3 ghz
Alignment  4 -  2.122 bytes/cycle - 6072.41 MiB/sec @ 3 ghz
Alignment  5 -  2.122 bytes/cycle - 6072.35 MiB/sec @ 3 ghz
Alignment  6 -  2.123 bytes/cycle - 6073.10 MiB/sec @ 3 ghz
Alignment  7 -  2.123 bytes/cycle - 6073.19 MiB/sec @ 3 ghz

SMhasher reports almost a 14% improvement in the worst case. For aligned data blocks it is processing at almost 6 GB/s! The small key results are not shown here but there is however an increase of 3 cycles in the worst case. I feel that marginal reduction in performance for small buffers/keys is acceptable for this gain for large buffers.

All these numbers are from my laptop. I’d expect better gains on better boxes and processors. I will have to run the full SMHasher test suite to validate my approach. My profit from all this is the learning experience and the potential speedup of deduplication in Pcompress.

Pcompress goes to 0.9.1

Now that encryption and message verification/authentication is done pushed out a couple of releases. Here’s some of the salient features that have come in after the initial implementation of AES encryption:

  1. Hash-based Message Authentication (HMAC)
  2. Optimized SHA256 for AMD platforms
  3. Fix build on Debian platforms (Linux Mint)
  4. Portable printf format string for unsigned int64 value to avoid gcc 4.6 warnings.

The HMAC functionality is available for all chunk digest algorithms namely SKEIN 256/512, SHA 256/512. For CRC64, SHA256 HMAC is used. The HMAC uses the same encryption key. However question now arises which items to verify using the HMAC. Ideally it should be everything in the file to ensure tampering is prevented. Now a Pcompress data file has a file header and every chunk in the file have their chunk headers. Every chunk includes a normal cryptographic disgest which can be SKEIN or SHA-2 to verify data integrity.

At this point applying a HMAC which is the same digest strengthened using an encryption key to the entire chunk data is wasteful. So what I have done is to apply the HMAC to the file header and the chunk headers. So file header is verified and chunk header is verified. The chunk header includes the normal chunk data digest which also gets verified by the HMAC. It is then used to verify integrity of the chunk data. This is good for performance since computing a HMAC is much more expensive than computing a standard cryptographic digest. Apart from these I added a few data validation checks during decompression to ensure that things like chunk sizes mentioned are within bounds.

With respect to the SHA256 optimizations, I found that Intel’s optimized implementations based on SSE 4.2 and AVX1 work fine on AMD Bulldozer and later platforms (Piledriver). So I have enabled those to be used on AMD with the SSE 4.2 and AVX1 feature detection. Thankfully AMD uses the same bits in ECX to indicate SSE4.2 and AVX1 capabilities.