Hacker News Reader

After experimenting more with this, it seems like with random generation the bottle neck is the "input generation" and not the hashing itself, that's why I went with sequential.

I replaced my nonce generation with a static string and my hashrate went to the moon, so I invested more time in optimizing my input generation.

View on HN

I profiled my code and you're right that it was using a big chunk of CPU on generating the input. Approximately 40-50% of the CPU time was taken up by go's rand.IntN function.

I was able to optimize it so that I only call rand.Int63 twice per string generation, bringing the CPU time of that part down to 10-15%. I'm getting 11.3 MH/s now!

There is really no point randomising at all, any cycles you spend on it are a total waste - one of the most important properties of a good hash algorithm is that a one bit change in the input should result in an output that's completely unrelated to the previous.

Your random number generator is pretty much equivalent to feeding a counter into SHA256, so using it as input is pretty much equivalent to hashing a counter twice. There's no point!

Yea, I know. It makes me feel better this way, though.

BTW, I changed it so it's iterative, getting 12.5 MH/s.

Reply on news.ycombinator.com