Bitcoin Forum
December 03, 2016, 04:52:35 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 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 ... 60 »
  Print  
Author Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only)  (Read 1528165 times)
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
December 20, 2011, 11:26:27 PM
 #61

Pooler,

 Don't you think that NVidia CUDA can run some new assembly code for Scrypt more fast than a CPU?
 I'm asking this because I see that some guys are working on a open source miner for SolidCoin (a.k.a Shitcoin) that run on CUDA...

Best!
Thiago

I might be wrong, but doesn't SolidCoin use a different algorithm?
Apart from that, I'm not a GPGPU expert in any way, but I don't think computing Scrypt on a GPU would be efficient, at least not with the hardware that is available at the moment.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480740755
Hero Member
*
Offline Offline

Posts: 1480740755

View Profile Personal Message (Offline)

Ignore
1480740755
Reply with quote  #2

1480740755
Report to moderator
1480740755
Hero Member
*
Offline Offline

Posts: 1480740755

View Profile Personal Message (Offline)

Ignore
1480740755
Reply with quote  #2

1480740755
Report to moderator
exahash
Sr. Member
****
Offline Offline

Activity: 276



View Profile
December 21, 2011, 03:29:44 AM
 #62

The Pentium D's are running fresh installs of Ubuntu 10.04 64-bit, up to date "aptitude dist-upgrade" and rebooted.  

The artforz miner was pulled from git yesterday with "git pull https://github.com/ArtForz/cpuminer" as was pooler's "git pull https://github.com/pooler/cpuminer"  Both were compiled with CFLAGS="-march=native -O3 -Wall -msse2"

I even tried copying over the binaries that were compiled on the sempron and xeon boxes but got the same results.

I'm thinking there's either something about the P4D's that makes them bad at scrypt, or I've got a bios or OS setting messed up somewhere.

It seems odd that they are 2.8 GHz dual-core chips with each thread doing exactly half it's GHz in khash/s.  Maybe there is some instruction that takes two clock cycles which only takes one in newer chips?

If I can get some time, I might go try Windows and/or Ubuntu 11.10 on one of them to see if it makes a difference.

Yes, I would like to see the performance in 32-bit mode. The Pentium D's were very early 64-bit cpus, and are not as good at SSE as later Core-based models, but I expected them to get some improvement from the new code.

I put Ubuntu 11.10 i386 on one of the Pentium D boxes and it's not good - it only sees one core, with ArtForz's miner doing 0.84 kh/s and pooler's miner running at 1.26 kh/s

There might be an smp kernel, but I'd rather go back to the amd64 build and just count my blessings at 1.48 kh/s x2.
kjlimo
Legendary
*
Offline Offline

Activity: 1498


View Profile WWW
December 21, 2011, 03:58:51 AM
 #63

Intel Core 2 Duo P8700 went from 1.15 khash/s to 3.4khash/s!

CampBX for buying BTCs, Coinbase for selling BTCs or Vircurex or Cryptsy for trading alternate cryptocurrencies like DOGEs

PM me with any questions on these sites!  Happy to help!

Bitcoin Poker at Seals                  Strike Sapphire Casino  Free games every hour & day!
  Get Free Bitcoins here.

Spondoolies-Tech or KnC Miner for the fastest mining hardware available!

Bitpay to help your business accept bitcoin payments!
Intention
Full Member
***
Offline Offline

Activity: 128


View Profile
December 21, 2011, 04:02:00 AM
 #64

Pooler,

 Don't you think that NVidia CUDA can run some new assembly code for Scrypt more fast than a CPU?
 I'm asking this because I see that some guys are working on a open source miner for SolidCoin (a.k.a Shitcoin) that run on CUDA...

Best!
Thiago

I might be wrong, but doesn't SolidCoin use a different algorithm?
Apart from that, I'm not a GPGPU expert in any way, but I don't think computing Scrypt on a GPU would be efficient, at least not with the hardware that is available at the moment.
They do use a different algorithm, funny enough I remember asking him if it used scrypt back on IRC when they launched SC2 since it was supposed to be cpu only and he said yes.

YinCoin YangCoin ☯☯First Ever POS/POW Alternator! Multipool! ☯ ☯ http://yinyangpool.com/ 
Free Distribution! https://bitcointalk.org/index.php?topic=623937
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
December 21, 2011, 09:14:09 PM
 #65

We finally managed to build a 32-bit binary for Mac OS X 10.4, here it is:
http://dl.dropbox.com/u/828037/minerd_for_OSX_10.4.zip
Many thanks to SockPuppet, who did all the hard work! Smiley

