Bitcoin Forum
April 20, 2018, 07:21:12 PM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 187 »
  Print  
Author Topic: [ANN]: cpuminer-opt v3.8.7.2, open source optimized multi-algo CPU miner  (Read 405370 times)
joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 21, 2016, 08:12:47 PM
 #141

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.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1524252072
Hero Member
*
Offline Offline

Posts: 1524252072

View Profile Personal Message (Offline)

Ignore
1524252072
Reply with quote  #2

1524252072
Report to moderator
1524252072
Hero Member
*
Offline Offline

Posts: 1524252072

View Profile Personal Message (Offline)

Ignore
1524252072
Reply with quote  #2

1524252072
Report to moderator
zTheWolfz
Full Member
***
Offline Offline

Activity: 228
Merit: 100



View Profile
January 22, 2016, 04:52:51 AM
 #142

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.

I have one of the EVGA SR2's almost ready for test in VM, got late & had other problems delaying the completion. "AMD video drivers"  Shocked
Will try to finish that up later on tonight. I need to get out my old Linux HDD's and see what's on them for other rigs.
Might have to start fresh with all those.

Edit: hashrate is a bit all over the place, probably something on my end or server end.
http://www.xpool.ca/stats/18tvS3deKZK5q4eTtPRWYeEMWmGmuErHgz


 
joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 04:57:49 AM
 #143

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.

 

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.
I have this issue to investigate on my to do list

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 06:21:48 AM
 #144

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.

 

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


cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
zTheWolfz
Full Member
***
Offline Offline

Activity: 228
Merit: 100



View Profile
January 22, 2016, 09:41:11 AM
 #145

EVGA SR2 OC @ 3.33Ghz VM Ubuntu 15.10 VB set to 12 cores testing now some short results soon.
Hash looks low for this system I will look into that now and try a different server.

Code:
wolf@wolf-VirtualBox:~/Desktop/cpuminer-opt-3.0.2$ ./cpuminer -a x11 -o stratum+tcp://x11.usa.nicehash.com:3336 -u 18tvS3deKZK5q4eTtPRWYeEMWmGmuErHgz.SR2core12 -p d=0.01 -t 12

         **********  cpuminer-opt  v3.0.2  ***********
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi-1.2pre with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0 and Jeff Garzik.

Only quark and qubit support SSE at this time. Whenever mining
other algos with an SSE2 capable CPU the generic x86_64 miner
will be used.

Checking CPU capatibility...
        Genuine Intel(R) CPU             000  @ 2.13GHz
AES_NI: Yes, start mining with AES_NI optimizations...

[2016-01-22 03:15:53] Starting Stratum on stratum+tcp://x11.usa.nicehash.com:3336
[2016-01-22 03:15:53] 12 miner threads started, using 'x11' algorithm.
[2016-01-22 03:15:53] Stratum difficulty set to 0.01
[2016-01-22 03:15:54] x11.usa.nicehash.com:3336 x11 block 650802

zTheWolfz
Full Member
***
Offline Offline

Activity: 228
Merit: 100



View Profile
January 22, 2016, 10:39:58 AM
 #146

SR2 20 cores of 24

pallas
Legendary
*
Offline Offline

Activity: 1624
Merit: 1080


Black Belt Developer


View Profile
January 22, 2016, 10:56:34 AM
 #147

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);
       ^

joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 11:50:19 AM
 #148

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);
       ^


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.

Edit: That's Wolf0's cryptonight he contributed. You should take a look at the code. He's done some things I haven't a clue
what they are. He's been talking to Intel. At some point I'll dive in but I have others things on the go right now.

In what's becoming  a regular thing, I bring you a real time progress update.

Found small improvement in lyra2 which translated into an almost immeasurable improvent in lyra2v2.
Higher hash rates coming for sse2. aesni is mostly done for now. Code cleanup a tree restructuring planned.
Am I avoiding windows support? Maybe but I'm making a lot of changes to the makefile sources and I don't
want to have to make them in two places everytime. I'll do windows all at once.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
pallas
Legendary
*
Offline Offline

Activity: 1624
Merit: 1080


Black Belt Developer


View Profile
January 22, 2016, 11:53:03 AM
 #149

performance report with 3.0.2:

        AMD FX(tm)-8320 Eight-Core Processor           
AES_NI: Yes, start mining with AES_NI optimizations...

