Bitcoin Forum
October 06, 2024, 04:32:03 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 [63] 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 ... 197 »
  Print  
Author Topic: [LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner  (Read 444042 times)
felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
September 16, 2016, 01:11:23 PM
 #1241

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
th3.r00t
Sr. Member
****
Offline Offline

Activity: 312
Merit: 250



View Profile WWW
September 16, 2016, 01:40:59 PM
 #1242

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

BitSend ◢◤Clients | Source
www.bitsend.info
█▄
█████▄
████████▄
███████████▄
██████████████
███████████▀
████████▀
█████▀
█▀












Your Digital Network | 10MB Blocks
Algo: XEVAN | DK3 | Masternodes
Bitcore - BTX/BTC -Project












BSD -USDT | Bittrex | C.Gather | S.Exchange
Cryptopia | NovaExchange | Livecoin
CoinPayments | Faucet | Bitsend Airdrop













████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
th3.r00t
Sr. Member
****
Offline Offline

Activity: 312
Merit: 250



View Profile WWW
September 16, 2016, 01:44:15 PM
 #1243

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 Smiley

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.

BitSend ◢◤Clients | Source
www.bitsend.info
█▄
█████▄
████████▄
███████████▄
██████████████
███████████▀
████████▀
█████▀
█▀












Your Digital Network | 10MB Blocks
Algo: XEVAN | DK3 | Masternodes
Bitcore - BTX/BTC -Project












BSD -USDT | Bittrex | C.Gather | S.Exchange
Cryptopia | NovaExchange | Livecoin
CoinPayments | Faucet | Bitsend Airdrop













████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
September 16, 2016, 01:56:01 PM
 #1244

thanks will try Wink

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

cheers
felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
September 17, 2016, 10:54:11 AM
 #1245

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 (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
September 17, 2016, 05:25:37 PM
 #1246

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.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
th3.r00t
Sr. Member
****
Offline Offline

Activity: 312
Merit: 250



View Profile WWW
September 18, 2016, 07:07:00 AM
 #1247

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.  Smiley
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.  Wink

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.

BitSend ◢◤Clients | Source
www.bitsend.info
█▄
█████▄
████████▄
███████████▄
██████████████
███████████▀
████████▀
█████▀
█▀












Your Digital Network | 10MB Blocks
Algo: XEVAN | DK3 | Masternodes
Bitcore - BTX/BTC -Project












BSD -USDT | Bittrex | C.Gather | S.Exchange
Cryptopia | NovaExchange | Livecoin
CoinPayments | Faucet | Bitsend Airdrop













████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
AlexGR
Legendary
*
Offline Offline

Activity: 1708
Merit: 1049



View Profile
September 19, 2016, 10:08:02 PM
 #1248

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
Full Member
***
Offline Offline

Activity: 201
Merit: 100


View Profile
September 20, 2016, 06:20:51 AM
 #1249

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!

<a href="https://billing.time4vps.eu/?affid=1984"><img src="https://www.time4vps.eu/banners/affiliate/Time4VPS_468_60.png" width="468" height="60" border="0" title="Time4VPS.EU" alt="Time4VPS.EU - VPS hosting in Europe" /></a>
<br /><br />
thesilex
Member
**
Offline Offline

Activity: 61
Merit: 10


View Profile
September 20, 2016, 02:06:50 PM
 #1250

Is it possible to use this miner for Solo Mining? If so, how? Thanks
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
September 20, 2016, 02:37:24 PM
 #1251

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.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
joblo (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
September 20, 2016, 02:38:00 PM
 #1252

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

Only stratum is supported.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
xdrzrex
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
September 20, 2016, 03:23:43 PM
 #1253

I was able to compile with gcc 6.1.
any git available please ?
felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
September 20, 2016, 05:21:06 PM
 #1254

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
Sr. Member
****
Offline Offline

Activity: 312
Merit: 250



View Profile WWW
September 20, 2016, 06:43:52 PM
 #1255

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?

BitSend ◢◤Clients | Source
www.bitsend.info
█▄
█████▄
████████▄
███████████▄
██████████████
███████████▀
████████▀
█████▀
█▀












Your Digital Network | 10MB Blocks
Algo: XEVAN | DK3 | Masternodes
Bitcore - BTX/BTC -Project












BSD -USDT | Bittrex | C.Gather | S.Exchange
Cryptopia | NovaExchange | Livecoin
CoinPayments | Faucet | Bitsend Airdrop













████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████

████
 ████
  ████
   ████
    ████
     ████
      ████
       ████
        ████
       ████
      ████
     ████
    ████
   ████
  ████
 ████
████
AlexGR
Legendary
*
Offline Offline

Activity: 1708
Merit: 1049



View Profile
September 20, 2016, 08:18:28 PM
 #1256

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 (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
September 20, 2016, 09:43:56 PM
 #1257

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.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
felixbrucker
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile WWW
September 20, 2016, 10:18:27 PM
 #1258

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 (OP)
Legendary
*
Offline Offline

Activity: 1470
Merit: 1114


View Profile
September 21, 2016, 12:14:55 AM
 #1259

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.

AKA JayDDee, cpuminer-opt developer. https://github.com/JayDDee/cpuminer-opt
https://bitcointalk.org/index.php?topic=5226770.msg53865575#msg53865575
BTC: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT,
AlexGR
Legendary
*
Offline Offline

Activity: 1708
Merit: 1049



View Profile
September 21, 2016, 12:31:44 AM
 #1260

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.

Quote
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.
Pages: « 1 ... 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 [63] 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 ... 197 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!