Thanks for testing. Here's another test, integrating the 4way algorithm and removing the others:
http://yyz.us/bitcoin/cpuminer-installer-0.2.2test-4way-only.zip
Unlikely to change anything, but it seems that we are narrowing this down to gcc 4.4 -> gcc 4.5 changes in Fedora 13 -> 14.
Topic: New demonstration CPU miner available - page 24. (Read 386323 times)
Phenom II X3 720 2.8GHz XP x64
--algo=4way --threads=1
0.2.2test-o2 = 1450
0.2.2test-o2-pentium4 = 1438
0.2.2test-o2-k8 = 1450
0.2.2test-o3 = 1450
0.2.2test-o3-pentium4 = 1438
0.2.2test-o3-k8 = 1450
0.2.1 = 2418.34 interesting on this one is, that it's not fluctuating,
all others go up and down by 1-few khash, 0.2.1 isnt, it's rockstable at 2418.34,
except the CPU is doing some other stuff, then it drops a bit too.
--algo=4way --threads=1
0.2.2test-o2 = 1450
0.2.2test-o2-pentium4 = 1438
0.2.2test-o2-k8 = 1450
0.2.2test-o3 = 1450
0.2.2test-o3-pentium4 = 1438
0.2.2test-o3-k8 = 1450
0.2.1 = 2418.34 interesting on this one is, that it's not fluctuating,
all others go up and down by 1-few khash, 0.2.1 isnt, it's rockstable at 2418.34,
except the CPU is doing some other stuff, then it drops a bit too.
cryptopp_asm32 = 1350khash/s
This is faster than standard bitcoin client, yes?
Anyway, how much patience do you have for testing?
Other readers.. your help in comparing 0.2 versus 0.2.2test* speed is welcomed. Here is a matrix of options, to see if 4way can be improved:| Compiler flags | URL |
| -O2 -msse2 | http://yyz.us/bitcoin/cpuminer-installer-0.2.2test-o2.zip |
| -O2 -march=pentium4 -msse2 | http://yyz.us/bitcoin/cpuminer-installer-0.2.2test-o2-pentium4.zip |
| -O2 -march=k8 | http://yyz.us/bitcoin/cpuminer-installer-0.2.2test-o2-k8.zip |
| -O3 -msse2 | http://yyz.us/bitcoin/cpuminer-installer-0.2.2test-o3.zip |
| -O3 -march=pentium4 -msse2 | http://yyz.us/bitcoin/cpuminer-installer-0.2.2test-o3-pentium4.zip |
| -O3 -march=k8 | http://yyz.us/bitcoin/cpuminer-installer-0.2.2test-o3-k8.zip |
Quote
Did you test 'cryptopp_asm32' algorithm?
sorry, the slow 4way-algo confused me a bit, so i totally missed to post those,
yes i did.
cryptopp = 890khash/s
cryptopp_asm32 = 1350khash/s
Quote
I'm interested if this works at all.
it does, installs and runs nice as usual,Did you test 'cryptopp_asm32' algorithm?
Quote
so, with 0.2.1 '4way' i get 2400,
0.2.2-0.2.2test '4way' i get 1440.
0.2.2-0.2.2test '4way' i get 1440.
hmmm. On my side, I upgraded Fedora 13 to Fedora 14, and changed -O2 to -O3 in compile flags. Gotta wonder what changed
I should also look into a better CPU architecture setting than the default.
Quote
I'm interested if this works at all.
it does, installs and runs nice as usual,on my PhenomII X3 it's
slightly faster using 'c' 1070khash/s (+50)
but slower using '4way' 1440khash/s (-960), which is also the case in version 0.2.2, haven't tested that one before.
so, with 0.2.1 '4way' i get 2400,
0.2.2-0.2.2test '4way' i get 1440.
you broke it.
and yes, it's all single threads.
A test version of cpuminer, with crypto++ 32-bit assembly implementation, has been pushed out to git, and a test installer for Windows uploaded at http://yyz.us/bitcoin/cpuminer-installer-0.2.2test.zip
SHA1: c105454954b63c4f846ced958b553c87182b88e5 cpuminer-installer-0.2.2test.zip
MD5: ce5fd9d17167080892b8d9c06f582660 cpuminer-installer-0.2.2test.zip
I'm interested if this works at all. Should be faster for Windows users than the current Crypto++ implementation, I'm guessing.
SHA1: c105454954b63c4f846ced958b553c87182b88e5 cpuminer-installer-0.2.2test.zip
MD5: ce5fd9d17167080892b8d9c06f582660 cpuminer-installer-0.2.2test.zip
I'm interested if this works at all. Should be faster for Windows users than the current Crypto++ implementation, I'm guessing.
note if you wanted to do a full difficulty test rather than returning the preliminary "proof of work" to the server, its not hard, I think this would work:
Code:
/* do full difficulty test of hash */
#define OFF 75
int fulltest(void * block, void *hash)
{
unsigned char *blk = block; // 80 bytes
unsigned char *hsh = hash; // 32 bytes
int i;
int shift = blk[OFF] - 2;
for (i = 31; i > shift && i >= 0; i--)
if (hsh[i] != 0)
return 0;
if (shift < 32)
for (i = 0; i < 3 && shift >= i; i++) {
if (hsh[shift - i] > blk[OFF - 1 - i])
return 0;
if (hsh[shift - i] < blk[OFF - 1 - i])
return 1;
}
return 1;
}
#define OFF 75
int fulltest(void * block, void *hash)
{
unsigned char *blk = block; // 80 bytes
unsigned char *hsh = hash; // 32 bytes
int i;
int shift = blk[OFF] - 2;
for (i = 31; i > shift && i >= 0; i--)
if (hsh[i] != 0)
return 0;
if (shift < 32)
for (i = 0; i < 3 && shift >= i; i++) {
if (hsh[shift - i] > blk[OFF - 1 - i])
return 0;
if (hsh[shift - i] < blk[OFF - 1 - i])
return 1;
}
return 1;
}
Version 0.2.2 released:
- VIA padlock works (lfm)
- minor bug fixes (lfm)
SHA1: b7ffda89f3b76302b948a715905105b4cf0c080f cpuminer-installer-0.2.2.zip
MD5: 716f883b92e93082e2dfa9a3130972cb cpuminer-installer-0.2.2.zip
See top of thread for URLs.
- VIA padlock works (lfm)
- minor bug fixes (lfm)
SHA1: b7ffda89f3b76302b948a715905105b4cf0c080f cpuminer-installer-0.2.2.zip
MD5: 716f883b92e93082e2dfa9a3130972cb cpuminer-installer-0.2.2.zip
See top of thread for URLs.
Fantastic work. Are you able to get the 4way algorithm into the main client? It performs twice as well as the main client's algorithm on intel hardware, and seems to be working terrific on the AMD hardware.
4way is in the main client already -- albeit Linux-only, if I understand correctly. That's an open project for someone to tackle, if they're interested.
Fantastic work. Are you able to get the 4way algorithm into the main client? It performs twice as well as the main client's algorithm on intel hardware, and seems to be working terrific on the AMD hardware.
I wonder what this might mean:
Any ideas?
Quote
checking for json_loads in -ljansson... no
checking for pthread_create in -lpthread... yes
./configure: line 4305: syntax error near unexpected token `LIBCURL_CHECK_CONFIG'
./configure: line 4305: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
checking for pthread_create in -lpthread... yes
./configure: line 4305: syntax error near unexpected token `LIBCURL_CHECK_CONFIG'
./configure: line 4305: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
Any ideas?
autogen.sh did not find the necessary libcurl autoconf magic to build your configure script. Thus, instead of transforming the macro LIBCURL_CHECK_CONFIG into something useful, it left it as-is.
So, your libcurl install is missing some pieces (or autogen.sh cannot find them).
I wonder what this might mean:
Any ideas?
Quote
checking for json_loads in -ljansson... no
checking for pthread_create in -lpthread... yes
./configure: line 4305: syntax error near unexpected token `LIBCURL_CHECK_CONFIG'
./configure: line 4305: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
checking for pthread_create in -lpthread... yes
./configure: line 4305: syntax error near unexpected token `LIBCURL_CHECK_CONFIG'
./configure: line 4305: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,'
Any ideas?
Just pushed out v0.2.1 to cpuminer.git, and updated the Windows installer:
http://yyz.us/bitcoin/cpuminer-installer-0.2.1.zip
SHA1: d85390e1bb4da94b84f0968d0c98590f4be22f39 cpuminer-installer-0.2.1.zip
MD5: 02bcd0b22fa62499e96244ebd86efcd5 cpuminer-installer-0.2.1.zip
Windows users should see a slight increase in khash/sec, due to improved optimization.
http://yyz.us/bitcoin/cpuminer-installer-0.2.1.zip
SHA1: d85390e1bb4da94b84f0968d0c98590f4be22f39 cpuminer-installer-0.2.1.zip
MD5: 02bcd0b22fa62499e96244ebd86efcd5 cpuminer-installer-0.2.1.zip
Windows users should see a slight increase in khash/sec, due to improved optimization.
This has happened to me every time a hash with zeros is found on my 64-bit Atom system:
Fixed in git commit 145e5fe141857c0757fdb5bb6909583aa67691b1, just pushed to cpuminer.git.
This has happened to me every time a hash with zeros is found on my 64-bit Atom system:
I mentioned the problems with -march=atom CFLAGS previously, but this does not go away when changing the -march.
Code:
DBG: found zeroes in hash:
d624b64665519a6e0c74eeca4e00a5be937086db86f106b0ed6e759400000000
HashMeter(2): 8150287 hashes, 123.22 khash/sec
PROOF OF WORK FOUND? submitting...
*** buffer overflow detected ***: ./minerd terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f6a2387f847]
/lib/libc.so.6(+0xe56c0)[0x7f6a2387d6c0]
/lib/libc.so.6(+0xe4a39)[0x7f6a2387ca39]
/lib/libc.so.6(_IO_default_xsputn+0x81)[0x7f6a23809651]
/lib/libc.so.6(_IO_vfprintf+0x3f6f)[0x7f6a237ddbef]
/lib/libc.so.6(__vsprintf_chk+0x9d)[0x7f6a2387cadd]
/lib/libc.so.6(__sprintf_chk+0x7f)[0x7f6a2387ca1f]
./minerd[0x401958]
/lib/libpthread.so.0(+0x6c1a)[0x7f6a23b04c1a]
/lib/libc.so.6(clone+0x6d)[0x7f6a2386992d]
d624b64665519a6e0c74eeca4e00a5be937086db86f106b0ed6e759400000000
HashMeter(2): 8150287 hashes, 123.22 khash/sec
PROOF OF WORK FOUND? submitting...
*** buffer overflow detected ***: ./minerd terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f6a2387f847]
/lib/libc.so.6(+0xe56c0)[0x7f6a2387d6c0]
/lib/libc.so.6(+0xe4a39)[0x7f6a2387ca39]
/lib/libc.so.6(_IO_default_xsputn+0x81)[0x7f6a23809651]
/lib/libc.so.6(_IO_vfprintf+0x3f6f)[0x7f6a237ddbef]
/lib/libc.so.6(__vsprintf_chk+0x9d)[0x7f6a2387cadd]
/lib/libc.so.6(__sprintf_chk+0x7f)[0x7f6a2387ca1f]
./minerd[0x401958]
/lib/libpthread.so.0(+0x6c1a)[0x7f6a23b04c1a]
/lib/libc.so.6(clone+0x6d)[0x7f6a2386992d]
I mentioned the problems with -march=atom CFLAGS previously, but this does not go away when changing the -march.
I think miners should retry connection every now and then if the master is not available, so you don't have to care if it is temporary down (i.e. while updating).
'getwork' miners (such as mine) already do this. The basic algorithm looks like this:
- 1. Connect to bitcoin via TCP, obtain work
- 2. Work on work (no TCP connection required, needed, or used)
- 3. If solution found, connect to bitcoin via TCP and submit solution
- 4. Go to step #1.
If bitcoin is down when a solution is found, presumably the solution will be invalid by the time bitcoin comes back up, so the "retry" with solution seems less than useful. A "retry" is really just going back to obtain more work (step #1).
I think miners should retry connection every now and then if the master is not available, so you don't have to care if it is temporary down (i.e. while updating).
Just added the Crypto++ implementation of SHA256 to cpuminer.git. C only, though I would eventually like to add asm for 32-bit.
sha.cpp, converted to C, seems slower than cpuminer's current "c" algorithm.
sha.cpp, converted to C, seems slower than cpuminer's current "c" algorithm.
Platform: 64 bit Linux.
Strange. I wouldn't have thought the mainline implementation would be that much faster on 64-bit.
Quote
It might be better to catch the KILL SIGNAL complete the current work and even catch this unlikely case. OTOH, it might not be worth the effort, since the change of creating one is so small...
At some point you have to surrender to the fact that killing the miner means possibly missing a solution that would have been found, if you only gave it another microsecond to run...
Jump to: