Preventing compiler optimizations in benchmarks without a memory fence

[elichai]

As asked #667 (comment) this is the parts of #667 that don't require an assembly memory fence.

I splitted them to 2 commits, one with obvious easy ones. and another that changes the logic a bit to achieve this (See #667 (comment) )

[jonasnick]

ACK 362bb25

[real-or-random]

code changes in 362bb25 look good to me.

This fixes the two jacobi benchmark on gcc but for some reason it makes some of the benchmarks in clang noticeably faster (a few percents) on my machine, see the spreadsheet here: https://gist.github.com/real-or-random/68cf2e2ba7d9ab1fc6a50a7e3698fc8f/raw/e13e2485628016976cedc2ad58180050ddc6c071/362bb25.ods
Any idea why this is the case? Can you reproduce this?

[elichai]

@real-or-random Is there a commend to convert the data to the excel thing? or did you do it manually? :)

[elichai]

that's my stats:
https://gist.github.com/elichai/7cc8ac137c83565768d87387efae96bf

Seems like clang didn't optimize this from the beginning.
Not sure why it's faster but in my machine it's only by 8us

[real-or-random]

Anyway this is certainly an improvement.

ACK 362bb25 I read the diff and I ran the benchmarks

[elichai]

Can we get this merged? anything blocking? @sipa @apoelstra @gmaxwell

[sipa]

ACK, this is certainly an improvement. I'm not convinced that the compiler isn't still able to optimize some of these away, but there is only so much we can do.