Images snipped.
3.1.18 is kind'a buggy in cpu detection. In a Q8200 it says:
Checking CPU capatibility...
Intel(R) Core(TM) i5 CPU 670 @ 3.47GHz CPU arch supports AES_NI...YES.
SW built for AES_NI........NO.
Algo supports AES_NI.......YES.
CPU and algo support AES_NI, but SW build does not.
Rebuild with "-march=native" for better performance.
Starting mining without AES_NI optimizations...
...so naturally it thinks I have AES, even though the build is not for AES (-march=native no AES in Intel quad core q8200).
Anyway I did a profile run in x11 to check the slowdowns:
A couple of them, with echo512 being the biggest culprit, dominate the process in terms of time wasted.
It seems there is a very optimized AES version for it:
https://bench.cr.yp.to/impl-hash/echo512.htmlhttps://bench.cr.yp.to/impl-hash/echo512.htmlhttps://github.com/floodyberry/supercop/tree/master/crypto_hash/echo512/aes/aes64Let me get this straight. You compiled with -march=native on a core2 that thinks it's a i5-670.
The compile succeeded and the miner ran ok. That's pretty special.
The CPU model and AES support comes directly from CPUID and has been reliable until now.
Even the AMD guys haven't reported CPUID problems.
Can you confirm CPUID is correct:
catproc/cpuinfo |grep model
It would be interesting to see what the compiler thought:
gcc -march=native -Q --help=target | fgrep march
Regarding echo512, yes you will get the slow version. Unfortunately I'm unaware of a SSE2 optimized
version and the AES version is already used by cpuminer-opt on capable CPUs.
I have yet to study your data in any detail but the following may put performance into perspective.
Echo512 and groestl have AES optimizations for most algos.
Cryptonight and hodl have their own unique AES optimizations.
The rest of the x11 chain, including groestl but excluding echo, have SSE2 optimized versions.
The algos in the longer X chains, as well as non-aes echo, are filled with slow SPH versions.