Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 191. (Read 444067 times)

Of course it doesn't work. You compiled for a cpu which isn't compatible with yours. The compiler used some instructions which your cpu doesn't understand.

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

I deleted all the source files, after suspecting make clean doesnt clean out all the object files. 
Then I did a fresh untar of version 3.0.2.
This time, it compiled and linked cleanly.   But still core dump when running.
I tried changing the miner_thread to force a particular cpu architecture, as you suggested:
    bool cpu_aesni = has_aes_ni();
    bool cpu_sse2  = has_sse2();
cpu_aesni = false;
cpu_sse2 = false;
then
cpu_aesni = false;
cpu_sse2 = true;
then
cpu_aesni = true;
cpu_sse2 = true;
but none worked.
I then tried to recompile with the -g switch, but I got new errors....

./algo/sse2/groestl/grso-asm.c: In function ‘grsoP1024ASM’:
./algo/sse2/groestl/grso-asm.c:6:3: error: ‘asm’ operand has impossible constraints
   asm (
   ^

Too many problems with the miner on this CPU.. It might take some effort to fix this.  You may want to put this lower on your priority list.

Thanks a lot for the data. It's clear  the support for older cpus just isn't there yet. That's what happens when one can't
ddo his own testing I need to change that. I have a core2quad but it runs windows, I guess I'll have to get widows
workinh sooner than later..

In the meantime, since youseem comfortable in the code I have a request to gather more data with some instrumented
code.

In file cpu-miner.c, function miner_thread there is a big switch statement casing on each algo. You will notice how
I select the proper kernel. Simly comment out a few lines to force either the sse2 version or x64 version to run
regardless of the detected CPU technology.

If you could do this for several algos it would help identify any code contamination.

The sausage factory in action. It ain't pretty and better done behind closed doors.

Edit: try forcing all three kernels to run to see at what level your core2 fails. thanks

A compile issue has been discovered whenusing older CPUs that don't support AES_NI,
specifically a core2.

I am reconsidering support for older HW in light of the fact there seems to be little
demand for it.

The cpuminer-opt package includes AES_NI code that can't run  on the native CPU. The
configure command includes the compile option "-march=native" tells the compiler not to
compile code that can't run on the native CPU. As a result the compiler throws an error and
the compile fails.

The code has runtime checks to isolate the AES_NI code from incompatible CPUs, the issue
is compiling.

I have suggested a workaround to change the compile option to specify an architecture that
does support AES_NI. To do this change "-march=native" to "-march=corei7-avs" or someting
similar.

At his time I have no feedback on the success of this workaround.
Should the workaround fail I will be forced with a decision.

I can try to find a compiler directive to selectively exclude specific code based on architecture.
I that is unsussesful I will have a couple of options.

I could drop support altogether for non AES_NI CPUs. The is still the TPruvot fork that is compatible
with all x86_64 CPU. But that leaves out the in-betweeners that have sse2 but not AES_NI.

I'm almost finished with the sse2 optimizations so I could build a special final release for sse2.
but only if there is interest. And I don't mean posting and saying do it. I mean substantial interest
like posting results showing you are trying to use cpuminer-opt. on an old CPU.
Please note that x86_64 is the absolute minimum HW arctitecture supported.

How 'bout it?  

Edit: I have some small hashrate increases in a couple of algos but not enough for another release yet.

Just for fun I tried to compile miner version 3.0.2 on my old Athlon, setting march=corei7-avx in the configure.
And it compiled without a hitch. 

Then tried to run it, but it core dumps :

Checking CPU capatibility...
        AMD Athlon(tm) 64 Processor 3200+
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 20:15:18] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 20:15:18] 1 miner threads started, using 'qubit' algorithm.
/home/bobben/miner_cpu_qubit: line 12:  5354 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

I changed march as you suggested.  I got a bit further, but still errors.
I commented out the content of the functions in  algo/sse2/groestl/grso-asm.c as it was throwing errors.
Then I created a dummy .c file which I compiled and added to the link statement with the following content as these functions were missing:
I then got the program linked, but it core dumps when I start it:
 
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-22 17:41:29] Starting Stratum on stratum+tcp://hashpower.co:4733
[2016-01-22 17:41:29] 2 miner threads started, using 'qubit' algorithm.
/home/arve/miner_cpu_qubit: line 11:  3379 Illegal instruction     (core dumped) cpuminer -t $thr -a qubit -o stratum+tcp://hashpower.co:4733 -u $ADDR_BTC

According to /proc/cpuinfo the core 2 duo has sse2, so I am surprised at the program conclusion..

Here is the info from gdb after I recompiled with -g

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `cpuminer -t 2 -a qubit -o stratum+tcp://hashpower.co:4733 -u 19eSQxSAL9PuTF8gfW'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x000000000064595d in jsonp_strtod (strbuffer=0x7f69bae93ca8,
    out=0x7f69bae93a88) at strconv.c:69
69          value = strtod(strbuffer->value, &end);
(gdb)

I took a look at your build file and I think I know what the problm is. The package contains code for CPUs with
AES_NI but your cpu can't handle it. The miner can handle this at run time but compiling is the issue.
the compiler option -march=native means to build for your CPU. Since your CPU can't run AES_NI instructions
the compiler refuses to compile it. If we can get it compiled I think it will run fine because cpuminer-opt checks
the CPU architectire in order to select code to run for the correct CPU architecture.

I have an idea for a workaround. We can fool the compiler into think it is bulding for an AES_NI CPU but in fact
we'll run it on your core2. Change the configure option "-march=native" to "-march=corei7-avx" and see if it
compiles. If successful try to run it and note the startup messages regarding the CPU capabilities.

I hope this works.

Edit: Only 64 bit CPU are supported.

#include 

void quarkhash_aes()  { fprintf(stderr,"This should not happen\n"); }
void quarkhash_sse2() { fprintf(stderr,"This neither\n"); }
void qubithash_aes() {  fprintf(stderr,"Nor this\n"); }

If you're confirming it works for you, I'll document in the build instructions for next release. Know
how to do it on VS?

I would simply:

configure --disable-aesni

wolf0 did it on his cryptonight cpuminer.

I posted about this back half a page or so. Try using -march=corei7-avx. It seems counter intuitive but we need
to fool the compiler to compile the AESNI code. Once compile the run time checks will avoid falling into it.
If you know of the appropriate compiler directive to check CPU architecture, please advise.

Tried compiling on a non-aesni cpu (core2), but it tries to use  aesni on cryptonight:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
                 from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
 _mm_aeskeygenassist_si128 (__m128i __X, const int __C)
 ^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
  tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
       ^

Thanks. I've made a breakthrough with a nagging problem.  Sorry it's not windows (yet), but will give relatively big
hash rate increase in quark & x* in a day or two.

Edit: Due to the low hash rate of cpu miners in general the share submits aren't very frequent. This causes the
pool reported hash rate to fluctuate from about 50% below what the miner reports to sometimes 200%. I would
consider that normal. If the submit rate was higher the graph would be smoother and should be around the hash
rate reported by the miner.

In theory you don't lose anything because fewer shares means they are bigger.

However, there is a possibility of hash being wasted if a block goes stale while you are working on it
and that is more likely with a low hash rate. I have this issue to investigate on my to do list

v3.0.2 seems to be running very well, only 19 rejects out of over 10k summits.
6700GH 4 cores used x11 coin. VM=Ubuntu 15.10 x86_64
Thanks for your hard work you put into this.