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

Sounds good enough 
Have a great weekend!

I'll have to think about that. Those steps are part of the installatin procedure, IMO, and I don't want to duplicate it.
There may be some ambiguity that installation means only running the installer file. I can clarify that to instruct to do the
the post-install setup up to the end except where it says to close the MSYS2 MSYS window.

How about something like?

Run the installer and perform the post intall setup to update the packages and install the mingw
toolchain. Leave the MSYS2 MSYS window open for further package installations in the next step.

Update: I've updated the instuctions, they should be clearer in what's involved in the MSYS2 installation procedure.
I also removed the option to compile without CPU groups. Since CPU groups are supported from Win7 and MSYS2
requires minimum Win7 there is no situation where it's not supported.

It worked perfectly on a fresh installation of MSYS2(latest build on their website).
I think users should be also informed to follow the instructions on the msys2 website to update the base packages and install some tools for compiling(just in case they overlook these three steps):

Confirmed. I did a quick performance test and it's equal to the existing Windows package. The test was done on a VM so
I'll have to try it on real HW.

I may have found a way to make portable https://stackoverflow.com/questions/6951938/libgmp-10-dll-is-missing.
All the dll's reported missing are there, but I haven't tried it yet. it's better than building them.

Edit:

I've updated the compile instructions for Windows on the Wiki. Give it a test run if you like and let me know of issues.

I suspect portability is still an issue with the MSYS2 build. Only 4 DLLs were missing on a system where
MSYS2 was installed, there may be others on a system without MSYS2.

Edit2:

I ran through the new procedure on an i7-6700K Win10 and had no problems. The executable ran in both the MSYS2 environment
and a Windows comand prompt with the environment variable set. It looks pretty solid.

I won't pursue using MSYS2 for the portable binaries package at this time. I'd still have to package dll's with it,  and I'd have to
setup a Windows virtual machine for package building. It would end up being more work for me. The existing Ubuntu based mingw
environment is already setup and very simple to use. When the time comes to upgrade my development system I may reconsider.

I'm also going to have to do a pass on fixing compiler warnings. GCC-11 is flagging a bunch of string overflows that should be addressed.

You were right, it is a compiler bug!
The problem is a flag in -O2 level that is -ftree-vrp and the default values of its parameters.

We can keep -O3 and add --param=evrp-mode=legacy. From my understanding this param will instruct how the flag -ftree-vrp will perform. The default value for this param is ranger:
It works fine with:
I found some info related to this issue here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103603

Aside from this, you are right about the resulting binary. It's working only in msys2 environment. It might work outside msys2 too, if we provide the path to the DLLs files.
It's just another way of doing it, and if it's possible, why not!

I never got mingw/msys2 working from a Windows host but if you've gotten this far it's worth pursuing.
If you have git an issue would be appropriate for tracking.

It compiles ok with gcc 11.2.0 on Ubuntu-21.10 but I don't have mingw setup for that. I currently use gcc 9.3.0
in Ubuntu 20.04 to build the Windows binaries as documentd on the Wiki.

It's odd that it would compile depending on compiler optimizations, also that it's old code.
If I can identify what code is causing it  there might be a better way to write it even if the bug isn't obvious.
Since it compiles with -O1, unless there's a switch that turns a -O1 warning into a -O2 error, there could also
be a compiler bug.  [Not likely]

Edit: sph_jh doesn't include any Windows compatibility code so mingw compiles the same source code as Linux.

Edit: Not needed anymore:
The error you posted wasn't very useful, it only identified the file, not the line. Are there earlier errors with more info?
Relevant warnings, if any, from the -O1 compile might also be useful in figuring out why this switch makes a difference.

If you can document your procedure I'm sure a lot of people would be grateful, including me. The current procedure
using a full Linux installation, VM or separate PC, is quite cumbersome.

Update:

I got msys2 installed and was able to get to the same point as you.

