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

[joblo]

I noticed that the blake2b exists in the sources, but disabled in algo-gate-api
any reason for that?

I never got it to work. I should not have mentioned it in the change log.

[ybelevi]

hello
i've problem to install on debian.please help me

/usr/bin/ld: warning: libssl.so.1.0.2, needed by /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcurl.so, may conflict with libssl.so.1.1
/usr/bin/ld: warning: libcrypto.so.1.0.2, needed by /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcurl.so, may conflict with libcrypto.so.1.1
make[2]: Leaving directory '/root/cpuminer-opt'
make[1]: Leaving directory '/root/cpuminer-opt'

[joblo]

hello
i've problem to install on debian.please help me

/usr/bin/ld: warning: libssl.so.1.0.2, needed by /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcurl.so, may conflict with libssl.so.1.1
/usr/bin/ld: warning: libcrypto.so.1.0.2, needed by /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcurl.so, may conflict with libcrypto.so.1.1
make[2]: Leaving directory '/root/cpuminer-opt'
make[1]: Leaving directory '/root/cpuminer-opt'

This looks like only a warning, if the executable was built give it a try.

I presume you installed a newer version of openssl-dev for SHA support. It was initially added to 1.1 but appears to have been
ported back to some 1.0 versions.

If 1.1 doesn't work try with the latest 1.0.2. It has been reported to have SHA on Ubuntu 16.04 so it should also work on Debian.
You can confirm SHA support a number of ways. If you're CPU is a Ryzen the default compile arch should include SHA,
or you can add -msha to CFLAGS. You can confirm when the miner is started that SHA is listed in the SW features.

[ecth]

Nice, finally managed running it on my machine. Works best with Ubuntu on Windows. Compiled v3.7.0 for my Sandy Bridge-E 3930K (-march=corei7-avx).
On all cores (6 + HT = ~12), with some OC to 160W makes about 3.7-3.8 GHz on all cores/threads. Every thread has about 3.2-3.6 H/s. All together are at 40-42 H/s

On Windows I had problems running more than 3 threads. After upgrading to 1709 (Windows chose me. Update was shown instantly after release, lol ) Windows Defender killed the process and deleted the precompiled binary. On Ubuntu (from the Windows App Store) it runs perfectly smooth

[felixbrucker]

Maybe i missed it but i just stumbled upon this https://github.com/xmrig/xmrig

as it's based off cpuminer-multi, maybe there are some optimizations which can be used in cpuminer-opt as well, if there are any

[joblo]

Maybe i missed it but i just stumbled upon this https://github.com/xmrig/xmrig

as it's based off cpuminer-multi, maybe there are some optimizations which can be used in cpuminer-opt as well, if there are any

It uses double buffering to hash two nonces with one thread. This isn't parallel processing because the double buffering is
done serially. This could theoretically reduce CPU stalls while waiting for data from memory.

I haven't tried it yet so I don't know how performance compares.

[nizzuu]

I haven't tried it yet so I don't know how performance compares.

I can tell. With software AES, xmrig gives no performance improvement as compared to cpuminer-opt. With hardware AES, it gives ~15-20% boost on Kaby Lake pentiums, and around 40-45% on i5/i7 from same gen (Kaby Lake), as compared to cpuminer-opt. Thread (-t) number is the same.

Partly it's because of msvc compiler (your binaries are build with gcc), around 3-4% are there. I've personally compiled xmrig with three compilers - latest gcc, msvc 2017 and Intel compiler (trial parallel studio xe 2017 update 4) with different options. Intel and gcc give equal performance while msvc is slightly faster. So, for Windows and cryptonote part of cpuminer-opt it's probably no reason to purchase (or try) Intel compiler.

