Bitcoin Forum
January 18, 2018, 08:54:02 AM *
News: Electrum users must upgrade to 3.0.5 if they haven't already. More info.
 
   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 59 ... 165 »
  Print  
Author Topic: [ANN]: cpuminer-opt v3.7.10, open source optimized multi-algo CPU miner  (Read 390416 times)
joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 22, 2016, 08:57:06 PM
 #161

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.

I realize an old computer can't run new instructions but I assumed the run time checks would protect it. Obviously I was wrong.
I need compile time checks to avoid compiling the aesni code on older cpus. I also need to find out if the lower level kernels
are poluted with higher level code, among many other things.

I'll see if cygwin can come to my rescue.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
1516265642
Hero Member
*
Offline Offline

Posts: 1516265642

View Profile Personal Message (Offline)

Ignore
1516265642
Reply with quote  #2

1516265642
Report to moderator
1516265642
Hero Member
*
Offline Offline

Posts: 1516265642

View Profile Personal Message (Offline)

Ignore
1516265642
Reply with quote  #2

1516265642
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
pallas
Legendary
*
Offline Offline

Activity: 1526


Black Belt Developer


View Profile
January 22, 2016, 09:05:05 PM
 #162

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.

I realize an old computer can't run new instructions but I assumed the run time checks would protect it. Obviously I was wrong.
I need compile time checks to avoid compiling the aesni code on older cpus. I also need to find out if the lower level kernels
are poluted with higher level code, among many other things.

I'll see if cygwin can come to my rescue.

Hmmmm the check itself could be made of incompatible instructions.... every part of the code could. It's not just AES_NI but many other extensions as well.
You just can't compile for a pentium and expect it to run on a 386!

joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 22, 2016, 09:24:39 PM
 #163

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.

I realize an old computer can't run new instructions but I assumed the run time checks would protect it. Obviously I was wrong.
I need compile time checks to avoid compiling the aesni code on older cpus. I also need to find out if the lower level kernels
are poluted with higher level code, among many other things.

I'll see if cygwin can come to my rescue.

Hmmmm the check itself could be made of incompatible instructions.... every part of the code could. It's not just AES_NI but many other extensions as well.
You just can't compile for a pentium and expect it to run on a 386!

Good point. The aesni check on an old cpu might return garbage results.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 23, 2016, 12:45:31 AM
 #164

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 23, 2016, 02:43:47 AM
 #165

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
zTheWolfz
Full Member
***
Offline Offline

Activity: 227


View Profile
January 23, 2016, 04:49:59 AM
 #166

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I want to thank you for all your hard work, without your work I'd still be stuck in the stone age. lol
I now can do the same hashrate on a laptop and one SR2 that I was getting with 3xSR2's and
one 32 core AMD rig and the bigger catch is I'm making more with much less power. Old scyptjane
miner was 1.38 hash 3xSR2 plus the AMD rig. I'm now seeing 1.5 hash on just a laptop & 1x SR2.  Grin

I"m having a bit of a problem compiling on the AMD rig with errors. All same software but I may
need different library files on the AMD system? I had errors of missing files on the Intel systems
but those were easy found by what it posted the errors where about, but not so with the AMD system.
Of course the main OS that the VM sets on is Windows Server and could be playing apart with the errors.

Its been a really long day "up over 24h" now and I'm not at that rig so I will go into that more when I'm sure
to be able to give all the correct info. I'd like to make a donation to you for your hard work but that will
have to wait a bit only 0.2 BTC in my wallet at the moment, but once I get every thing swapped over that should change quickly.
joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 23, 2016, 09:28:16 AM
 #167

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

Didn't someone tell me mingw was easy?

After peeling the onion with missing dll's  I ended up draggin along about ten of them.
But now there's something i've never seen.

cpuminer starts up but crashes on a call to parse-arg.  The function and the calls are all
in cpu-miner.c, there's nothng special about it just a simple function call. BUT wew nevr get
there. I have a printf on the line before the call to parse arg and another just inside the opening
brace in parse_arg and only one gets hit before the crash. Itg's crashing on a simple function call.

I dpn't know how to get past this.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
pallas
Legendary
*
Offline Offline

Activity: 1526


Black Belt Developer


View Profile
January 23, 2016, 09:32:29 AM
 #168

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

Didn't someone tell me mingw was easy?

After peeling the onion with missing dll's  I ended up draggin along about ten of them.
But now there's something i've never seen.