The good news is if the compiler can get past sph_jh.c it will compile successfully. I haven't tried running it yet.
The bad news is 5 lines of code need to be commented out:


This compiles but if any one line is uncommented it will fail.
I have no idea what the problem is.

The code is very old and stable and hasn't had any problems before.
GCC 11.2 works on Ubuntu-21.10 native and mingw.
It works with msys2 with -O1 but not -O3.
The compiler can't provide a reason for the error.
The main difference between the Ubuntu mingw and Windows mingw, other than the OS itself, is msys2.

I can't make sense of this, could be a compiler bug, msys2 bug, some incompatibility?

I couldn't find another version of GCC in the package repo but maybe an older version of msys2 might
not have this bug.

It's still a lot farther than I've gotten before with msys2.

Update2:

It appears the compiled cpuminer.exe will only run from the msys2 environment. There are 4 missing dll's when running
directly from Windows, some are built by hand for the existing Windows package which means the same would have to be done
to make the msys2 build portable. So it doesn't look suitable for portability, maybe just for Windows geeks that want to compile
themselves.

Assuming the compile issue can be solved, there is the question of performance. There's no point in testing
performance with different compiler optimizations or butchered code. Using cygwin the perfomance is lower
than the current mingw build package. I believe msys2 uses some components from cygwin so it may also be slower.

I tried to compile in Windows 10(MinGW64) with [gcc version 11.2.0 (Rev5, Built by MSYS2 project)].
Using the default I get the following error on file algo/jh/sph_jh.c. Same error occurs with -O2.

Changing optimization level to -O1 solved the problem and it compiled successfully.

Thanks. There's too much phishing going on. I don't want to make it too easy for newbies to get caught.

OK ! edited   message
This link  from the first post...

Please don't post links like that. There is too much malware around.
The only valid links are in the FIRST POST, like I've said many times.

you can download here
valid links are in the FIRST POST

Inside the miner there is file  README.txt ,
Read it - it describes your question...

cpuminer-opt-3.19.4

git issue #359: Fix verthash memory allocation for non-hugepages, broken in v3.19.3.

New option stratum-keepalive prevents stratum timeouts when no shares are
submitted for several minutes due to high difficulty.

Fixed a bug displaying optimizations for some algos.

As usual the download links are in the first post of this thread.

I am running 2 CPUs on a Windows. My OS is Ubuntu. Where is the download?
Thank you,
Stacey

Hello JayDDee
verushash algorithm (Verus , Ticker : VRSC )  will be supported in  future?

cpuminer-opt-3.19.3

Linux: Faster verthash (+25%), scryptn2 (+2%) when huge pages are available.
Small speed up for Hamsi AVX2 & AVX512, Keccak AVX512.

Download links are in the first post of this thread, verify links before clicking on them.

Additional notes about huge pages:

Huge pages is an advanced OS feature that has pros and cons. Users should be familiar with the
issues before enabling huge pages at the OS level. Reserving too many huge pages can destabilize
the system.

cpuminer-opt will automatically use 2 MB huge pages on Linux for Verthash and Scryptn2 if they are
available. The miner does not reserve huge pages, it will only use what has been reserved by the OS.
There is no need to run the miner as root to use huge pages.

Confirmation of huge page use can be done in 2 ways: cpuminer logging which may
require --debug, or by using the proc file system to monitor huge page usage system wide.


Huge pages are not supported on Windows at this time.

thanks for  help !

Use the command line.

https://github.com/JayDDee/cpuminer-opt/wiki/Using-cpuminer-opt

Thanks for the answer
You
  had
  cpuminer-avx2.exe  in   folder manners 3.19.2 ?

 screen -> https://www.screencast.com/t/99K0H51sEPsR
   or just press start file.bat ??

Yes, it's based on the Haswell architecture so use the avx2 build.

Hello
cpuminer-opt 3.19.2  will work for  Intel XEON E5 2696V3 ?