Cleanup of the switch from yescrypt to yespower

[solardiz]

I thought I'd only drop the misattribution from yespower.h and fix the dangerous bug of failing to check yespower_tls() return value, but I ended up noticing and fixing other issues as well.

Two things I left as-is for now for not knowing their rationale:

1. Why does sha256.h have extern "C" { ... } dropped? It has those in yespower 1.0, and nested ones are meant to work OK: https://stackoverflow.com/questions/48099828/what-happens-if-you-nest-extern-c

2. Why does yespower-opt.c have #undef unlikely added, and why only in the GCC-specific branch? At least the latter is probably a bug: if this name was somehow a previously defined macro, then it probably needs to be undefined for non-GCC as well. But I didn't find any other code in the tree that would define this macro.

These changes are untested, but they got to work. ;-) So perhaps test them before merging. Not being even a user of Koto, I feel it'd be too much for me to also contribute testing. ;-)

[okoto-xyz]

These source files are that I copied from cpuminer-yescrypt.
Regarding the case AVX code was disabled, I think it was implimented to pursue faster performance as much as possible.
Actually, I also observed slightly faster result on testing for inline asm (AVX disabled) code with -march=native compile option.
but in case of only -mavx option, sandybridge and haswell ares slower and skylake is faster.

asm: inline asm (Koto cpuminer optimized)
avx: avx code (original yespower)
based on benchmark.c in yespower-1.0.0, gcc 7.3.0

For Koto core daemon, it seems that there are no -mavx or -march=native option for build script therefore Koto will be compiled with sse2 option in most case because gcc for x86_64 is sse2 enabled by default.
However, considering Koto core daemon is used in various cpu environments and compile options,
it should be a safe code as @solardiz pointed out.

[solardiz]

I'm sorry I sent this PR against master - apparently, it should have been against develop.

Yes, cpuminer will need similar changes, and probably more: I'd fully replace the old yescrypt code with yespower, not be adding yespower while still keeping the old yescrypt code like it's been done.

Regarding the speeds, I'm aware that the SSE2 inline asm is typically the fastest - that's why I wrote and included it in there. We just shouldn't use it in AVX-enabled builds for the reason I mentioned. Unfortunately.

Koto's cpuminer should probably build for SSE2 by default, not use any "native" optimization flags.

None of your benchmarks include plain SSE2 builds. You always try to enable some native instruction set in the compiler, and that allows the compiler to also include AVX and even AVX2 instructions in other places, which as I explained might hurt. It'd be useful to include a plain SSE2 build in your comparison. Quite possibly it'll be the fastest on at least some of those CPUs.

In PERFORMANCE file for yespower, I included this wording:

On x86(-64), the following code versions may reasonably be built: SSE2,
AVX, and XOP.  (There's no reason to build for AVX2 and higher, which is
unsuitable for and thus unused by current yespower anyway.  There's also
no reason to build yespower as-is for SSE4, although there's a disabled
by default 32-bit specific SSE4 code version that may be re-enabled and
given a try if someone is so inclined; it may perform slightly slower or
slightly faster across different systems.)

yescrypt and especially yespower 1.0 have been designed to fit the SSE2
instruction set almost perfectly, so there's very little benefit from
the AVX and XOP builds, yet even at yespower 1.0 there may be
performance differences between SSE2, AVX, and XOP builds within 2% or
so (and it is unclear which is the fastest on a given system until
tested, except that where XOP is supported it is almost always faster
than AVX).

For the old yescrypt/yespower 0.5 mode, AVX and XOP matter slightly more, because the code uses Salsa20 more, and Salsa20 benefits from AVX and XOP. Especially when r is low, like it is in Koto. So it is possible AVX is of some help, and it is even possible that the SSE2/AVX mix is the fastest on some builds on some CPUs - but this is risky territory as huge slowdowns may be observed in different builds and/or on different CPUs. I once observed a ~30x slowdown from tight mix of SSE2/AVX2 on Haswell. No joke.

[okoto-xyz]

I ran benchmark again with SSE2.
Certainly plain SSE2 build is the fastest performance on Haswell and Skylake.
Interesting.

For Ryzen, AVX seems to be slightly faster.

[solardiz]

These new results make sense to me as it relates to relative speeds of the different builds. I'm a bit surprised i5-6500 (3.3 GHz all-core turbo) performs so poorly - I'd expect it to be closer to i5-4590 (3.5 GHz all-core turbo). I'm not surprised i5-4590 performs much worse than i7-4770K, for which I included a comparable benchmark result in PERFORMANCE - it gives 3773 H/s there on CentOS 7 and with default "gcc version 4.8.5 20150623 (Red Hat 4.8.5-28)" - that's clock rate difference (all-core turbo 3.7 GHz) combined with cache size difference (8 vs. 6 MiB). Maybe there's something "wrong" with the specific i5-6500 system - e.g., only one DIMM installed. Whatever.

For the Ryzen 1700 system, optimal thread count is probably 16 or 8, not 4 which you measured - or is that an error in the footnote? The speed is unrealistically high for 4 threads.

In PERFORMANCE, I recommend limiting the threads to physical cores, but that's for yespower 1.0. For yespower 0.5 mode, some systems will benefit from matching logical CPU count and some others from matching physical cores, but either way the performance differences are smaller and this isn't as important as it is for yespower 1.0 mode.

[okoto-xyz]

That's right.
i5-6500 was result of single channel DIMM.
Ryzen was result of 8 threads. I updated the image. 12 threads was the best result.

[solardiz]

Also related: Koto adds libbitcoin_common_a_CFLAGS = -fPIC, which I understand was needed for the build to succeed at all (because of -fPIE on linking, inherited from Zcash, which they had for security hardening?), but possibly this leaves out the optimization flags when building yespower C files. A better alternative line may be libbitcoin_common_a_CFLAGS = $(libbitcoin_common_a_CXXFLAGS) (works for me when integrating yespower in another tree, not Koto) or even libbitcoin_common_a_CFLAGS = $(libbitcoin_common_a_CXXFLAGS) -O2 -fomit-frame-pointer to optimize these files in that way regardless of whether the rest of the tree is built with optimizations or not.