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

[felixbrucker]

also interestingly 3.4.5 compile fails with multiple error about "PACKAGE_NAME" (being undeclared, expected ',' or ';' before, expected ')' before etc) while 3.4.6 compiles just fine

though i noticed no real improvement on my tiny A6-6400K compared to the AVX core-i build i used previously when utilizing only AES and SSE2, however when using AVX the game changed and speedup was a little over 100% (18->45 H/s)

cheers

[1713868394]

1713868394

[1713868394]

1713868394

[1713868394]

1713868394

[1713868394]

1713868394

[th3.r00t]

it seems i need to add some dirs to PATH, is this correct?

when using the 7z archive and starting winbuild.sh "no suitable compiler" is found, so i added /d/msys/opt/windows_64/bin to the PATH and it got further, just to display it cant find curl/curl.h

where do i add this path definition for includes and later libs? (/d/msys/opt/windows_64/include [...]/lib etc)

cheers


edit: just did it, my first ever successful compile on windows, i inserted the dirs into the winbuild.sh like so (-I/d/msys/opt/windows_64/include -L/d/msys/opt/windows_64/lib64) but there has to be a "better" systemwide setting for this, right?

thanks for your support!

Do you change your extract drive from C to D?
It looks that way.

All path definition are in this TXT file DRIVE:\msys\etc\profile

[th3.r00t]

also interestingly 3.4.5 compile fails with multiple error about "PACKAGE_NAME" (being undeclared, expected ',' or ';' before, expected ')' before etc) while 3.4.6 compiles just fine

though i noticed no real improvement on my tiny A6-6400K compared to the AVX core-i build i used previously when utilizing only AES and SSE2, however when using AVX the game changed and speedup was a little over 100% (18->45 H/s)

cheers

I had issues with 3.4.5 too.
I never had a successful build for windows, but 3.4.6 came fast so I don't feel the need to report it.

About the improvement I was sure that Intel-AMD compile is cripled somehow.
I think I said that few posts back.

Anyway, glad to be of help for a fellow AMD (AB)user

EDIT: I manage to my AMD build a little faster by using these dll's:

Code:

http://pc.cd/pMyotalK

These are the last version of win64 prebuild dll's for libcurl, OpenSSL, jansson and pthreads.

Code:

libcurl/7.50.1 OpenSSL/1.0.2h zlib/1.2.8 WinIDN libssh2/1.7.0 nghttp2/1.13.0
jansson/2.6 pthreads/2.9.1.0

pthreads for me is better than winpthreads dll that I used before.

[felixbrucker]

thanks will try

about the includes etc: i noticed only the bin path is declared in profile file, include and lib64 dirs are somewhere else?

cheers

[felixbrucker]

On a tangent I'm curious about the mining performance of the A6's IGPU. The CPU alone is weak but CPU+IGPU
might make up for it.

i can now deliver: best it can do (as of now) is 0.00005404 BTC/Day with nicehash and blake256r8vnl
i just ran the NHM benchmark, other algos and other pools might change it a bit but you might get an idea from this

cheers

[joblo]

also interestingly 3.4.5 compile fails with multiple error about "PACKAGE_NAME" (being undeclared, expected ',' or ';' before, expected ')' before etc) while 3.4.6 compiles just fine

though i noticed no real improvement on my tiny A6-6400K compared to the AVX core-i build i used previously when utilizing only AES and SSE2, however when using AVX the game changed and speedup was a little over 100% (18->45 H/s)

cheers

I've been following this discussion and I have no explanation for the compile error in v3.4.5. PACKAGE_NAME is defined in configure
and there are no changes to that file, other than updating PACKAGE_VERSION every release.

In another post it was mentioned that Intel-AMD compile was broken. I presume that means compiling an AMD load on an Intel CPU.
If that is the case it doesn't look like I will be able to provide optimum AMD binaries.

I'll keep following the progress and comment when appropriate.

[th3.r00t]

In another post it was mentioned that Intel-AMD compile was broken. I presume that means compiling an AMD load on an Intel CPU.
If that is the case it doesn't look like I will be able to provide optimum AMD binaries.

You presume correct. 
With Intel-AMD compile, I do mean AMD binary compiled on Intel CPU.