cpuminer starts up but crashes on a call to parse-arg.  The function and the calls are all
in cpu-miner.c, there's nothng special about it just a simple function call. BUT wew nevr get
there. I have a printf on the line before the call to parse arg and another just inside the opening
brace in parse_arg and only one gets hit before the crash. Itg's crashing on a simple function call.

I dpn't know how to get past this.

I compiled sgminer on windows using mingw, it wasn't trivial but following the instructions I made it.
About your specific crash issue, is it code you wrote or modified, or was it there for long?
Maybe it's just some issue with memory allocation.

joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 23, 2016, 10:31:20 AM
 #169

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

Didn't someone tell me mingw was easy?

After peeling the onion with missing dll's  I ended up draggin along about ten of them.
But now there's something i've never seen.

cpuminer starts up but crashes on a call to parse-arg.  The function and the calls are all
in cpu-miner.c, there's nothng special about it just a simple function call. BUT wew nevr get
there. I have a printf on the line before the call to parse arg and another just inside the opening
brace in parse_arg and only one gets hit before the crash. Itg's crashing on a simple function call.

I dpn't know how to get past this.

I compiled sgminer on windows using mingw, it wasn't trivial but following the instructions I made it.
About your specific crash issue, is it code you wrote or modified, or was it there for long?
Maybe it's just some issue with memory allocation.

Tnaks for all your help Pallas, I reaklly apprecciate it even though I don't always say so.

The code that crashed was unchanged by me. It's part of the command line argument parsing
and I haven't gone near it. A hand written traceback looks like this:

parse_arg       <- crashes here beofre enterring parse_arg
parse_cmdline
main

I can't see it being a run time issue, it happened on two PCs. It must be a compile issue,
a reproduceable compile issue. The same code runs fine in linux.

But it gets worse, much worse.

After installing mingw I couldn't compile for linux anymore even though it was
in another source tree where I had never run mingw. Somehow mingw took over my system and
I could only compile for windows.

I managed to recover by uninstalling mingw and doing a make distclean but there a few moments of
panic.

It's just too risky to pursue this at this point. When my nerves settle down I may try again in the safety
of a VM but windows support is going to have to wait a little longer.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
pallas
Legendary
*
Offline Offline

Activity: 1526


Black Belt Developer


View Profile
January 23, 2016, 11:00:58 AM
 #170

Safer and easier: a VM with windows and mingw in it.
No visual studio, no conflicts ;-)

bobben2
Full Member
***
Offline Offline

Activity: 194


View Profile
January 23, 2016, 04:47:29 PM
 #171

Hi Joblo.
An update on cpuminer 3.0.2 on Core 2 duo.
I managed to get it going - at least mining X11.

Code:
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-23 17:25:40] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-23 17:25:40] 2 miner threads started, using 'x11' algorithm.
[2016-01-23 17:25:41] Stratum difficulty set to 0.016
[2016-01-23 17:25:41] hashpower.co:3533 x11 block 652575
[2016-01-23 17:25:47] CPU #1: 43.13 kH/s
[2016-01-23 17:25:47] CPU #0: 43.13 kH/s
[2016-01-23 17:25:54] hashpower.co:3533 x11 block 652576
[2016-01-23 17:25:54] CPU #0: 43.07 kH/s
[2016-01-23 17:25:54] CPU #1: 43.07 kH/s

As you can see the hashrate is not great, and even worse (actually half) if I dont override the return from the has_sse2() function which doesnt work in this case.
Here is a list of the changes I did to get it working:

../cpuminer-opt-3.0.2/algo/aes_ni/groestl/groestl-intr-aes.h <- Added #ifdef HAVE_AESNI to exclude the aesni code from being compiled.
../cpuminer-opt-3.0.2/algo/aes_ni/echo512/hash.c  <- remove inline keyword. Also added #undef AES_NI
..//home/arve/cpuminer/joblo3.0.2/cpuminer-opt-3.0.2/algo/ <- remove inline keyword in
qubit-aes.c
quark-sse2.c
quark-aes.c
../cpuminer-opt-3.0.2/cpu-miner.c line 1947 force cpu_sse2 = true

In my opinion it should be possible to add a switch when running configure to disable-aesni ?



Mining Hobbyist
joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 23, 2016, 05:26:10 PM
 #172

Hi Joblo.
An update on cpuminer 3.0.2 on Core 2 duo.
I managed to get it going - at least mining X11.

