Topic: [ANN] cpuminer-opt v3.14.2, open source optimized multi-algo CPU miner - page 19. (Read 10284 times)

First time when I ran the miner with two threads, a dialog box of error appeared, atm I can't remember what the error was.
After that the dialog box doesn't appear, just the miner exits silently. I'm sure the miner is crashing when I use more than 1 thread.
I think there is something wrong in coding.

- try default thread count  -  doesn't work with more than 1 thread
Edit: When I tried this option, I removed the flag --threads=

- try stratum+tcps port, if available  -  doesn't work with more than 1 thread

- try different algo same pool  -  it works with different algo same pool

- try different pool same algo  -  doesn't work with more than 1 thread

The stratum problem at rplant pool is weird. There is no reason the miner would fail based on thread count.
There is also no reason it would exit silently unless it crashed. I'm not familiar with Windows crash debugging
so I don't know how to determine if it crashed or how it crashed.

I can only suggest trying different things to see if there's a pattern.

- try default thread count
- try stratum+tcps port, if available
- try different algo same pool
- try different pool same algo

I'll try to find more info about the RPC error solo mining.

This miner only works if I use 1 (one) thread to do pool mining, if I use more than one thread then the miner stops just after connecting to the pool.



And this is the error that I get when do solo mining.

I assume not if rplant doesn't work, but you could give it a try and post your results. If it doesn't work I can take
a look at the debug output to see if there's something obvious.

Hey JayDDee,

Does solo mining work in Minotaur release?  I keep getting rpc errors from miner.  I know rplant said solo is broken in his version, but he’s not going to fix it because he wants people using his pool.

It isn't nonsense at all, actually a very good question.

Vectorization can be implemented 2 ways, linear and parallel.

Linear can be used when a single data stream has repeated instructions on contiguous data.

Parallel is multiple data streams, similar to a GPU but with some strict limitations. First the data
streams must be interleaved. There must not be any data dependencies that would cause code
divergence between lanes. All lanes must execute the exact same code in the same order.
Also the interleaved data must be contiguous to get any performance benefit. When possible,
parallel is easier to implement because it's basically SIMD versions of the same scalar instructions.

Some code segments can do linear only, some parallel only, some both and some neither.

Blake2b can do parallel but only represents a small portion of the entire algo. The rest of Yespower
has data dependencies that prevent parallel vectorization but has some segments that can benefit
from linear vectorization.

One other barrier is memory throughput. If an algo is already I/O bound (mempory hard) linear vectors
still have to access the same amount of memory but with fewer instructions. That won't help (example lyra2z330).
Parallel vectorization increases memory usage by 4x or 8x depending on the number of lanes making
the bottleneck worse.

It's an unfortunate reality that CPU vectorization is a losing battle in crypto mining. Any vectorization
a CPU can do, a GPU can do better. Algos that favour CPUs typically have limited vectorization potential.
Many new algos are specifically designed to exploit the advantages of CPUs over GPUs and ASICs.

This may be nonsense but please bear with me:

Blake2b seems to be optimized for AVX2. Power2b just supports SSE2.
Assuming that power2b uses blake2b internally, and the latter is/may be optimized with AVX2, my question is couldn't power2b use blake2b's already existing AVX2 optimizations, and not fall back as a whole to SSE2?

What CPU coin are you mining now?

Both are fixed in v3.12.8.2.

https://github.com/JayDDee/cpuminer-opt/releases

Thanks.
Please also add to your list that phi is crashing in AVX2 immediately upon start.

X12 for  AVX2 is broken again, or should I say, still. I thought I fixed it in v3.11.3 but now I can't find a working version for AVX2.

I'm investigating.

Yes, the number in parentheses is calculated by counting hashes. This calculation is also used in the new block report to calculate TTF,
thread hash meter, and benchmark total. This is called the "reference hash rate". Anything related to actual shares
is called the "effective hash rate".

You can find details in the Wiki...

https://github.com/JayDDee/cpuminer-opt/wiki/Console-Logs

As far as interpreting the values, the reference hashrate is simply the sum of the last sample from each thread.
It can be volatile if there is other activity on the CPU. Some miners average it but I prefer discrete samples.

Newer miner versions should not have a slower ref hash rate. If anything they should be faster if not equal.
If you find otherwise please post the details so I can investigate.

Hi.

I was just wondering: in the current periodic share/speed report, is there the raw hash rate, the one the machine can actually compute? Not sure if the value in parenthesis is this number as it seems quite smaller than the value I got from older versions. Does --benchmark still output this value reliably?
Thanks.

Thanks for the warning. I know rplant8, he has contributed some improvements to cpuminer-opt. He doesn't publish
his source code, he should, but I have no reason to believe he includes any malware.

Hello,
This pool is distribute your miner without source code.
Maybe virus.

https://github.com/rplant8/cpuminer-opt-rplant/releases

Maybe you want take some action.

I'm soliciting user input for improving the API in cpuminer-opt in light of the enhanced statistics reporting.
Suggestions can be discussed here or  at:

https://github.com/JayDDee/cpuminer-opt/issues/256

This was an interesting test but I don't see the point. It's conclusion was Clang/AOCC didn't improve performance
when compared against GCC.

The testing was also incomplete. There was no live test to confirm shares are valid and no control test of
Clang without AOCC.

Clang, with or without AOCC, is not recommended and not supported for cpuminer-opt.

We wrote an article on how to install AOCC (AMD Optimizing C / C ++ Compiler) and tested CPUminer it on a ryzen 2600 CPU.

Read full article: http://cpu-mining.info/post.php?post=2

https://i.imgur.com/7gQXwft.png

AOCC Docs - https://developer.amd.com/wp-content/resources/AOCC-2.1-Install-Guide.pdf

Install depends


download aocc-compiler-2.1.0_1_amd64.deb from https://developer.amd.com/amd-aocc/

install AOCC in Ubuntu


check the installed AOCC compiler


Tested cpuminer-opt on yespower algos.
you need to remove all algorithms from the miner, except yespower

if error in coinfigure - use olds version cpuminer-opt


configure with AOCC



benchmark


You can check this compiler on your favorite algorithm.

Centos 6 isn't supported, it's just too old. That error is because libcurl is too old. If you fix that you
get an error because gmp is too old ...

It's a lot simpler to upgrade the entire OS.

Any chance you could help with the following error during compilation?
This is under centos 6 and gcc 8.3.1

util.c: In function ‘send_line’:
util.c:1136:15: error: ‘sock’ undeclared (first use in this function); did you mean ‘work’?
      n = send(sock, s + sent, len, 0);
               ^~~~
               work
util.c:1136:15: note: each undeclared identifier is reported only once for each function it appears in