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

Another update, sorry for the spam.

Managed to install devtoolset-6 (GCC 6.3.1), it was quite straightforward:




The errors are always there, but at least they more detailed. They are all very similar, I'll paste just one:


Searching in and here found just this similar question: https://stackoverflow.com/questions/43128698/inlining-failed-in-call-to-always-inline-mm-mullo-epi32-target-specific-opti but not much idea how to proceed.

Sorry if I flood the thread, but it may be useful information to others, too.

Managed to update to gcc 4.9 (thanks to this guy's comment), with:

(reminder: I'm on Centos6.9)

sudo yum install centos-release-scl
sudo yum install devtoolset-3-toolchain
scl enable devtoolset-3 bash

Relaunched make, got these lines on screen (still out of redirected txt, duh):



warning: implicit declaration of function ‘syslog’ [-Wimplicit-function-declaration]

Then many other lines started to popout, ending with these, that may be related to Intel intrinsics already mentioned before:



Now I try to fix all these, if you have any clues to spare, thank you in advance.

Found this for _mm_shuffle_epi8 of the last screenshot : https://msdn.microsoft.com/en-us/library/bb531427(v=vs.120).aspx

The full makelog2.txt: https://pastebin.com/yr6dexwL

---

after digging here and there, it looks like a matter of upgrading GCC to the greater version available, from my current 4.9 to 6.x or 7.x even.

Thank you, I'll surely need that once I manage to compile the miner.

I'm slowly trying to come to an end at this

Followed your advice, did a make -B > makelog.txt.

First lines to popup on screen (they weren't redirected to makelog.txt, strange), were about 10 of this:

configure: WARNING: The assembler does not support the AVX2 instruction set.

It seems for that I need gcc 4.7 at least, I'm running gcc 4.4.7, I'll try to update this as first thing.

Is http://www.ypool.co a stratum pool?  Could you use that?  The pool operator apparently thought it was regular yescrypt so he set it up that way, but he's obviously not finding any blocks because no one is actually sending him yescryptR16 solutions.  Can you use his mistake to test, or does it not work that way?

BTW I don't mean to be pushy, if you can't be bothered (edit: or if it won't work) it's fine, I just thought I'd let you know in case you wanted to.

Not until there's a stratum pool where I can test. It looks like the same hash function with different parameters.

Is this "yescryptR16" actually a new algorithm, or is it just yescrypt?   https://bitcointalksearch.org/topic/ann-cpu-mining-yenten-v201-ytn-yescryptr16-exchange-avilable-2329470

If new, any plans to support?  

Thanks!

Edit: source is at https://github.com/conan-equal-newone/yenten

here is a good starting point on what docker is: https://opensource.com/resources/what-docker

Good to read you got it working but too bad no significant improvement.

At my end I got it working using http://www.msys2.org/ but again no significant performance difference.

Msys2 is pretty clumsy to setup, nice installer but it only installs a minimal base system. Then you use a clumsy
package manager to install everything else.

gcc 6.3 7.2 and openssl 1.0.2l are available. Compiling with SHA works but I couldn't verify due to lack of SHA CPU.
It works fine from within Msys2 shell, getting it to work from a DOS shell required copying all the DLLs included in Mingw,
over 40 of them.

I don't like bundling DLLs, just delivering a Windows binary is scary enough. I was hoping there was a way to download
just the DLLs from Msys2 but they are all hidden in individual package files. It seems the only way to get them is to install
Msys2 and all the packages that provide the DLLs.

First time I heard of it, this could give an hint on how comfy I'm with it

Is is a vm manager like virtualbox or some kinda vps? Fact is I'm already paying - well, my boss is - for some dedicated servers with much power not to use and I'd loved to use them before going to spend other money around.

(sorry to the op because of this offtopic)

yup, after linking with pthreadGC2 it works fine.
and it looks like it brings a very slight improve in performance (about 1% or so in a few algos that i benchmarked)
compiling sha version also works, too bad i don't have hardware to test it

You could run everything inside docker, if you are comfortable with that

Thanks for reply. Since I've root access on those dedicated machines I could install the packages but I preferrerd not, let's see. Too bad Centos was installed instead of Ubuntu.

Those real servers would need most of the same packages, it's probably not worth it.

As for your compile error the first error is always the most important. From what you posted it looks like the Intel intrinsics aren't insrtalled.
You may find earlier errors for missing immintrin.h or files with similar names. I don't know if they exist for Centos 6, it's very old, or what
the package might be called.

I'm trying to compile the 3.7.0 on a Centos 6.9 vm on virtualbox to later copy it ont a real machine server running the same Centos 6.9, I don't even know if it makes sense, but I'm doing it to not install extra packages in the real server.

After managing to bypass several errors and difficulties such as the #pragma error of gcc 4.4.7 by upgrading gcc (not so obvious), now I'm stuck with these:



Does a fix exist for the errors above or alternatively does a precompiled version exist of cpuminer-opt-3.7.0 to run in a Centos 6.9 system with this processor: https://ark.intel.com/it/products/88173/Intel-Xeon-Processor-E3-1245-v5-8M-Cache-3_50-GHz ( SSE4.1/4.2, AVX2 )?

Thank you in advance.

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


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.

-lpthread

how can i fix that?

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.

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

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.