Code:
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-23 17:25:40] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-23 17:25:40] 2 miner threads started, using 'x11' algorithm.
[2016-01-23 17:25:41] Stratum difficulty set to 0.016
[2016-01-23 17:25:41] hashpower.co:3533 x11 block 652575
[2016-01-23 17:25:47] CPU #1: 43.13 kH/s
[2016-01-23 17:25:47] CPU #0: 43.13 kH/s
[2016-01-23 17:25:54] hashpower.co:3533 x11 block 652576
[2016-01-23 17:25:54] CPU #0: 43.07 kH/s
[2016-01-23 17:25:54] CPU #1: 43.07 kH/s

As you can see the hashrate is not great, and even worse (actually half) if I dont override the return from the has_sse2() function which doesnt work in this case.
Here is a list of the changes I did to get it working:

../cpuminer-opt-3.0.2/algo/aes_ni/groestl/groestl-intr-aes.h <- Added #ifdef HAVE_AESNI to exclude the aesni code from being compiled.
../cpuminer-opt-3.0.2/algo/aes_ni/echo512/hash.c  <- remove inline keyword. Also added #undef AES_NI
..//home/arve/cpuminer/joblo3.0.2/cpuminer-opt-3.0.2/algo/ <- remove inline keyword in
qubit-aes.c
quark-sse2.c
quark-aes.c
../cpuminer-opt-3.0.2/cpu-miner.c line 1947 force cpu_sse2 = true

In my opinion it should be possible to add a switch when running configure to disable-aesni ?


That's great news after another difficult day trying to get windows working.
The generic kernel is pretty slow as shown in the performce charts. Support is
more about compatibility than performance. The sse2 kernels are looking
pretty good, relatively speaking.

It seems the SSE2 check fails on your core2 but when you force it the SSE2 kernel
runs fine. Is that correct?

I'll restore all the compiler directives, I had removed them LOL, when I was hacking and slashing
the code an focussed only on the top tier.

I'll follow up on your findings, thanks a lot.

Edit: Another dramatic turn of events, this time a positive one!

Reenabling the AESNI_NI defines (and the companion OPTIMIZE_SSE2 has unlocked a ton
more performance thaty had been hidden by chainsaw approach.

X11 is up to 865 from 720 on my i7-4790K, but things aren't perfect, I see some rejects.
Some of the exposed code may not be perfect and may require a scalple to cut out the
cancer.

I've got a lot of work to do but I'm back on track.

BTW thanks for the excelllent report, very clear, complete, and precise. I followed it like  a script.

---------------------------------------------------------

Edit:

It looks like the dramatic sped increase was due to an error on my part. It seems the #define AES_NI
I put in miner.h isn't being seen. I had to #define it in every file that uses it. Clumsy but it works.

I'm building a debug tarbar so you can do some better testing. It will require you to make some small
code changes. I will send a PM with a link to the file.

Here's how it works:

Default is to enable and respect all AES_NI checks.

Edit: changed default configuration for your convenience.

Will disable AES_NI because we already know your CPU can't handle it

To force disable AES_NI you have to do two things before compiling:
    - in cpu-miner.c:1945 hard code cpu_aesni to false
 - remove #define AESNI from all algos, grep -r AES_NI to find them all, sorry

To force disable SSE2
  - in addition to the steps above hard code cpu_sse2 to false

These changes will affect kernel selection only, the start up capability check is still performed but not enforced.
This should solve the compile problem you had and allow you to do more testing.
The ugly workarounds are for the debug load only. I will investigate a more user firendly implentation
before release. Any suggestions welcome, including why the algos don't pick up the #define in miner.h

The goals of the further testing:

1. confirm the capability of your core2 CPU

2. determine if cpuminer-opt can correctly identify your CPU's capability level and select the appropriate kernel

3. compare sse2 vs x86_64 performance.

The first two are pretty obvious The third will allow me to extrapolate an estimate of the hash deficit of SSE2 vs AES_NI
and split it into the HW component and software component. How much of the loss is due purely due to the lack of
AES_NI and how much is due to other CPU optimizations in the latest generation.

Thanks for the great work.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
zTheWolfz
Full Member
***
Offline Offline

Activity: 227


View Profile
January 23, 2016, 11:25:56 PM
 #173

Looks to compile okay up until this point:

Code:
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: [color=red]error[/color]: 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);
       ^