Running minerd.exe on Windows with no parameters causes a gpf.
Known bug

That should be fixed now.
I have also added a couple lines of code to auto-detect the number of cores when the number of threads is not specified. This already worked under Linux, but now it should work under Windows, too. (Thanks to diki for testing and for the new binaries!)

Please note that I have changed a few default values in the latest release. The default URL is now http://127.0.0.1:9332/, and the retry parameter has been defaulted to -1, i.e. "retry indefinitely".
This release also changes the "PROOF OF WORK RESULT" message to include information about submitted shares and total hash rate. (Thanks to inlikeflynn!)

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
December 21, 2011, 10:50:44 PM
 #66

We finally managed to build a 32-bit binary for Mac OS X 10.4, here it is:
http://dl.dropbox.com/u/828037/minerd_for_OSX_10.4.zip
Many thanks to SockPuppet, who did all the hard work! Smiley

Running minerd.exe on Windows with no parameters causes a gpf.
Known bug

That should be fixed now.
I have also added a couple lines of code to auto-detect the number of cores when the number of threads is not specified. This already worked under Linux, but now it should work under Windows, too. (Thanks to diki for testing and for the new binaries!)

Please note that I have changed a few default values in the latest release. The default URL is now http://127.0.0.1:9332/, and the retry parameter has been defaulted to -1, i.e. "retry indefinitely".
This release also changes the "PROOF OF WORK RESULT" message to include information about submitted shares and total hash rate. (Thanks to inlikeflynn!)

Well tells us the secret so we can build it ourselves...

Code:
gcc  -O3 -pthread -arch x86_64 -o minerd minerd-cpu-miner.o minerd-util.o minerd-scrypt.o -L/opt/local/lib -lcurl -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lidn -lssl -lcrypto -lssl -lcrypto -lz -lz compat/jansson/libjansson.a -lpthread
Undefined symbols:
  "_x64_scrypt_core", referenced from:
      _scanhash_scrypt in minerd-scrypt.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [minerd] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


In the above gcc line you miss a couple object files.
I didn't change any build-related file in this release, however, so that's a bit strange.
Have you tried running a clean clone/autogen/configure/make?

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
December 21, 2011, 11:11:03 PM
 #67

Yes was problem with old configure.am I copied over however now I get.

{code}

I guess this is the first time you try to compile the new miner on that machine, because I didn't change the assembly code in the latest release, and you are getting errors on that.
What version of gcc/binutils are you using? I think I saw those errors already on some older versions.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
bulanula
Hero Member
*****
Offline Offline

Activity: 518



View Profile
December 21, 2011, 11:19:56 PM
 #68

I was going mad here telling everyone there has to be better performance for Intel CPUs but I was seen a lunatic Roll Eyes

It has finally arrived but sadly since everyone will upgrade, there will not be any profitability increase. Thanks though !
pooler
Hero Member
*****
Offline Offline

Activity: 644


View Profile
December 21, 2011, 11:32:42 PM
 #69

Yes was problem with old configure.am I copied over however now I get.

{code}

I guess this is the first time you try to compile the new miner on that machine, because I didn't change the assembly code in the latest release, and you are getting errors on that.
What version of gcc/binutils are you using? I think I saw those errors already on some older versions.

The binutils I just installed from MacPorts it made no difference same error.


Code:
gcc -version
i686-apple-darwin10-gcc-4.2.1: no input files

binutils @2.21_0

Hey, wait, you are on a Mac! Smiley I thought you were under Linux, sorry. Unfortunately gcc 4.2 seems to have some problems with macros in assembly code.
In order to get it to compile, SockPuppet had to expand all the macros by hand. Unfortunately I cannot just use his version in the main package, because the code becomes very hard to read. But I think you can contact him if you want the modified sources.

BTC: 15MRTcUweNVJbhTyH5rq9aeSdyigFrskqE · LTC: LTCPooLqTK1SANSNeTR63GbGwabTKEkuS7
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1414

Newbie


View Profile
December 22, 2011, 05:34:54 AM
 #70

I was going mad here telling everyone there has to be better performance for Intel CPUs but I was seen a lunatic Roll Eyes

It has finally arrived but sadly since everyone will upgrade, there will not be any profitability increase. Thanks though !

We heard u. The profit comes from better performance on older machines (new ones get less boost). Also with improved miner we have better chance to survive 51% attacks.