Wanted to compile cpuminer-opt using these three and test for performance (got different CPU's - G4560/G4600/i5-4570/G1840/G620/i3-4000M/E5-2609v3/E5-2630v4) , but the project structure is a bit complex for me to rework it for direct VS2017 usage. Will give it a try later if joblo won't release instruction (or rework the project)

[joblo]

I haven't tried it yet so I don't know how performance compares.

I can tell. With software AES, xmrig gives no performance improvement as compared to cpuminer-opt. With hardware AES, it gives ~15-20% boost on Kaby Lake pentiums, and around 40-45% on i5/i7 from same gen (Kaby Lake), as compared to cpuminer-opt. Thread (-t) number is the same.

Partly it's because of msvc compiler (your binaries are build with gcc), around 3-4% are there. I've personally compiled xmrig with three compilers - latest gcc, msvc 2017 and Intel compiler (trial parallel studio xe 2017 update 4) with different options. Intel and gcc give equal performance while msvc is slightly faster. So, for Windows and cryptonote part of cpuminer-opt it's probably no reason to purchase (or try) Intel compiler.

Wanted to compile cpuminer-opt using these three and test for performance (got different CPU's - G4560/G4600/i5-4570/G1840/G620/i3-4000M/E5-2609v3/E5-2630v4) , but the project structure is a bit complex for me to rework it for direct VS2017 usage. Will give it a try later if joblo won't release instruction (or rework the project)

The Windows binaries I provide are definitely slower than compiled on Linux. Both use gcc 4.8 so I do't think it's the compiler. My guess is
the libraries in my mingw environment are old. I've tried a couple of newer versions of mingw (mostly for SHA) but so far have not been successful
getting cpuminer-opt to compile.

I tried getting MSVC to work early on but gave up. At this point the project files would have to rebuilt from scratch to have any hope of
getting it to work.

[felixbrucker]

and around 40-45% on i5/i7 from same gen (Kaby Lake)

that is impressive, thanks for sharing

[nizzuu]

Both use gcc 4.8 so I do't think it's the compiler.

I tried getting MSVC to work early on but gave up. At this point the project files would have to rebuilt from scratch to have any hope of
getting it to work.

Yep, the compiler side has a little affect. My main machine is i5-7600 non-K with 32Gb DDR4-3000MHz XMP @ 2 channels, so the compiler difference was ~230H/s vs ~239H/s. It's 3-4%, that's all. But the diff 129H/s with cpuminer-opt vs 239H/s xmrig - that's where real diff lives. Same result with cpuminer-multi and other forks, while xmrstack gives 225H/s with provided stock binaries (I hate the config way there huh).

Will start with component upgrades, thanks for pointing that out.

[4ward]

I haven't tried it yet so I don't know how performance compares.

I can tell. With software AES, xmrig gives no performance improvement as compared to cpuminer-opt. With hardware AES, it gives ~15-20% boost on Kaby Lake pentiums, and around 40-45% on i5/i7 from same gen (Kaby Lake), as compared to cpuminer-opt. Thread (-t) number is the same.

Partly it's because of msvc compiler (your binaries are build with gcc), around 3-4% are there. I've personally compiled xmrig with three compilers - latest gcc, msvc 2017 and Intel compiler (trial parallel studio xe 2017 update 4) with different options. Intel and gcc give equal performance while msvc is slightly faster. So, for Windows and cryptonote part of cpuminer-opt it's probably no reason to purchase (or try) Intel compiler.

Wanted to compile cpuminer-opt using these three and test for performance (got different CPU's - G4560/G4600/i5-4570/G1840/G620/i3-4000M/E5-2609v3/E5-2630v4) , but the project structure is a bit complex for me to rework it for direct VS2017 usage. Will give it a try later if joblo won't release instruction (or rework the project)

The Windows binaries I provide are definitely slower than compiled on Linux. Both use gcc 4.8 so I do't think it's the compiler. My guess is
the libraries in my mingw environment are old. I've tried a couple of newer versions of mingw (mostly for SHA) but so far have not been successful
getting cpuminer-opt to compile.

I tried getting MSVC to work early on but gave up. At this point the project files would have to rebuilt from scratch to have any hope of
getting it to work.

Have you tries cross-compiling in Linux to windows? That could solve the old mingw version issues, let you use a newer gcc and perhaps allow to add SHA support
I have tried cross-compiling, but the build configurations you have, need some changes and I'm yet to have success figuring it out, due to lack of experience. Although cross-compiling openssl was pretty simple

edit:
after some playing around, i have managed to cross-compile, but, unfortunately, executions fails with "workio thread dead, exiting" message
any suggestions on where to dig?

[ZenFr]

Joblo CPUminer is the best CPU miner :-).
Unfornutaly, this miner don't work with equihash algorithm (exept an error from my side ?) !
Do you know a good CPU miner for equihash ?

[4ward]

Unfornutaly, this miner don't work with equihash algorithm (exept an error from my side ?) !
Do you know a good CPU miner for equihash ?

yes, it doesnt support equihash
try nheqminer: https://github.com/nicehash/nheqminer/

[ZenFr]

Unfornutaly, this miner don't work with equihash algorithm (exept an error from my side ?) !
Do you know a good CPU miner for equihash ?

yes, it doesnt support equihash
try nheqminer: https://github.com/nicehash/nheqminer/

Ok, thank you for the reply.
NHEQMiner have no update since 10 months...
But I will try this last version (My last version was the first, a long time ago :-).).

[joblo]

Have you tries cross-compiling in Linux to windows? That could solve the old mingw version issues, let you use a newer gcc and perhaps allow to add SHA support
I have tried cross-compiling, but the build configurations you have, need some changes and I'm yet to have success figuring it out, due to lack of experience. Although cross-compiling openssl was pretty simple

edit:
after some playing around, i have managed to cross-compile, but, unfortunately, executions fails with "workio thread dead, exiting" message
any suggestions on where to dig?

How do you cross-compile? Isn't that what mingw does? How did you make it portable?

That last question may be why the workio thread is dying, possibly a pthread issue. To run on Windows it needs to link to
pthreadGC2 instead of pthread. I have run in to this problem trying to compile on cygwin. I have discovered that I had
set up a "cygwin" compile environment instead of a "mingw" compile environment. The mingw toolchain includes pthreadGC2.

[joblo]

Unfornutaly, this miner don't work with equihash algorithm (exept an error from my side ?) !
Do you know a good CPU miner for equihash ?

yes, it doesnt support equihash
try nheqminer: https://github.com/nicehash/nheqminer/

Ok, thank you for the reply.
NHEQMiner have no update since 10 months...
But I will try this last version (My last version was the first, a long time ago :-).).