Makefile:1819: recipe for target 'algo/cryptonight/cpuminer-cryptonight-aesni.o' failed
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:2682: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive][color=red] Error [/color]1
make[1]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:599: recipe for target 'all' failed
make: *** [all] Error 2
thewolf2@thewolf2-VirtualBox:~/Desktop/cpuminer-opt-3.0.2$ error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’[color=red]error[/color]: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’
joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 24, 2016, 01:35:58 AM
 #174

Looks to compile okay up until this point:

Code:
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);
       ^
Makefile:1819: recipe for target 'algo/cryptonight/cpuminer-cryptonight-aesni.o' failed
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:2682: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:599: recipe for target 'all' failed
make: *** [all] Error 2
thewolf2@thewolf2-VirtualBox:~/Desktop/cpuminer-opt-3.0.2$ error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’

That's interesting. The code decided to fail the compile. I've never seen that before.
What CPU?

I presume this is v3.0.2? No one else has reported this problem. I'll be releasing v3.0.3 soon I hope,
if bobben2's testing goes well. Meanwhile I'l take a look at the code and try to figure out what's going on.

Edit: I compared the code to Wolf0' original and nothing stood out. You could try downloading again maybe
the download was corrupt.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
zTheWolfz
Full Member
***
Offline Offline

Activity: 227


View Profile
January 24, 2016, 01:54:50 AM
 #175

Looks to compile okay up until this point:

Code:
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);
       ^
Makefile:1819: recipe for target 'algo/cryptonight/cpuminer-cryptonight-aesni.o' failed
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:2682: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:599: recipe for target 'all' failed
make: *** [all] Error 2
thewolf2@thewolf2-VirtualBox:~/Desktop/cpuminer-opt-3.0.2$ error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’

That's interesting. The code decided to fail the compile. I've never seen that before.
What CPU?

I presume this is v3.0.2? No one else has reported this problem. I'll be releasing v3.0.3 soon I hope,
if bobben2's testing goes well. Meanwhile I'l take a look at the code and try to figure out what's going on.
Yes v3.0.2 It has 4x 6124 HE 1.8Ghz CPU's OCed to 2358Ghz easy 300k+ PPD Folding at Home rig.
16x2GB GSkill ram 32GB quad channel memory set. 4x Hyper12 coolers.
Motherboard H8QGi+F w/ Tech Station w/ 64GB SSD HDD. Old picture below with AMD video card it now host a GTX660Ti
v3.0.2 compiled fine on the Intel CPU I have test with so far. So it could be a AMD thing.
http://www.cpu-world.com/CPUs/K10/AMD-Opteron%206124%20HE%20-%20OS6124VAT8EGO.html

http://www.superbiiz.com/detail.php?name=MB-H8QGIF&c=FR&pid=7cf0fe6d5b2d53d138f6a5a40fa803c7e448d1f83de651ede82ab086f2bcae9c&gclid=Cj0KEQiA5oy1BRDQh6Wd572hsfkBEiQAfdTPCggsWJEaG_HfIyWyY5szrIbLSFr5yVUv96QTKBmyJGoaAs068P8HAQ


joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 24, 2016, 02:35:17 AM
 #176


I presume this is v3.0.2? No one else has reported this problem. I'll be releasing v3.0.3 soon I hope,
if bobben2's testing goes well. Meanwhile I'l take a look at the code and try to figure out what's going on.
Yes v3.0.2 It has 4x 6124 HE 1.8Ghz CPU's OCed to 2358Ghz easy 300k+ PPD Folding at Home rig.
16x2GB GSkill ram 32GB quad channel memory set. 4x Hyper12 coolers.
Motherboard H8QGi+F w/ Tech Station w/ 64GB SSD HDD. Old picture below with AMD video card it now host a GTX660Ti
v3.0.2 compiled fine on the Intel CPU I have test with so far. So it could be a AMD thing.
http://www.cpu-world.com/CPUs/K10/AMD-Opteron%206124%20HE%20-%20OS6124VAT8EGO.html

http://www.superbiiz.com/detail.php?name=MB-H8QGIF&c=FR&pid=7cf0fe6d5b2d53d138f6a5a40fa803c7e448d1f83de651ede82ab086f2bcae9c&gclid=Cj0KEQiA5oy1BRDQh6Wd572hsfkBEiQAfdTPCggsWJEaG_HfIyWyY5szrIbLSFr5yVUv96QTKBmyJGoaAs068P8HAQ