PS: I know at least 2 guys who wrote faster LTC miners but since they have not published their sources nor compiled binaries we shouldn't take this into account. So why bother about such things? Any program can be improved indefinitely.
sd
Hero Member
*****
Offline Offline

Activity: 730



View Profile
December 22, 2011, 08:47:24 AM
 #71

Also with improved miner we have better chance to survive 51% attacks.

Not unless you assume the people doing the 51% attack already have the faster miner.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1414

Newbie


View Profile
December 22, 2011, 09:05:24 AM
 #72

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
December 22, 2011, 03:01:39 PM
 #73

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.
You don't seem to understand. If they were using the same miner as we did before, then with the new one, the dark pool has twice the speed now, but we have also increased it.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 22, 2011, 03:05:24 PM
 #74

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.

terrytibbs
Hero Member
*****
Offline Offline

Activity: 560



View Profile
December 22, 2011, 03:20:34 PM
 #75

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.


You are wrong. This code increases the hashing rate more for specific architectures than it does for others. An attack by one of the weaker architectures (AMD right now, if I'm not mistaken) can still be mitigated if everyone switches to this.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
December 22, 2011, 03:24:01 PM
 #76

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.


You are wrong. This code increases the hashing rate more for specific architectures than it does for others. An attack by one of the weaker architectures (AMD right now, if I'm not mistaken) can still be mitigated if everyone switches to this.

That would assume the distribution of Intel vs AMD is materially different between an attacker and a defender.  A botnet is a collection of semi-random computer systems with a wide variety of hardware.  The defenders likewise are running on a wide variety of hardware.      Sure if all the "good guys" had Intels and all the botnets had nothing but AMD chips then the software improvement would change the balance but that dynamic doesn't exist.

Technically a botnet has more control of its nodes.  So a botnet could be assured that all its nodes are running the most efficient software.  If only a fraction of the "good guys" upgrade to more efficient software then the improved code would actually shift the balance away from the defenders.   Luckily there is a direct financial incentive to upgrade.  If you don't upgrade your revenue/profits will decline.  If you do upgrade you avoid lower profits.
terrytibbs
Hero Member
*****
Offline Offline

Activity: 560



View Profile
December 22, 2011, 03:41:38 PM
 #77

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.


You are wrong. This code increases the hashing rate more for specific architectures than it does for others. An attack by one of the weaker architectures (AMD right now, if I'm not mistaken) can still be mitigated if everyone switches to this.

That would assume the distribution of Intel vs AMD is materially different between an attacker and a defender.  A botnet is a collection of semi-random computer systems with a wide variety of hardware.  The defenders likewise are running on a wide variety of hardware.      Sure if all the "good guys" had Intels and all the botnets had nothing but AMD chips then the software improvement would change the balance but that dynamic doesn't exist.

Technically a botnet has more control of its nodes.  So a botnet could be assured that all its nodes are running the most efficient software.  If only a fraction of the "good guys" upgrade to more efficient software then the improved code would actually shift the balance away from the defenders.   Luckily there is a direct financial incentive to upgrade.  If you don't upgrade your revenue/profits will decline.  If you do upgrade you avoid lower profits.

Botnets aren't our only enemy. We are also fighting possible future ASIC or FPGA implementations. Come-from-Beyond beyond is correct in saying that "[the] more power we have - [the] stronger we are." You, on the other hand, are incorrect in saying that "all that matters is relative strength."
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1414

Newbie


View Profile
December 22, 2011, 04:43:24 PM
 #78

You don't seem to understand. If they were using the same miner as we did before, then with the new one, the dark pool has twice the speed now, but we have also increased it.

Now I got it. U r right.

PS: Seems to me I shouldn't publish my miner that works at 2.5 rate (2500 h/s for 1 GHz of cpu). Just to prevent its usage for a so-called "dark pool"...
Remember remember the 5th of November
Legendary
*
Offline Offline

Activity: 1526

Reverse engineer from time to time


View Profile
December 22, 2011, 04:48:40 PM
 #79

You don't seem to understand. If they were using the same miner as we did before, then with the new one, the dark pool has twice the speed now, but we have also increased it.

Now I got it. U r right.

PS: Seems to me I shouldn't publish my miner that works at 2.5 rate (2500 h/s for 1 GHz of cpu). Just to prevent its usage for a so-called "dark pool"...
Glad that got sorted out.

As for the miner, the Atom CPU which is 1.6Ghz can do over 5Kh/s with the new miner.

BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 1414

Newbie


View Profile
December 22, 2011, 04:50:20 PM
 #80

5 kh/s just 1 thread?
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 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 ... 60 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!