Bitcoin Forum
September 26, 2016, 12:14:52 AM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   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 »
  Print  
Author Topic: New demonstration CPU miner available  (Read 371722 times)
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
June 09, 2011, 05:45:07 PM
 #401

The new changes seem to work rather well on my 64bit linux. However, since some of the usage texts are now incorrect, I'd like to suggest the following patch:
Code:
--- cpuminer-git/cpu-miner.c    2011-06-09 16:58:43.137777002 +0200
+++ cpuminer_build/cpu-miner.c  2011-06-09 19:25:52.087777001 +0200
@@ -140,24 +140,28 @@
          "(-h) Display this help text" },
 
        { "config FILE",
-         "(-c FILE) JSON-format configuration file (default: none)\n"
+         "(-c FILE) JSON-format configuration file (default: none)\n\t"
          "See example-cfg.json for an example configuration." },
 
        { "algo XXX",
          "(-a XXX) Specify sha256 implementation:\n"
-         "\tc\t\tLinux kernel sha256, implemented in C (default)"
+#ifdef WANT_X8664_SSE2
+         "\t\tc\t\tLinux kernel sha256, implemented in C"
+#else
+         "\t\tc\t\tLinux kernel sha256, implemented in C (default)"
+#endif
 #ifdef WANT_SSE2_4WAY
-         "\n\t4way\t\ttcatm's 4-way SSE2 implementation"
+         "\n\t\t4way\t\ttcatm's 4-way SSE2 implementation"
 #endif
 #ifdef WANT_VIA_PADLOCK
-         "\n\tvia\t\tVIA padlock implementation"
+         "\n\t\tvia\t\tVIA padlock implementation"
 #endif
-         "\n\tcryptopp\tCrypto++ C/C++ implementation"
+         "\n\t\tcryptopp\tCrypto++ C/C++ implementation"
 #ifdef WANT_CRYPTOPP_ASM32
-         "\n\tcryptopp_asm32\tCrypto++ 32-bit assembler implementation"
+         "\n\t\tcryptopp_asm32\tCrypto++ 32-bit assembler implementation"
 #endif
 #ifdef WANT_X8664_SSE2
-         "\n\tsse2_64\t\tSSE2 implementation for x86_64 machines"
+         "\n\t\tsse2_64\t\tSSE2 implementation for x86_64 machines (default)"
 #endif
          },
 
@@ -191,7 +195,11 @@
 #endif
 
        { "threads N",
+#ifdef WIN32
          "(-t N) Number of miner threads (default: 1)" },
+#else
+         "(-t N) Number of miner threads (default: #available cpus)" },
+#endif
 
        { "url URL",
          "URL for bitcoin JSON-RPC server "
@@ -753,7 +761,7 @@
                struct option_help *h;
 
                h = &options_help[i];
-               printf("--%s\n%s\n\n", h->name, h->helptext);
+               printf("--%s\n\t%s\n\n", h->name, h->helptext);
        }
 
        exit(1);

Summary of changes:
  • tabs before description items to improve readability
  • the default algorithm is now marked correctly
  • on Linux, it now says "default: #available cpus" instead of just "default: 1" (if anyone knows how to insert the actual numer here, be my guest)

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
Transactions must be included in a block to be properly completed. When you send a transaction, it is broadcast to miners. Miners can then optionally include it in their next blocks. Miners will be more inclined to include your transaction if it has a transaction fee.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1474848892
Hero Member
*
Offline Offline

Posts: 1474848892

View Profile Personal Message (Offline)

Ignore
1474848892
Reply with quote  #2

1474848892
Report to moderator
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
June 09, 2011, 05:58:58 PM
 #402

I agree with your changes.  I think the default should be the maximum number of CPUs on board.  The default wasn't the SSE2_64?  Hmm, good thing I set that then.
But I don't think I've ever seen Via padlock not crash the program on start.  Does it actually have a use?  If no, it could be edited out until then.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
June 09, 2011, 06:16:47 PM
 #403

I agree with your changes.  I think the default should be the maximum number of CPUs on board.  The default wasn't the SSE2_64?  Hmm, good thing I set that then.
But I don't think I've ever seen Via padlock not crash the program on start.  Does it actually have a use?  If no, it could be edited out until then.
I only changed the usage text, no "proper" code. SSE2_64 is default on 64bit Linux since the last commit, therefore the usage text was wrong, so I wrote a patch to amend that.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile WWW
June 09, 2011, 06:46:44 PM
 #404

Actually Con's patch is rather simplified -- you want the number of cores, not the total number of processors (which might include HyperThread siblings).

If you use all cores + HT, then your hash performance is slower than cores alone.