We'll that explains it. Wolf0 has used some scary optimization techniques that he got directly from Intel and
the compile failed in Intel code. My guess is it's a trick to prevent inlining on the competition's CPUs to make
their's look better. Good one.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
pallas
Legendary
*
Offline Offline

Activity: 1526


Black Belt Developer


View Profile
January 24, 2016, 09:53:07 AM
 #177

Both 3.0.2 and Wolf0's cryptonight do compile fine on my amd fx.

joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 24, 2016, 10:12:35 AM
 #178

Both 3.0.2 and Wolf0's cryptonight do compile fine on my amd fx.

But I've just discovered 3.0.2 cryptonight is broken.

I've prepared a debug build for bobben2 to address his compile problems on an older CPU
(not the same issue you replied to). I've got a start toa solution but I want to make sure
I've properly isolated the AES_NI code from the compiler. For now I need to #define the
swiitch in every file that references it even though it's #defined in miner.h which everyone
#includes. Probably just another noob mistake.

I think I can get configure to pass the swutch to the compile environment the same way
it does for the package version. I might even be able to get configure to determine the CPU
architecture on its own (it would have to be accurate) and make the whole process
transparent to the user. Otherwise it wold be an option to the configure script.

I'm learning but there are still areas where I seem to repeatedly make the same mistake.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
bobben2
Full Member
***
Offline Offline

Activity: 194


View Profile
January 24, 2016, 12:06:59 PM
 #179

Hi Joblo.
An update on cpuminer 3.0.2 on Core 2 duo.
I managed to get it going - at least mining X11.

Code:
Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-23 17:25:40] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-23 17:25:40] 2 miner threads started, using 'x11' algorithm.
[2016-01-23 17:25:41] Stratum difficulty set to 0.016
[2016-01-23 17:25:41] hashpower.co:3533 x11 block 652575
[2016-01-23 17:25:47] CPU #1: 43.13 kH/s
[2016-01-23 17:25:47] CPU #0: 43.13 kH/s
[2016-01-23 17:25:54] hashpower.co:3533 x11 block 652576
[2016-01-23 17:25:54] CPU #0: 43.07 kH/s
[2016-01-23 17:25:54] CPU #1: 43.07 kH/s

As you can see the hashrate is not great, and even worse (actually half) if I dont override the return from the has_sse2() function which doesnt work in this case.
Here is a list of the changes I did to get it working:

../cpuminer-opt-3.0.2/algo/aes_ni/groestl/groestl-intr-aes.h <- Added #ifdef HAVE_AESNI to exclude the aesni code from being compiled.
../cpuminer-opt-3.0.2/algo/aes_ni/echo512/hash.c  <- remove inline keyword. Also added #undef AES_NI
..//home/arve/cpuminer/joblo3.0.2/cpuminer-opt-3.0.2/algo/ <- remove inline keyword in
qubit-aes.c
quark-sse2.c
quark-aes.c
../cpuminer-opt-3.0.2/cpu-miner.c line 1947 force cpu_sse2 = true

In my opinion it should be possible to add a switch when running configure to disable-aesni ?


That's great news after another difficult day trying to get windows working.
The generic kernel is pretty slow as shown in the performce charts. Support is
more about compatibility than performance. The sse2 kernels are looking
pretty good, relatively speaking.

It seems the SSE2 check fails on your core2 but when you force it the SSE2 kernel
runs fine. Is that correct?

I'll restore all the compiler directives, I had removed them LOL, when I was hacking and slashing
the code an focussed only on the top tier.

I'll follow up on your findings, thanks a lot.

Edit: Another dramatic turn of events, this time a positive one!