I suggest you keep up the great work with the miner itself and the windows binaries compiled on you Intel CPU.
For every average user your Windows binaries should be fast enough (even not optimal).
After all it's not your fault that Intel decided to criple down binaries for AMD CPU's. 

For others like me that like to tinker, to squeeze every little bit of extra hash from their AMD CPU,
I've shared my MinGW64 install that works nice on AMD's.
That way every one that want to get dirty a bit more can share their results here and everyone can test and try to improve the them.

[AlexGR]

If anyone wants to squeeze a bit more "easy" speed out of their binaries, I wrote a technique that I was using a couple of years ago by combining multiple compilers: https://steemit.com/development/@alexgr/creating-faster-c-c-binaries-without-changing-a-single-line-of-code

That's mainly for multi-algo setups where there are C implementations - and there might be speed differences in how these are executed from different compilers. Obviously, when we have machines running 24/7, even 2-5-10% makes a difference.

[birty555]

Hi - are there any plans to make this work with ARM NEON extensions as well as SSE? Would like to get it running on an Odroid XU4. Can build and run tpruvot's version but want it for scrypt-N and this version works better on my other machines
thanks!

[thesilex]

Is it possible to use this miner for Solo Mining? If so, how? Thanks

[joblo]

Hi - are there any plans to make this work with ARM NEON extensions as well as SSE? Would like to get it running on an Odroid XU4. Can build and run tpruvot's version but want it for scrypt-N and this version works better on my other machines
thanks!

If you only need scrypt-n use TPruvot, cpuminer-opt is no faster. You can then get a skilled ARM coder to optimize it for you.
I have no interest in supporting ARM in cpuminer-opt.

[joblo]

Is it possible to use this miner for Solo Mining? If so, how? Thanks

Only stratum is supported.

[xdrzrex]

I was able to compile with gcc 6.1.
any git available please ?

[felixbrucker]

I was able to compile with gcc 6.1.
any git available please ?

not until now, cpuminer-opt code is on git from nicehash (with modifications i guess) here: https://github.com/nicehash/cpuminer-opt and from myself to more easily distribute to my miners on linux: https://github.com/felixbrucker/cpuminer-opt (though 3.4.6 is still missing because of benchmark bug, will upload it when 3.4.7 is out as i dont want to do any changes to the code myself)

cheers

[th3.r00t]

If anyone wants to squeeze a bit more "easy" speed out of their binaries, I wrote a technique that I was using a couple of years ago by combining multiple compilers: https://steemit.com/development/@alexgr/creating-faster-c-c-binaries-without-changing-a-single-line-of-code

That's mainly for multi-algo setups where there are C implementations - and there might be speed differences in how these are executed from different compilers. Obviously, when we have machines running 24/7, even 2-5-10% makes a difference.

Guess that is for Lunux?
Do you test it on your compile?
What are the speed diff's with default compile and your method?

[AlexGR]

If anyone wants to squeeze a bit more "easy" speed out of their binaries, I wrote a technique that I was using a couple of years ago by combining multiple compilers: https://steemit.com/development/@alexgr/creating-faster-c-c-binaries-without-changing-a-single-line-of-code

That's mainly for multi-algo setups where there are C implementations - and there might be speed differences in how these are executed from different compilers. Obviously, when we have machines running 24/7, even 2-5-10% makes a difference.

Guess that is for Lunux?
Do you test it on your compile?
What are the speed diff's with default compile and your method?

Yes, Linux.
Yes, I have tested it with X11 - back when more of its algorithms were C-based. I haven't tried recently due to x11 asics, and more files being assembly.
I got >10% in gains on my pc.

[joblo]

If anyone wants to squeeze a bit more "easy" speed out of their binaries, I wrote a technique that I was using a couple of years ago by combining multiple compilers: https://steemit.com/development/@alexgr/creating-faster-c-c-binaries-without-changing-a-single-line-of-code

That's mainly for multi-algo setups where there are C implementations - and there might be speed differences in how these are executed from different compilers. Obviously, when we have machines running 24/7, even 2-5-10% makes a difference.

Guess that is for Lunux?
Do you test it on your compile?
What are the speed diff's with default compile and your method?