Jeff Garzik, bitcoin core dev team

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1918


Ruu \o/


View Profile WWW
June 09, 2011, 09:00:01 PM
 #405

Actually Con's patch is rather simplified -- you want the number of cores, not the total number of processors (which might include HyperThread siblings).

If you use all cores + HT, then your hash performance is slower than cores alone.



I tested total threads vs total cores and got slightly more with total threads on i7. Plus there is no particularly easy and reliable way to detect cores versus threads. So total "processors" actually generated more in my testing.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1918


Ruu \o/


View Profile WWW
June 09, 2011, 09:21:46 PM
 #406

Actually that's not quite true. There was one more complex setup that produced higher throughput. If I set the number of mining threads to the total number of cores only, and then bound each worker thread to all the logical CPUs that shared cache, the throughput was a bit better again. However which cores shares threads is even harder to detect reliably without digging around in /sys and the format has changed between kernels. Furthermore, on my i7, the shared caches aren't even sequential numbers so binding threads to sequential logical CPUs was worse (i.e. CPUs 0 and 2 shared caches and 1 and 3 and so on).

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
June 10, 2011, 12:40:01 PM
 #407

I believe there is one i7 processor out there that doesn't have a shared cache.  Each core on it has its own dedicated 2M cache.  However, if you could detect the shared cache, you could also detect the unshared cache and end up with what I suggested above that I had no idea how to start coding for a similar reason.  But anyhow, if you're worried about the kernels having sys information in different locations, it's a simple if-else-else statement that you'll be using to find or not find it.
But, as I suggested, using the two cores sharing the same cache, you can have each core perform different portions of the same work.  While one has completed half of the equations, you can send the work off to the next core for completion and get the next work.  With each core doing a specific task, you can simplify the code for unrolled loops and pass fewer instructions to the processor I believe.  Fewer instructions generally means less overhead.
So a part of the problem is the first getwork.  Half as many threads will be running until half of the work is completed and passed to the next core.  I don't know a way around it since I would think the SHA equation to only be done according to the order of operations (Parenthesis, exponents, multiple/divide...).  Actually, now that I think about it, if a matrix calculation comes into play, that would have its own unique optimizations...eep digressing!  But yeah, how to split the cores to keep them from doing redundant work is the biggest issue here.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1918


Ruu \o/


View Profile WWW
June 10, 2011, 12:45:13 PM
 #408

Bouncing work from one CPU to another will decrease throughput a fair amount. The cost of that should not be discounted. Anyway feel free to try...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
rocksalt
Jr. Member
*
Offline Offline

Activity: 52



View Profile
June 10, 2011, 04:28:05 PM
 #409

is there a working flag for outputting to a log file for this using the windows binaries?

I've tried
--f
-f
>

with full path, just a file name, with extension, without ext, with "" "" and also without.

I think i've worn my fingers out doing this

TIPS/Donations: mwahahaha.. not that desperate, just a thank you or a flame please but if you must... 1NTZcWQGfdGang9piBKUv9Z1VZ7x6cTXjV
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
June 10, 2011, 05:22:46 PM
 #410

You need to redirect stderr. According to http://www.techtalkz.com/windows-xp/27452-redirect-stdout-stderr-windows-shell.html, "2>" will do that.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
rocksalt
Jr. Member
*
Offline Offline

Activity: 52



View Profile
June 11, 2011, 06:24:28 AM
 #411

Im now discovering a different issue Tongue

minerd.exe --algo cryptopp_asm32 --s 2 --url http://btcguild.com/ --userpass xxxx:xxx this runs when i tried it on deepbit, local miner and a few others....

however on btcguild i get the following error

[2011-06-12 10:02:16] 1 miner threads started, using SHA256 'cryptopp_asm32' algorithm.
[2011-06-12 10:02:20] JSON decode failed(1): '[' or '{' expected near '<'
[2011-06-12 10:02:20] json_rpc_call failed, retry after 30 seconds


its only happening with btcguild though, not any of the other mining pools i tested with.

anyone come accross this before ??

Win7
Intel Dual Core
Nvidia GTX470OC

TIPS/Donations: mwahahaha.. not that desperate, just a thank you or a flame please but if you must... 1NTZcWQGfdGang9piBKUv9Z1VZ7x6cTXjV
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1918


Ruu \o/


View Profile WWW
June 11, 2011, 03:41:35 PM
 #412

Hi Jeff, et al.

I've made some modifications to the output to generate a total throughput counter since there was confusion with the multiple threads issue, cleaned up the output a little, and added a solution counter. I also dropped a lot of output when only one thread is in use. Please pull the changes into your tree if you agree with the changes.