[2016-01-22 12:01:02] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-22 12:01:02] 8 miner threads started, using 'x11' algorithm.
[2016-01-22 12:01:02] Stratum difficulty set to 0.016
[2016-01-22 12:04:22] accepted: 1/1 (100.00%), 364.68 kH/s yes!
[2016-01-22 12:06:12] accepted: 2/2 (100.00%), 353.90 kH/s yes!
[2016-01-22 12:08:01] accepted: 3/3 (100.00%), 344.48 kH/s yes!
[2016-01-22 12:10:11] accepted: 4/4 (100.00%), 340.22 kH/s yes!
[2016-01-22 12:10:44] accepted: 5/5 (100.00%), 340.28 kH/s yes!

pallas
Legendary
*
Offline Offline

Activity: 1624
Merit: 1080


Black Belt Developer


View Profile
January 22, 2016, 11:58:13 AM
 #150

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);
       ^


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.

I would simply:

configure --disable-aesni

wolf0 did it on his cryptonight cpuminer.

joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 12:02:40 PM
 #151

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);
       ^


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.

I would simply:

configure --disable-aesni

wolf0 did it on his cryptonight cpuminer.

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?

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
pallas
Legendary
*
Offline Offline

Activity: 1624
Merit: 1080


Black Belt Developer


View Profile
January 22, 2016, 12:18:20 PM
 #152

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);
       ^


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.

I would simply:

configure --disable-aesni

wolf0 did it on his cryptonight cpuminer.

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 don't know if it works, it must be implemented first :-)
On linux you need to modify the m4 files and, possibly, add some precompiler directives.
That's why I suggested looking at how Wolf0 did it on his miner.

bobben2
Full Member
***
Offline Offline

Activity: 213
Merit: 100


View Profile
January 22, 2016, 04:44:17 PM
 #153

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0


Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

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.



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:
Code:
#include <stdio.h>

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"); }
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)


Mining Hobbyist
joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 07:03:30 PM
 #154

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0


Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

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.



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:
Code:
#include <stdio.h>

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"); }
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)



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

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
bobben2
Full Member
***
Offline Offline

Activity: 213
Merit: 100


View Profile
January 22, 2016, 07:23:46 PM
 #155

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

Mining Hobbyist
joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 07:35:34 PM
 #156

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


It looks like I have a lot of work to do. And getting windows to work has become a higher priority so I
can do my own testing on a core2.

I'll finish up v3.0.3 then get to work on windows.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 08:04:36 PM
 #157

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.

This problem is bigger than I anticipated. Along with the compile issues it appears  the advanced code isn't
properly identified and isolated.

In order to gather more information I will provide two special packages targeted for x86_64 and SSE2 each. That
will allow users to directly control which kernel is run. Hopefuly later today.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
bobben2
Full Member
***
Offline Offline

Activity: 213
Merit: 100


View Profile
January 22, 2016, 08:34:04 PM
 #158

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0


Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

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.



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:
Code:
#include <stdio.h>

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"); }
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)



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

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.


Mining Hobbyist
joblo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1015


View Profile
January 22, 2016, 08:39:23 PM
 #159

Hi Joblo,
Thank you for this initiative.  
I downloaded the 3.0.1 version.
It compiles (and runs) on my machines having i5 processors (Ubuntu 12.04), but it fails to compile on
my Intel Core 2 duo machine (Ubuntu 14.04), as well as on my old Athlon single core machine (Ubuntu 12.04).
Here is the build log (from ./build.sh) from the core 2 duo if interested.
https://www.dropbox.com/s/mbxje7fdntxgrkk/cpuminer_build.log?dl=0


Hi bobben,

Thank you for your interest. You are the first person to report with a CPU without AES_NI support and I only have AES_NI.
as a result cpuminer-opt on older CPUs is untested.

I hope we can work together to get this working. I will download and look at your compile but I'm busy right now
preparing another release. Stay tuned.

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.



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:
Code:
#include <stdio.h>

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"); }
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)



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

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 for the testing. This is the kind of testing I should be doing behind closed doors. I'm going to fire up
cygwin to see if I get get  a testing environment on al oder CPU of my own.

For now consider SSE2 ans x86_64 unsupported, will update OP.

cpuminer-opt developer, https://bitcointalk.org/index.php?topic=1326803.0
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
ETH: 0x72122edabcae9d3f57eab0729305a425f6fef6d0
pallas
Legendary
*
Offline Offline

Activity: 1624
Merit: 1080


Black Belt Developer


View Profile
January 22, 2016, 08:44:04 PM
 #160

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


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.

Pages: « 1 2 3 4 5 6 7 [8] 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 ... 187 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!