[LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner

[joblo]

I have been looking at integrating the zcoin version of lyra2. I have ported the AVX2 optimizations but zcoin
is no faster. The algo is I/O bound (memory hard)  so speeding up computation doesn't help when the CPU Is waiting
for data.

There are also some issues with rejects related to teh pool stability issues. These rejects are not seen with the ocminer
implementation. I will investigate further.

I'm still looking at ways to reduce memory accesses but am not optimistic.

Some notes about zcoin. It uses a monstrous implementation of pure Lyra2. It's memory requirements grow and hashrate slow
as block height increases.

I am not aware of an official name for the algo. ocminer has reused lyra2v2 but that causes confusion with the real lyra2v2 (Lyra2REv2).

Using the coin name has been a frequent choice for new algos and I'm going with zcoin in cpuminer-opt.
Some suggestions are lyra2Z or Lyra2-Zcoin.

[Nik4691]

Just a note about this - I was reading about this issue a number of days ago and someone mentioned that AES may not actually be enabled even though it says that it is? I just can't imagine that dual 6-core L5640 processors would perform like this without something being wrong. I tried doling things out via numactl and that didn't have any impact to speak of.

I don't use this miner for cryptonight, but i did a test and it seems it don't uses AES-NI.
Claymore's miner gives me about 300 h/s and Wolf0's about 280 h/s. This one only 170 h/s (total).
This, with an 8core AMD FX at 4GHz.
Considering that my old PHENOM without AES-NI gave me about the same h/s per core, i imagine that this is the case.

Compiled your own? AMD CPU have been a challenge to get properly compiled. I can't do it as I don't have any AMDs.
AMD users have reported problems compiling with "-march=native". A couple of AMD users have posted tips in this
thread that may help. What's the L3 cache size? (see my previous post).

I used the binaries in windows 7 x64 cpuminer-opt-3.4.7-windows.
I mine VERIUM now (-a scrypt:1048576) and the results seems legit (comparable with others with Intel or AMD processors with AES-NI).
I did some benchmarks with other algos too and it seems that AES-NI are working, but not on cryptonight.

[joblo]

Just a note about this - I was reading about this issue a number of days ago and someone mentioned that AES may not actually be enabled even though it says that it is? I just can't imagine that dual 6-core L5640 processors would perform like this without something being wrong. I tried doling things out via numactl and that didn't have any impact to speak of.

I don't use this miner for cryptonight, but i did a test and it seems it don't uses AES-NI.
Claymore's miner gives me about 300 h/s and Wolf0's about 280 h/s. This one only 170 h/s (total).
This, with an 8core AMD FX at 4GHz.
Considering that my old PHENOM without AES-NI gave me about the same h/s per core, i imagine that this is the case.

Compiled your own? AMD CPU have been a challenge to get properly compiled. I can't do it as I don't have any AMDs.
AMD users have reported problems compiling with "-march=native". A couple of AMD users have posted tips in this
thread that may help. What's the L3 cache size? (see my previous post).

I used the binaries in windows 7 x64 cpuminer-opt-3.4.7-windows.
I mine VERIUM now (-a scrypt:1048576) and the results seems legit (comparable with others with Intel or AMD processors with AES-NI).
I did some benchmarks with other algos too and it seems that AES-NI are working, but not on cryptonight.

The btver1 build does not include AES. Try the Intel builds or try compiling using the tips it README.md.

[Nik4691]

Just a note about this - I was reading about this issue a number of days ago and someone mentioned that AES may not actually be enabled even though it says that it is? I just can't imagine that dual 6-core L5640 processors would perform like this without something being wrong. I tried doling things out via numactl and that didn't have any impact to speak of.

I don't use this miner for cryptonight, but i did a test and it seems it don't uses AES-NI.
Claymore's miner gives me about 300 h/s and Wolf0's about 280 h/s. This one only 170 h/s (total).
This, with an 8core AMD FX at 4GHz.
Considering that my old PHENOM without AES-NI gave me about the same h/s per core, i imagine that this is the case.

Compiled your own? AMD CPU have been a challenge to get properly compiled. I can't do it as I don't have any AMDs.
AMD users have reported problems compiling with "-march=native". A couple of AMD users have posted tips in this
thread that may help. What's the L3 cache size? (see my previous post).

I used the binaries in windows 7 x64 cpuminer-opt-3.4.7-windows.
I mine VERIUM now (-a scrypt:1048576) and the results seems legit (comparable with others with Intel or AMD processors with AES-NI).
I did some benchmarks with other algos too and it seems that AES-NI are working, but not on cryptonight.

The btver1 build does not include AES. Try the Intel builds or try compiling using the tips it README.md.

A, yes, that did the trick. Using the cpuminer-corei7-avx the hashrate is up there with Claymore's and Wolf0's miners (280 h/s).
But using -a scrypt:1048576 the hashrate is the same as with cpuminer-btver1 core.

[shakeandbake]

I have dual L5640 Wesmere processors (dual 6 core = 24 thread) and I get horrible performance no matter which exe I use... or even running via Linux, 100 h/s is about all I get. Is there a bug or something I'm missing?

Try it with 6 threads per cpu, that should better fit the L3 cache and make sure the miner recongnizes AES.
Otherwise I need a lot more info.

Are there any debug logs or anything like that I can retrieve? any parameters I can add, when launching, to get additional debug info ?

You mean like a console session? Why haven't you posted that yet? There's a lot of good info displayed when the miner starts up,
it should be obvious to post that as a minimum when asking a question.

OK got some info - also, the result is no different in v3.4.7

edit: Also a note about config... these results were compiled with march=westmere -O3 ; trying other variations doesn't do much +/- a few percentage points (march=native, -O2,1,fast etc..)

6-thread

      **********  cpuminer-opt 3.4.8-dev  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz
CPU features: SSE2 AES
SW built on Oct 13 2016 with GCC 5.4.0
SW features: SSE2 AES
Algo features: SSE2 AES
Start mining with SSE2 AES

[2016-10-13 03:06:50] Starting Stratum on stratum+tcp://xmr.pool.minergate.com:45560
[2016-10-13 03:06:50] 6 miner threads started, using 'cryptonight' algorithm.
[2016-10-13 03:06:50] Stratum difficulty set to 4252
[2016-10-13 03:06:53] CPU #4: 66 H, 31.26 H/s
[2016-10-13 03:06:53] CPU #5: 66 H, 31.22 H/s
[2016-10-13 03:06:53] CPU #2: 66 H, 30.11 H/s
[2016-10-13 03:06:53] CPU #0: 66 H, 30.00 H/s
[2016-10-13 03:06:53] CPU #3: 66 H, 29.95 H/s
[2016-10-13 03:06:53] CPU #1: 66 H, 28.31 H/s
[2016-10-13 03:07:25] CPU #5: 1058 H, 32.97 H/s
[2016-10-13 03:07:25] CPU #1: 1004 H, 31.48 H/s
[2016-10-13 03:07:25] CPU #2: 1016 H, 31.72 H/s
[2016-10-13 03:07:25] CPU #0: 1014 H, 31.66 H/s
[2016-10-13 03:07:25] CPU #3: 1012 H, 31.60 H/s
[2016-10-13 03:07:25] CPU #4: 1060 H, 33.00 H/s
[2016-10-13 03:07:44] CPU #5: 645 H, 33.04 H/s
[2016-10-13 03:07:45] Accepted 1/1 (100%), 5751 H, 192.50 H/s, 51C

8 thread:

   **********  cpuminer-opt 3.4.8-dev  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Xeon(R) CPU           L5640  @ 2.27GHz
CPU features: SSE2 AES
SW built on Oct 13 2016 with GCC 5.4.0
SW features: SSE2 AES
Algo features: SSE2 AES
Start mining with SSE2 AES

[2016-10-13 03:08:29] Starting Stratum on stratum+tcp://xmr.pool.minergate.com:45560
[2016-10-13 03:08:29] 8 miner threads started, using 'cryptonight' algorithm.
[2016-10-13 03:08:30] Stratum difficulty set to 4252
[2016-10-13 03:08:33] CPU #6: 40 H, 15.84 H/s
[2016-10-13 03:08:33] Accepted 1/1 (100%), 40 H, 15.84 H/s, 52C
[2016-10-13 03:08:34] CPU #4: 66 H, 18.90 H/s
[2016-10-13 03:08:34] CPU #5: 66 H, 17.43 H/s
[2016-10-13 03:08:34] CPU #3: 66 H, 16.84 H/s
[2016-10-13 03:08:34] CPU #2: 66 H, 16.24 H/s
[2016-10-13 03:08:34] CPU #7: 66 H, 15.81 H/s
[2016-10-13 03:08:35] CPU #0: 66 H, 15.52 H/s
[2016-10-13 03:08:35] CPU #1: 66 H, 14.82 H/s
[2016-10-13 03:08:54] CPU #7: 312 H, 16.13 H/s
[2016-10-13 03:08:54] Accepted 2/2 (100%), 748 H, 131.71 H/s, 52C




Just a note about this - I was reading about this issue a number of days ago and someone mentioned that AES may not actually be enabled even though it says that it is? I just can't imagine that dual 6-core L5640 processors would perform like this without something being wrong. I tried doling things out via numactl and that didn't have any impact to speak of.

Good data. It appears only 1 CPU is mining (there are 2 right?), it doesn't look like the miner supports multiple CPUs.
Other than that everyting looks fine, you get higher hashrate with 6 cores vs 8.

For cryptonight the optimum thread count is (L3 cache size in MB / 2).

Edit: What's the default thread count, does it represent both CPUs?

It's defaulting to 12 threads so that tells me that it does take multiple CPU's

also of note, I've got this running on numerous dual 16-core opteron setups and it takes those like a champ... 900H/s

[joblo]

A, yes, that did the trick. Using the cpuminer-corei7-avx the hashrate is up there with Claymore's and Wolf0's miners (280 h/s).
But using -a scrypt:1048576 the hashrate is the same as with cpuminer-btver1 core.

Scrypt has no AES optimizations, you can see that in the Algo features.

[joblo]

It's defaulting to 12 threads so that tells me that it does take multiple CPU's

also of note, I've got this running on numerous dual 16-core opteron setups and it takes those like a champ... 900H/s

Each CPU can run 12 threads (6 cores hypertthreaded) so it appears you are only using one CPU. With both CPUs it should default
to 24.

[shakeandbake]

It's defaulting to 12 threads so that tells me that it does take multiple CPU's

also of note, I've got this running on numerous dual 16-core opteron setups and it takes those like a champ... 900H/s

Each CPU can run 12 threads (6 cores hypertthreaded) so it appears you are only using one CPU. With both CPUs it should default
to 24.

interesting.... am I missing something when I compile i wonder? I figured it would automatically pick up the other CPU?

[joblo]

It's defaulting to 12 threads so that tells me that it does take multiple CPU's

also of note, I've got this running on numerous dual 16-core opteron setups and it takes those like a champ... 900H/s

Each CPU can run 12 threads (6 cores hypertthreaded) so it appears you are only using one CPU. With both CPUs it should default
to 24.

interesting.... am I missing something when I compile i wonder? I figured it would automatically pick up the other CPU?

I have no experience with multi CPU configs. You should check your BIOS and OS to make sure everything is setup correctly and make
sure both CPUs are being used. Check the system monitor or whatever tools you have. It should all be transparent to the miner SW.

[felixbrucker]

I have been looking at integrating the zcoin version of lyra2. I have ported the AVX2 optimizations but zcoin
is no faster. The algo is I/O bound (memory hard)  so speeding up computation doesn't help when the CPU Is waiting
for data.

There are also some issues with rejects related to teh pool stability issues. These rejects are not seen with the ocminer
implementation. I will investigate further.

I'm still looking at ways to reduce memory accesses but am not optimistic.

Some notes about zcoin. It uses a monstrous implementation of pure Lyra2. It's memory requirements grow and hashrate slow
as block height increases.

I am not aware of an official name for the algo. ocminer has reused lyra2v2 but that causes confusion with the real lyra2v2 (Lyra2REv2).

Using the coin name has been a frequent choice for new algos and I'm going with zcoin in cpuminer-opt.
Some suggestions are lyra2Z or Lyra2-Zcoin.

id love to see zcoin supported in cpuminer-opt

as for naming, you might also use the xzc short tag in combination with lyra2

[joblo]

I have been looking at integrating the zcoin version of lyra2. I have ported the AVX2 optimizations but zcoin
is no faster. The algo is I/O bound (memory hard)  so speeding up computation doesn't help when the CPU Is waiting
for data.

There are also some issues with rejects related to teh pool stability issues. These rejects are not seen with the ocminer
implementation. I will investigate further.

I'm still looking at ways to reduce memory accesses but am not optimistic.

Some notes about zcoin. It uses a monstrous implementation of pure Lyra2. It's memory requirements grow and hashrate slow
as block height increases.

I am not aware of an official name for the algo. ocminer has reused lyra2v2 but that causes confusion with the real lyra2v2 (Lyra2REv2).

Using the coin name has been a frequent choice for new algos and I'm going with zcoin in cpuminer-opt.
Some suggestions are lyra2Z or Lyra2-Zcoin.

id love to see zcoin supported in cpuminer-opt

as for naming, you might also use the xzc short tag in combination with lyra2

I think I'm making progress with the rejects. It's slow to test as the frequency or rcvline failures has dropped. There are occasionally
rejects immediately after a new block is issued but that appears to be a race condition between the stratum thread and the miner
threads switching to the new block.

On the name side I'm leaning toward "Lyra2Z" as the formal name "lyra2z' as the command arg and "zcoin" as an alias.
I don't like using coins names or symbols as the primary algo name.

[felixbrucker]

I think I'm making progress with the rejects. It's slow to test as the frequency or rcvline failures has dropped. There are occasionally
rejects immediately after a new block is issued but that appears to be a race condition between the stratum thread and the miner
threads switching to the new block.

On the name side I'm leaning toward "Lyra2Z" as the formal name "lyra2z' as the command arg and "zcoin" as an alias.
I don't like using coins names or symbols as the primary algo name.

are the rejects you see after a block switch like this?



taken from the ocminer cpuminer

[joblo]

I think I'm making progress with the rejects. It's slow to test as the frequency or rcvline failures has dropped. There are occasionally
rejects immediately after a new block is issued but that appears to be a race condition between the stratum thread and the miner
threads switching to the new block.

On the name side I'm leaning toward "Lyra2Z" as the formal name "lyra2z' as the command arg and "zcoin" as an alias.
I don't like using coins names or symbols as the primary algo name.

are the rejects you see after a block switch like this?



taken from the ocminer cpuminer

Yes, I still get those. When a new block is issued all the miner threads must abort their current work and start solving the new block.
If they find a solution on the old block first it seems to be rejected. I haven't noticed this before with any other algo and seeing it
also occurs with ocminer I'm assuming it's not a miner issue.

I also had a problem recovering from a recv_line failure, where every submit would be rejected
until a new block was issued. This morning's botnet provided a good test and it passed on the machines with the fix,
failed on those without. This problem may have affected all algos because recv line failures are extremely rare
and likely wouldn't have been seen.

I still haven't made any progress with optimizing. Although the Lyra2 AVX2 optimizations produced big improvements
in Lyra2RE and Lyra2REv2 there was no measurable difference with zcoin which is ALL Lyra2 and ONLY Lyra2. The only
conclusion is that zcoin is already I/O bound so the only effect of improving computation is the CPU spends more time
waiting for data. There might be an improvement on architectures with faster memory but only if the memory can keep
up with the CPU. At this point I don't know how oversaturated it is, but I do know it will only get worse as the matrix size
increases with every block. I don't anticipate memory technology to increase performance faster than zcoin's demands
so optimizing for AVX2 may be entirely futile.

Edit: In the other thread you mentioned optiminer's version, I can't find it. Did you mean ocminer?

[felixbrucker]

i dont have AVX2 capable cpus so i cant comment on those, but for the rest of my cpus ranging from SSE2 only Celerons to Xeon E3 i see similar results.

- Celeron G1820's produce 5-6H/s with a single core used (they are used in GPU mining as well)
- i3-3120m produces 20H/s
- i5-3330 produces 15-20H/s (4 cores used, also running my desktop and stuff)
- E3-1265Lv2 produces 25-40H/s (some great variance here, not sure why) using 4 cores
- FX-8320e gives abyssal 7-8H/s (0.6H/s per core if all cores used)
- A10-6800K gives abyssal 6H/s
- A6-6400K gives abyssal 4H/s

amd cpus do not seem to be very good in this algo (used native compiles) and celerons deliver a greater performance compared to other algos

optminers version (with some AVX2 optimizations i suppose) is here: https://github.com/Optiminer/cpuminer-xzc

[joblo]

i dont have AVX2 capable cpus so i cant comment on those, but for the rest of my cpus ranging from SSE2 only Celerons to Xeon E3 i see similar results.

- Celeron G1820's produce 5-6H/s with a single core used (they are used in GPU mining as well)
- i3-3120m produces 20H/s
- i5-3330 produces 15-20H/s (4 cores used, also running my desktop and stuff)
- E3-1265Lv2 produces 25-40H/s (some great variance here, not sure why) using 4 cores
- FX-8320e gives abyssal 7-8H/s (0.6H/s per core if all cores used)
- A10-6800K gives abyssal 6H/s
- A6-6400K gives abyssal 4H/s

amd cpus do not seem to be very good in this algo (used native compiles) and celerons deliver a greater performance compared to other algos

optminers version (with some AVX2 optimizations i suppose) is here: https://github.com/Optiminer/cpuminer-xzc

Thanks, optiminer is tweaking some of my AVX2 code. He did excellent work with hodl so I'll have to keep an eye on it.

[shakeandbake]

It's defaulting to 12 threads so that tells me that it does take multiple CPU's

also of note, I've got this running on numerous dual 16-core opteron setups and it takes those like a champ... 900H/s

Each CPU can run 12 threads (6 cores hypertthreaded) so it appears you are only using one CPU. With both CPUs it should default
to 24.

interesting.... am I missing something when I compile i wonder? I figured it would automatically pick up the other CPU?

I have no experience with multi CPU configs. You should check your BIOS and OS to make sure everything is setup correctly and make
sure both CPUs are being used. Check the system monitor or whatever tools you have. It should all be transparent to the miner SW.

Adjusting ACPI options in the BIOS did it - running around 350H/s (better, but still a good deal under what I was hoping for... 400+ at least.

[maxfunky]

optminers version (with some AVX2 optimizations i suppose) is here: https://github.com/Optiminer/cpuminer-xzc

Code for AVX2 can be enabled by compiling with "-mavx2": $ CFLAGS="-O2 -mavx2" ./configure && make clean && make
Memory prefetching can be enabled by compiling with "-mavx2": $ CFLAGS="-O2 -DROW_PREFETCH" ./configure && make clean && make

Should I compile with both? if so how exactly? (kind of a noob on nix lol)

[maxfunky]

Code:

collect2: error: ld returned 1 exit status
Makefile:869: recipe for target 'cpuminer' failed
make[2]: *** [cpuminer] Error 1
make[2]: Leaving directory '/home/ubuntu/cpuminer-xzc'
Makefile:2349: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ubuntu/cpuminer-xzc'
Makefile:559: recipe for target 'all' failed
make: *** [all] Error 2

 

[joblo]

Code:

collect2: error: ld returned 1 exit status
Makefile:869: recipe for target 'cpuminer' failed
make[2]: *** [cpuminer] Error 1
make[2]: Leaving directory '/home/ubuntu/cpuminer-xzc'
Makefile:2349: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ubuntu/cpuminer-xzc'
Makefile:559: recipe for target 'all' failed
make: *** [all] Error 2

 

That's not cpuminer-opt you're compiling, and cpuminer-opt doesn't support zcoin yet.
Try the zcoin thread and include more info.

[kenshirothefist]

joblo, you're probably already aware of the Tromp's Equihash solvers, which were released under open-source. Are you considering implementing them into your cpuminer-opt, thus adding support for equihash algortihm (for z.cash)?