Reenabling the AESNI_NI defines (and the companion OPTIMIZE_SSE2 has unlocked a ton
more performance thaty had been hidden by chainsaw approach.

X11 is up to 865 from 720 on my i7-4790K, but things aren't perfect, I see some rejects.
Some of the exposed code may not be perfect and may require a scalple to cut out the
cancer.

I've got a lot of work to do but I'm back on track.

BTW thanks for the excelllent report, very clear, complete, and precise. I followed it like  a script.

---------------------------------------------------------

Edit:

It looks like the dramatic sped increase was due to an error on my part. It seems the #define AES_NI
I put in miner.h isn't being seen. I had to #define it in every file that uses it. Clumsy but it works.

I'm building a debug tarbar so you can do some better testing. It will require you to make some small
code changes. I will send a PM with a link to the file.

Here's how it works:

Default is to enable and respect all AES_NI checks.

Edit: changed default configuration for your convenience.

Will disable AES_NI because we already know your CPU can't handle it

To force disable AES_NI you have to do two things before compiling:
    - in cpu-miner.c:1945 hard code cpu_aesni to false
 - remove #define AESNI from all algos, grep -r AES_NI to find them all, sorry

To force disable SSE2
  - in addition to the steps above hard code cpu_sse2 to false

These changes will affect kernel selection only, the start up capability check is still performed but not enforced.
This should solve the compile problem you had and allow you to do more testing.
The ugly workarounds are for the debug load only. I will investigate a more user firendly implentation
before release. Any suggestions welcome, including why the algos don't pick up the #define in miner.h

The goals of the further testing:

1. confirm the capability of your core2 CPU

2. determine if cpuminer-opt can correctly identify your CPU's capability level and select the appropriate kernel

3. compare sse2 vs x86_64 performance.

The first two are pretty obvious The third will allow me to extrapolate an estimate of the hash deficit of SSE2 vs AES_NI
and split it into the HW component and software component. How much of the loss is due purely due to the lack of
AES_NI and how much is due to other CPU optimizations in the latest generation.

Thanks for the great work.


The cpu check fails on this computer and I suspect cpuid has been disabled in the BIOS.  I will check when I get a chance.

I downloaded the code you sent.  I had to do the following mods to get it to compile.

1. Commented out #define AES_NI and Added #ifdef AES_NI to effectively comment out code in algo/cryptonight/cryptonight-aesni.c.
2. Added #undef AES_NI in algo/aesni/echo512/hash.c
since miner.h is not included.
3. Added #ifdef AES_NI_ON a lot of places in algo/aesni/groestl/groestl-intr-aes.h

After these changes, I could leave both
#define AES_NI
#define AES_NI_ON 1
in miner.h and it compiled/runs fine.

Hashrates:
With cpu_sse2 = false I get
[2016-01-24 13:05:53] CPU #0: 25.50 kH/s
[2016-01-24 13:05:53] CPU #1: 25.50 kH/s
Set to true:
[2016-01-24 13:06:36] CPU #0: 43.38 kH/s
[2016-01-24 13:06:36] CPU #1: 43.38 kH/s

EDIT: You might want to move the calls to has_aes_ni() and has_sse2() to the top of main()  and make the boolean flags
global.  So that these functions are not called every pass of the main loop.  No need to call these more than once  Wink



Mining Hobbyist
joblo
Legendary
*
Offline Offline

Activity: 1008


View Profile
January 24, 2016, 03:57:51 PM
 #180


The cpu check fails on this computer and I suspect cpuid has been disabled in the BIOS.  I will check when I get a chance.

I downloaded the code you sent.  I had to do the following mods to get it to compile.

1. Commented out #define AES_NI and Added #ifdef AES_NI to effectively comment out code in algo/cryptonight/cryptonight-aesni.c.
2. Added #undef AES_NI in algo/aesni/echo512/hash.c
since miner.h is not included.
3. Added #ifdef AES_NI_ON a lot of places in algo/aesni/groestl/groestl-intr-aes.h

After these changes, I could leave both
#define AES_NI
#define AES_NI_ON 1
in miner.h and it compiled/runs fine.

Hashrates:
With cpu_sse2 = false I get
[2016-01-24 13:05:53] CPU #0: 25.50 kH/s
[2016-01-24 13:05:53] CPU #1: 25.50 kH/s
Set to true:
[2016-01-24 13:06:36] CPU #0: 43.38 kH/s
[2016-01-24 13:06:36] CPU #1: 43.38 kH/s

EDIT: You might want to move the calls to has_aes_ni() and has_sse2() to the top of main()  and make the boolean flags
global.  So that these functions are not called every pass of the main loop.  No need to call these more than once  Wink

I've di there was already some cpuid checks in the code that will all have to be consolidated/ It's not a priority
because the check is not expensive and is only really done at startup.

Your x86_64/SSE2 performance ratio is 25.0 / 43.38 = .58
my 4790K  is 266 / 472 = ,56

That's pretty close. If effect your CPU SSE2's performance is just as good as mine. My only advantage
is the addition of AES_NI and possibly higher power efficiency. There' slife in those old CPU yet.

I'll take some time to digest the rest of your report, I just woke up.

Principal developer of cpuminer-opt, the optimized multi-algo CPU miner.
BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
https://bitcointalk.org/index.php?topic=1326803.0
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 59 ... 165 »
  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!