Most brand new algos leave little room for improvement as they were initially written for the latest technolgies,
unlike the reshuffled sha3 chains like phi, tribus, hsr ...
They often also have a completely different code structure that is very difficult to import into cpuminer.
In other words all pain, no gain.

[4ward]

Have you tries cross-compiling in Linux to windows? That could solve the old mingw version issues, let you use a newer gcc and perhaps allow to add SHA support
I have tried cross-compiling, but the build configurations you have, need some changes and I'm yet to have success figuring it out, due to lack of experience. Although cross-compiling openssl was pretty simple

edit:
after some playing around, i have managed to cross-compile, but, unfortunately, executions fails with "workio thread dead, exiting" message
any suggestions on where to dig?

How do you cross-compile? Isn't that what mingw does? How did you make it portable?

That last question may be why the workio thread is dying, possibly a pthread issue. To run on Windows it needs to link to
pthreadGC2 instead of pthread. I have run in to this problem trying to compile on cygwin. I have discovered that I had
set up a "cygwin" compile environment instead of a "mingw" compile environment. The mingw toolchain includes pthreadGC2.

in short what i did, on ubuntu 17.04
install mingw-w64 package
download latest sources for openssl, curl and gmp
1. openssl
./Configure mingw64 shared --cross-compile-prefix=x86_64-w64-mingw32-
make
2. curl
./configure --with-winssl --with-winidn --host=x86_64-w64-mingw32
make
3. gmp
./configure --host=x86_64-w64-mingw32 #can also be compiled as shared lib instead of static
make
4. cpuminer
ln -s ../gmp-6.1.2/gmp.h #can probably be specified as lib path, but it was the simplest way to do that
export LDFLAGS="-L/home/ffwd/build/curl-7.56.1/lib/.libs -L/home/ffwd/build/gmp-6.1.2/.libs -L/home/ffwd/build/openssl-1.1.0f"
CFLAGS="-O3 -march=core-avx2 -Wall" CXXFLAGS="$CFLAGS -std=gnu++11 -fpermissive" ./configure --with-curl=../curl-7.56.1 --with-crypto=../openssl-1.1.0f --host=x86_64-w64-mingw32
make