it now looks like this:

[2011-06-12 01:37:26] [Total: 8.40 Mhash/sec] [thread 3: 109989796 hashes, 3075 khash/sec] [Solved: 0]
[2011-06-12 01:37:26] PROOF OF WORK RESULT: true (yay!!!)
[2011-06-12 01:37:47] [Total: 8.45 Mhash/sec] [thread 0: 183024176 hashes, 3090 khash/sec] [Solved: 1]
[2011-06-12 01:37:48] [Total: 9.89 Mhash/sec] [thread 1: 183024176 hashes, 3085 khash/sec] [Solved: 1]
[2011-06-12 01:37:48] [Total: 11.31 Mhash/sec] [thread 2: 183024176 hashes, 3082 khash/sec] [Solved: 1]
[2011-06-12 01:38:27] [Total: 9.72 Mhash/sec] [thread 3: 183316328 hashes, 3019 khash/sec] [Solved: 1]
[2011-06-12 01:38:50] [Total: 9.54 Mhash/sec] [thread 0: 186126280 hashes, 2969 khash/sec] [Solved: 1]
[2011-06-12 01:38:50] [Total: 10.52 Mhash/sec] [thread 1: 186126280 hashes, 2989 khash/sec] [Solved: 1]
[2011-06-12 01:38:51] [Total: 11.50 Mhash/sec] [thread 2: 186126280 hashes, 3007 khash/sec] [Solved: 1]

Thanks.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1918


Ruu \o/


View Profile WWW
June 11, 2011, 04:06:32 PM
 #413

Hmm perhaps "solved" isn't quite the right word there for accepted blocks.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
dserrano5
Legendary
*
Offline Offline

Activity: 1568



View Profile
June 11, 2011, 04:20:36 PM
 #414

As a user I would expect that total Mhash/s were the sum of the khash/s of all threads—in your example it would be always around 12 Mhash/s (since each thread works at a consistent pace of nearly 3000 khash/s). That's not the case, so I guess the algorithm is different.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1918


Ruu \o/


View Profile WWW
June 11, 2011, 04:22:25 PM
 #415

As a user I would expect that total Mhash/s were the sum of the khash/s of all threads—in your example it would be always around 12 Mhash/s (since each thread works at a consistent pace of nearly 3000 khash/s). That's not the case, so I guess the algorithm is different.

That was the miner just starting up. After a while it converges more and more.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1918


Ruu \o/


View Profile WWW
June 12, 2011, 11:42:39 PM
 #416

Now that I've got a meaningful total throughput counter, I can confirm that running number of threads == number of logical processors on i7 is actually faster than even carefully bound number of threads == number of physical cores. This means that the default behaviour of minerd with my modifications which chooses how many threads to start up will give you the highest throughput.

My cumulative changes are here till jgarzik pulls them if anyone's interested:
https://github.com/ckolivas/cpuminer

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 13, 2011, 02:58:04 PM
 #417

Im getting this error in Ubuntu 10.04 LTS when running autogen.sh:

~/cpuminer$ sh autogen.sh
configure.ac:15: installing `./compile'
configure.ac:4: installing `./config.guess'
configure.ac:4: installing `./config.sub'
configure.ac:6: installing `./install-sh'
configure.ac:6: installing `./missing'
compat/jansson/Makefile.am: installing `./depcomp'
Makefile.am: installing `./INSTALL'
configure.ac:96: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Any suggestion?
RaTTuS
Hero Member
*****
Offline Offline

Activity: 792


Bite me


View Profile
June 13, 2011, 03:19:47 PM
 #418

try :-
./configure

In the Beginning there was CPU , then GPU , then FPGA then ASIC, what next I hear to ask ....

1RaTTuSEN7jJUDiW1EGogHwtek7g9BiEn
hugolp
Hero Member
*****
Offline Offline

Activity: 742



View Profile
June 13, 2011, 03:31:25 PM
 #419

try :-
./configure

I actually tried ./configure just for the sake of it and does nothing as expected. Autogen is failing.
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
June 13, 2011, 05:07:09 PM
 #420

Im getting this error in Ubuntu 10.04 LTS when running autogen.sh:

~/cpuminer$ sh autogen.sh
configure.ac:15: installing `./compile'
configure.ac:4: installing `./config.guess'
configure.ac:4: installing `./config.sub'
configure.ac:6: installing `./install-sh'
configure.ac:6: installing `./missing'
compat/jansson/Makefile.am: installing `./depcomp'
Makefile.am: installing `./INSTALL'
configure.ac:96: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Any suggestion?

Standard advice -- your autotools installation is old or broken.  Use release tarball.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
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 »
  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!