Just to share, the miner seems to work quite well under wine on OS X on a Mac Pro. Just install wine as per these instructions: http://wiki.winehq.org/MacOSX/Installing (I used Mac Ports) and you are good to go.
Topic: New demonstration CPU miner available - page 16. (Read 386323 times)
ymmv, but I found that -Os (optimize for size, better exploits caches) outperforms -O3 or -O4 by about 8%.
jordan
jordan
This may also be why ufasoft's code runs faster than the 4way implementation used here. Since he doesn't unroll the loop used in the SHA calculation, the code is smaller and may fit into the cache more easily. MEMORY HIERARCHIES: THAT $#%! IS SO CACHE.
ymmv, but I found that -Os (optimize for size, better exploits caches) outperforms -O3 or -O4 by about 8%.
update:
only bothered testing on 4way, but tested on 3 recent Intel processors, a Xeon W3530 @ 2.80GHz (8192 KB cache), a Xeon @ 3.00GHz (2048 KB cache), and a Xeon E5430 @ 2.66GHz (6144 KB cache). All with approximately the same results.
Using version obtained from git with most recent commit 4a7f3f70b5628cb804ca4f46cf51651a1a42507f.
gcc version Ubuntu 4.4.3-4ubuntu5, CFLAGS="-O(s|3) -ftree-vectorize -march=native".
jordan
update:
only bothered testing on 4way, but tested on 3 recent Intel processors, a Xeon W3530 @ 2.80GHz (8192 KB cache), a Xeon @ 3.00GHz (2048 KB cache), and a Xeon E5430 @ 2.66GHz (6144 KB cache). All with approximately the same results.
Using version obtained from git with most recent commit 4a7f3f70b5628cb804ca4f46cf51651a1a42507f.
gcc version Ubuntu 4.4.3-4ubuntu5, CFLAGS="-O(s|3) -ftree-vectorize -march=native".
jordan
Ahh. Just need to wait longer then?
Me and my impatient self. Thanks!
Me and my impatient self. Thanks!
To double program output to file, you can make something like that:
Code:
minerd --threads X --url http://mypool.local:8332 --userpass user:pass 2>&1 | tee /some/path/log.log
Ok, that puts "1 miner threads started, using SHA256 'cryptopp_asm32' algorithm." into the logfile, but fails to record (or display) the hashcount.
Progress, but still not 100%
Thanks for the fast response, btw.
I started minerd and got this:
Code:
hangover@hangover:~$ minerd --threads 2 --url http://mining.bitcoin.cz:8332 --userpass hangover.XX:YY 2>&1 | tee /home/hangover/loglog
2 miner threads started, using SHA256 'c' algorithm.
2 miner threads started, using SHA256 'c' algorithm.
And after waiting for 5 minutes I got this:
Code:
HashMeter(1): 16777215 hashes, 628.20 khash/sec
HashMeter(0): 16777215 hashes, 620.19 khash/sec
HashMeter(0): 8388607 hashes, 643.54 khash/sec
HashMeter(1): 8388607 hashes, 637.17 khash/sec
HashMeter(1): 4194303 hashes, 502.27 khash/sec
HashMeter(0): 4194303 hashes, 430.20 khash/sec
HashMeter(1): 3194303 hashes, 582.57 khash/sec
HashMeter(0): 3194303 hashes, 602.13 khash/sec
HashMeter(1): 3194303 hashes, 582.68 khash/sec
HashMeter(0): 3194303 hashes, 586.11 khash/sec
HashMeter(0): 3194303 hashes, 632.09 khash/sec
HashMeter(1): 3194303 hashes, 598.81 khash/sec
HashMeter(0): 3194303 hashes, 643.12 khash/sec
HashMeter(1): 3194303 hashes, 628.86 khash/sec
HashMeter(0): 3294303 hashes, 638.16 khash/sec
HashMeter(1): 3194303 hashes, 643.76 khash/sec
HashMeter(0): 3294303 hashes, 661.30 khash/sec
HashMeter(1): 3294303 hashes, 641.22 khash/sec
HashMeter(0): 3394303 hashes, 645.43 khash/sec
HashMeter(1): 3294303 hashes, 645.00 khash/sec
HashMeter(0): 3394303 hashes, 647.02 khash/sec
...
HashMeter(0): 16777215 hashes, 620.19 khash/sec
HashMeter(0): 8388607 hashes, 643.54 khash/sec
HashMeter(1): 8388607 hashes, 637.17 khash/sec
HashMeter(1): 4194303 hashes, 502.27 khash/sec
HashMeter(0): 4194303 hashes, 430.20 khash/sec
HashMeter(1): 3194303 hashes, 582.57 khash/sec
HashMeter(0): 3194303 hashes, 602.13 khash/sec
HashMeter(1): 3194303 hashes, 582.68 khash/sec
HashMeter(0): 3194303 hashes, 586.11 khash/sec
HashMeter(0): 3194303 hashes, 632.09 khash/sec
HashMeter(1): 3194303 hashes, 598.81 khash/sec
HashMeter(0): 3194303 hashes, 643.12 khash/sec
HashMeter(1): 3194303 hashes, 628.86 khash/sec
HashMeter(0): 3294303 hashes, 638.16 khash/sec
HashMeter(1): 3194303 hashes, 643.76 khash/sec
HashMeter(0): 3294303 hashes, 661.30 khash/sec
HashMeter(1): 3294303 hashes, 641.22 khash/sec
HashMeter(0): 3394303 hashes, 645.43 khash/sec
HashMeter(1): 3294303 hashes, 645.00 khash/sec
HashMeter(0): 3394303 hashes, 647.02 khash/sec
...
To double program output to file, you can make something like that:
Code:
minerd --threads X --url http://mypool.local:8332 --userpass user:pass 2>&1 | tee /some/path/log.log
Ok, that puts "1 miner threads started, using SHA256 'cryptopp_asm32' algorithm." into the logfile, but fails to record (or display) the hashcount.
Progress, but still not 100%
Thanks for the fast response, btw.
One more thing to ask: Is there a way to log the output? I tried the standard > redirect, but nothing is dumped into the text file, and nothing displays in the terminal screen, either.
Interestingly, the redirect works with the --help switch, and does fill the text file with the help output, and once I try redirecting the live program output, the text is blanked, but even with the >> append, nothing is ever put into the file. What am I doing wrong?
OS: Linux 10.04
Processor: Crap
GPU: Crap
Interestingly, the redirect works with the --help switch, and does fill the text file with the help output, and once I try redirecting the live program output, the text is blanked, but even with the >> append, nothing is ever put into the file. What am I doing wrong?
OS: Linux 10.04
Processor: Crap
GPU: Crap
To double program output to file, you can make something like that:
Code:
minerd --threads X --url http://mypool.local:8332 --userpass user:pass 2>&1 | tee /some/path/log.log
One more thing to ask: Is there a way to log the output? I tried the standard > redirect, but nothing is dumped into the text file, and nothing displays in the terminal screen, either.
Interestingly, the redirect works with the --help switch, and does fill the text file with the help output, and once I try redirecting the live program output, the text is blanked, but even with the >> append, nothing is ever put into the file. What am I doing wrong?
OS: Linux 10.04
Processor: Crap
GPU: Crap
Interestingly, the redirect works with the --help switch, and does fill the text file with the help output, and once I try redirecting the live program output, the text is blanked, but even with the >> append, nothing is ever put into the file. What am I doing wrong?
OS: Linux 10.04
Processor: Crap
GPU: Crap
Patch for successfull compilation of minerd under FreeBSD:
Code:
--- miner.h.orig 2011-02-10 11:51:55.000000000 +0600
+++ miner.h 2011-02-16 16:04:28.000000000 +0600
@@ -5,7 +5,7 @@
#include
#include
#include
-#include
+#include
#ifdef __SSE2__
#define WANT_SSE2_4WAY 1
@@ -18,7 +18,12 @@
#if ((__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3))
#define WANT_BUILTIN_BSWAP
#else
-#include
+/* #include */ // <-- doesn't exist under FreeBSD
+# define bswap_64 __bswap64
+# define bswap_32 __bswap32
+# define bswap_16 __bswap16
+# define __BIG_ENDIAN__ (_BYTE_ORDER == _BIG_ENDIAN)
+#include
#endif
#if defined(__i386__)
+++ miner.h 2011-02-16 16:04:28.000000000 +0600
@@ -5,7 +5,7 @@
#include
#include
#include
-#include
+#include
#ifdef __SSE2__
#define WANT_SSE2_4WAY 1
@@ -18,7 +18,12 @@
#if ((__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3))
#define WANT_BUILTIN_BSWAP
#else
-#include
+/* #include
+# define bswap_64 __bswap64
+# define bswap_32 __bswap32
+# define bswap_16 __bswap16
+# define __BIG_ENDIAN__ (_BYTE_ORDER == _BIG_ENDIAN)
+#include
#endif
#if defined(__i386__)
Quick question: is there a way to setup minerd to run as a linux screensaver? an extra thread while i'm not using the computer at all would be a nice way to boost my hash/sec.
I have the same thing. Trying to configure sources on FreeBSD 8.1-RELEASE-p2 i386.
Maybe, there are some linker flags or workarounds or something?
Maybe, there are some linker flags or workarounds or something?
The solution here is easy: don't build from git, build from tarball releases. The tarball already has the proper configure script generated, so you don't have to worry about missing macros or broken OS configurations.
Thank you very much!
Because:
Code:
$ ./configure
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
autogen could not find your libcurl autoconf macros. Sounds like you have a non-standard installation, outside the normal autoconf/automake paths.
I have the same thing. Trying to configure sources on FreeBSD 8.1-RELEASE-p2 i386.
Maybe, there are some linker flags or workarounds or something?
The solution here is easy: don't build from git, build from tarball releases. The tarball already has the proper configure script generated, so you don't have to worry about missing macros or broken OS configurations.
I want to suggest some improvements (possibly incorrect).
As I understand your sources. Now, each thread makes his getwork and processes it.
Why not parallelize the processing of one getwork a few threads? Like this: thread_1(nonce = 0 to N), thread_2(nonce = N to M), ..., thread_X(nonce = Y to Z).
This should reduce the load on the network and the loss in the processing of RPC request. (For the case when the block solution time > maximum admissible (skantime). But this is the most common case, no?)
As I understand your sources. Now, each thread makes his getwork and processes it.
Why not parallelize the processing of one getwork a few threads? Like this: thread_1(nonce = 0 to N), thread_2(nonce = N to M), ..., thread_X(nonce = Y to Z).
This should reduce the load on the network and the loss in the processing of RPC request. (For the case when the block solution time > maximum admissible (skantime). But this is the most common case, no?)
Yes, this is a good idea for the future. If someone wanted to contributed a clean implementation of this, I would accept it.
As it stands now, simply starting completely independent threads was easier to code. Breaking up the nonce work implies some level of coordination among threads, which must be done carefully to avoid hurting performance due to locks / asynchronous queues / similar threading details. One must also take care never to stall one thread, while it waits on other threads. This is not a hard problem... but it must be done right to avoid these pitfalls.
Quote
The following improvements (for the distant future) - Miner parallelization on multiple hosts with the aid of a binary (for fast) protocol supports pooling, an indication of nonse range and calibrate the performance of customers (to determine the nonce range). In practice, this task of building a new server pool with their customers. It is interesting to you?
Pooling already exists. See this thread, or see this thread for a binary pool protocol.
Hello Jgarzik.
Thanks for the good miner.
I want to suggest some improvements (possibly incorrect).
As I understand your sources. Now, each thread makes his getwork and processes it.
Why not parallelize the processing of one getwork a few threads? Like this: thread_1(nonce = 0 to N), thread_2(nonce = N to M), ..., thread_X(nonce = Y to Z).
This should reduce the load on the network and the loss in the processing of RPC request. (For the case when the block solution time > maximum admissible (skantime). But this is the most common case, no?)
The following improvements (for the distant future) - Miner parallelization on multiple hosts with the aid of a binary (for fast) protocol supports pooling, an indication of nonse range and calibrate the performance of customers (to determine the nonce range). In practice, this task of building a new server pool with their customers. It is interesting to you?
P.S.
This is somewhat similar to the processing of one getwork on SSE2 processors that are discussed in the next thread.
Thanks for the good miner.
I want to suggest some improvements (possibly incorrect).
As I understand your sources. Now, each thread makes his getwork and processes it.
Why not parallelize the processing of one getwork a few threads? Like this: thread_1(nonce = 0 to N), thread_2(nonce = N to M), ..., thread_X(nonce = Y to Z).
This should reduce the load on the network and the loss in the processing of RPC request. (For the case when the block solution time > maximum admissible (skantime). But this is the most common case, no?)
The following improvements (for the distant future) - Miner parallelization on multiple hosts with the aid of a binary (for fast) protocol supports pooling, an indication of nonse range and calibrate the performance of customers (to determine the nonce range). In practice, this task of building a new server pool with their customers. It is interesting to you?
P.S.
This is somewhat similar to the processing of one getwork on SSE2 processors that are discussed in the next thread.
Because:
Code:
$ ./configure
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
autogen could not find your libcurl autoconf macros. Sounds like you have a non-standard installation, outside the normal autoconf/automake paths.
I have the same thing. Trying to configure sources on FreeBSD 8.1-RELEASE-p2 i386.
Maybe, there are some linker flags or workarounds or something?
For @jgarzik, would you accept pull requests as a way to share patches (via github) the way you want to manage patches? I'm looking at adding a benchmark code to automagically select a core, and *cough* eying how to get the best performance out of this TI DM3730...wonder how fast the DSP really is as a "second core", and porting to NEON.
github pull request, emailed pull request (Linux kernel-style) or a posted patch are all welcomed. It's a small project
I've been looking at the code, and my collection of ARM boxes...
For @jgarzik, would you accept pull requests as a way to share patches (via github) the way you want to manage patches? I'm looking at adding a benchmark code to automagically select a core, and *cough* eying how to get the best performance out of this TI DM3730...wonder how fast the DSP really is as a "second core", and porting to NEON.
For @jgarzik, would you accept pull requests as a way to share patches (via github) the way you want to manage patches? I'm looking at adding a benchmark code to automagically select a core, and *cough* eying how to get the best performance out of this TI DM3730...wonder how fast the DSP really is as a "second core", and porting to NEON.
Because:
Code:
$ ./configure
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
autogen could not find your libcurl autoconf macros. Sounds like you have a non-standard installation, outside the normal autoconf/automake paths.
Yeah, I'm probably crying wolf a bit. My development environment is highly customized, both for work requirements and laziness factors. I'll work my way around these issues myself, sorry for the inconvenience
Because:
Code:
$ ./configure
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
[...]
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
autogen could not find your libcurl autoconf macros. Sounds like you have a non-standard installation, outside the normal autoconf/automake paths.
Tried this on osx 10.6, using gcc 4.2.1, which does not have the builtin byte swap, apparently:
But the current master HEAD (6d2882937f8b2a5291ae68ae9ea985ad5271d0fb) does not have this byteswap.h file.
Code:
#if ((__GNUC__ > 4) || (__GNUC__ == 4 && __GNUC_MINOR__ >= 3))
#define WANT_BUILTIN_BSWAP
#else
#include
#endif
#define WANT_BUILTIN_BSWAP
#else
#include
#endif
But the current master HEAD (6d2882937f8b2a5291ae68ae9ea985ad5271d0fb) does not have this byteswap.h file.
byteswap.h is provided by your OS. cpuminer will probably need a few minor patches before building on osx. Patches welcome!
Right, I'll find where that is on my OS and why it isn't picked up using the default paths then.
Quote
Quote
Also, using ./autogen.h left me with a weird check for libcurl in configure:
Code:
LIBCURL_CHECK_CONFIG(, 7.10.1, ,
AC_MSG_ERROR([Missing required libcurl >= 7.10.1]))
AC_MSG_ERROR([Missing required libcurl >= 7.10.1]))
Why is that weird? That's the standard CURL autotools macro invocation.
Because:
Code:
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking whether gcc needs -traditional... no
checking whether gcc and cc understand -c and -o together... yes
checking for ranlib... ranlib
checking for ANSI C header files... yes
checking for json_loads in -ljansson... no
checking for pthread_create in -lpthread... yes
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking whether gcc needs -traditional... no
checking whether gcc and cc understand -c and -o together... yes
checking for ranlib... ranlib
checking for ANSI C header files... yes
checking for json_loads in -ljansson... no
checking for pthread_create in -lpthread... yes
checking for pkg-config... /opt/local/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
./configure: line 4301: syntax error near unexpected token `,'
./configure: line 4301: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
Jump to: