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

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.

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

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?

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



taken from the ocminer cpuminer

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.

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 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.

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

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.

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

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.

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

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.

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.

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 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.

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.

this thread is for a miner, not a pool, so if you are asking about a pool and an algo you have to be more specific for someone to try and help answer your question.