Yes, Linux.
Yes, I have tested it with X11 - back when more of its algorithms were C-based. I haven't tried recently due to x11 asics, and more files being assembly.
I got >10% in gains on my pc.

10% just from the compiler?

I'm not sure what you means by "more of its algorithms were C-based". I haven't added any assembly code.

I've been dithering about the benchmark issue while there were no other pressing issues to prompt a release. It has to do with the way the nonce
is initialized on startup. The change in v3.4.6 (init to 0) seems to be cleaner than the original (init pseudo-random) as it eliminates the
occasional 1 hash scans on startup. But it breaks benchmark. I'm likely to init the nonce differently depending on benchmark.

The next release will also add CPU temperature display. I've considered a few options based on usefulness vs work involved. I'm thinking of
simp;ly ading the temp to the share submission report, it was the simplest implementation although not architecturally sound. It only gets
displayed when a share is submitted. If no shares are submitted for a long time it isn't very useful.

A periodic temperature report, independent of share submissions, would be better but it's more work and would add verbosity to
the output.

[felixbrucker]

If anyone wants to squeeze a bit more "easy" speed out of their binaries, I wrote a technique that I was using a couple of years ago by combining multiple compilers: https://steemit.com/development/@alexgr/creating-faster-c-c-binaries-without-changing-a-single-line-of-code

That's mainly for multi-algo setups where there are C implementations - and there might be speed differences in how these are executed from different compilers. Obviously, when we have machines running 24/7, even 2-5-10% makes a difference.

Guess that is for Lunux?
Do you test it on your compile?
What are the speed diff's with default compile and your method?

Yes, Linux.
Yes, I have tested it with X11 - back when more of its algorithms were C-based. I haven't tried recently due to x11 asics, and more files being assembly.
I got >10% in gains on my pc.

10% just from the compiler?

I'm not sure what you means by "more of its algorithms were C-based". I haven't added any assembly code.

I've been dithering about the benchmark issue while there were no other pressing issues to prompt a release. It has to do with the way the nonce
is initialized on startup. The change in v3.4.6 (init to 0) seems to be cleaner than the original (init pseudo-random) as it eliminates the
occasional 1 hash scans on startup. But it breaks benchmark. I'm likely to init the nonce differently depending on benchmark.

The next release will also add CPU temperature display. I've considered a few options based on usefulness vs work involved. I'm thinking of
simp;ly ading the temp to the share submission report, it was the simplest implementation although not architecturally sound. It only gets
displayed when a share is submitted. If no shares are submitted for a long time it isn't very useful.

A periodic temperature report, independent of share submissions, would be better but it's more work and would add verbosity to
the output.

are you talking about the temperature also available via api? if so, on many systems this temp is either nonexistent (windows mostly) or some mobo temp, only on laptops i have received the actual cpu temp this way

[joblo]

The next release will also add CPU temperature display. I've considered a few options based on usefulness vs work involved. I'm thinking of
simp;ly ading the temp to the share submission report, it was the simplest implementation although not architecturally sound. It only gets
displayed when a share is submitted. If no shares are submitted for a long time it isn't very useful.

A periodic temperature report, independent of share submissions, would be better but it's more work and would add verbosity to
the output.

are you talking about the temperature also available via api? if so, on many systems this temp is either nonexistent (windows mostly) or some mobo temp, only on laptops i have received the actual cpu temp this way

Yes same as API, forgot to mention Linux only.

[AlexGR]

10% just from the compiler?

Multiple compilers, each one taking a different hash. Actually I think it peaked around 13-14% for x11 (with darkcoin 1.2 miner*), by combining gcc/clang/icc and having three sets of cflags - although it took me days to fine tune it.

* It's performance is similar (-5%) for core2 & c2 quad architecture to current cpuminer-opt 3.4.6.

I'm not sure what you means by "more of its algorithms were C-based". I haven't added any assembly code.

I was talking about a couple of years ago when there was less use of intrinsics and fewer advanced implementations embedded (darkcoin miner 1.2 and 1.3 days). I'm not currently mining x11 due to asics, but the principle is the same as it always has been - as long as there are some c implementations without asm/intrinsics (it leaves much less room for the compiler to make a difference) one can try alternative compilers per hash and pick the winners, to increase the throughput.