1 thread: ~4200 khash/s
2 threads: ~7700 khash/s
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
2 threads: ~7700 khash/s
Suffice it to say that I leverage SSE instructions to calculate four hashes at once, per thread.
I tried to implement your idea and my SSE code is almost exactly 4x as fast as the vanilla code (~2000 khash/s with one thread, up from ~500). However, when running two threads I only get ~3000 khash/s. There is room to optimize my code, but still, the improvement is way lower that yours.
Actually, I re-examined my changes based on your results and I think I may have messed up the rate calculation. Since it calculates four hashes per loop iteration I multiplied the increment to nHashCounter by four, but in retrospect it's already accounting for that by incrementing the nonce four times as quickly. Ergo, the rate was displayed as 4x higher than actual. For reference, I've generated 300 BTC (six blocks) since I started using the program on the 11th of this month, which works out to about one block out of every 400 (0.25%). Is that about what you're getting? It looks like your version should be a bit faster than mine, which is only to be expected--this was my first attempt at using SSE, or for that matter any kind of SIMD optimization.
I should've known it wouldn't be quite so simple.
I don't think pure SSE can be exactly four times as fast as a well optimized C code, mostly because SSE lacks rotate instructions. Did you implement SHA completely in SSE or are you mixing SSE and C?
I implemented the rotates as ((x >> y) | (x << (32-y))), using SSE opcodes for the shifts. It's implemented completely in C, using GCC's vector extensions--no direct assembly code. I did use intrinsics for the shift operations, since the shift operators aren't implemented for vectors. The rest looks much like the original version.