now, the dlls are spread over the system, so i used a highly scientific method of running the .exe file and copying the dlls that it was complaining about.
this is the list of dlls that were missing:
from compiled openssl:
libcrypto-1_1-x64.dll

from compiled curl:
libcurl-4.dll

from /usr/x86_64-w64-mingw32/lib
libwinpthread-1.dll
zlib1.dll

from /usr/lib/gcc/x86_64-w64-mingw32/6.2-win32
libgcc_s_seh-1.dll
libstdc++-6.dll


i have tried all of the -march options you have in winbuild-allarch.sh, and it also compiles with -march=znver1 , bringing sha support to windows (if you can find the source of workio thread issue)

hope you can take it from here and make it work

[joblo]

i have tried all of the -march options you have in winbuild-allarch.sh, and it also compiles with -march=znver1 , bringing sha support to windows (if you can find the source of workio thread issue)

hope you can take it from here and make it work

workio is just a message relay between the miner threads and the stratum thread. If it's broken there is something
fundamentally wrong with the build. The only dependencies workio has are curl and pthreads. A curl error would have
produced a different error message.

I'm still suspicious it's pthreads related because the workio polling loop would break down if pthreads was broken
causing it to exit and producing the error message you saw. Can you confirm how it was linked? You should see either
-lpthreads or -lpthreadsGC2. For mingw it should be -lpthreadsGC2 which it probably is because it was compiled for
a mingw host.

I have no other ideas.

[4ward]

i have tried all of the -march options you have in winbuild-allarch.sh, and it also compiles with -march=znver1 , bringing sha support to windows (if you can find the source of workio thread issue)

hope you can take it from here and make it work

workio is just a message relay between the miner threads and the stratum thread. If it's broken there is something
fundamentally wrong with the build. The only dependencies workio has are curl and pthreads. A curl error would have
produced a different error message.

I'm still suspicious it's pthreads related because the workio polling loop would break down if pthreads was broken
causing it to exit and producing the error message you saw. Can you confirm how it was linked? You should see either
-lpthreads or -lpthreadsGC2. For mingw it should be -lpthreadsGC2 which it probably is because it was compiled for
a mingw host.

I have no other ideas.

-lpthread

how can i fix that?

[joblo]

i have tried all of the -march options you have in winbuild-allarch.sh, and it also compiles with -march=znver1 , bringing sha support to windows (if you can find the source of workio thread issue)

hope you can take it from here and make it work

workio is just a message relay between the miner threads and the stratum thread. If it's broken there is something
fundamentally wrong with the build. The only dependencies workio has are curl and pthreads. A curl error would have
produced a different error message.

I'm still suspicious it's pthreads related because the workio polling loop would break down if pthreads was broken
causing it to exit and producing the error message you saw. Can you confirm how it was linked? You should see either
-lpthreads or -lpthreadsGC2. For mingw it should be -lpthreadsGC2 which it probably is because it was compiled for
a mingw host.

I have no other ideas.

-lpthread

how can i fix that?

It's controlled by configure.ac at line 111:

Code:

# GC2 for GNU static
if test "x$OS" = "xWindows_NT" ; then
   # MinGW
   AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthreadGC2",[])
else
   AC_CHECK_LIB([pthread], [pthread_create], PTHREAD_LIBS="-lpthread",[])
fi

It works as intended in the old MSYS environment but on cygwin linking fails because it can't find pthreadGC2.
I can't get cygwin to use the mingw toolchain which includes pthreadGC2. I've tried using --host and --build with
no luck.