Bitcoin Forum
December 05, 2016, 10:52:43 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3] 4 5 »  All
  Print  
Author Topic: 4 hashes parallel on SSE2 CPUs for 0.3.6  (Read 10948 times)
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
August 03, 2010, 02:04:22 AM
 #41

SHA256 test started
70293
found solutions = 70293
total hashes = 139463136
total time = 222110 ms
average speed: 627 khash/s

So slightly better, but still far for good... As for AMD vs Intel, on my Mac, which is an intel i5, the performance boost was almost 100%, so maybe some compiler thing? I did have to remove the -arch i386 from makefile.osx to have it build on osx 10.6, but there's no such flag on linux' g++ and I'm pretty sure the 64bit g++ will not compile 32bit anyway.
1480935163
Hero Member
*
Offline Offline

Posts: 1480935163

View Profile Personal Message (Offline)

Ignore
1480935163
Reply with quote  #2

1480935163
Report to moderator
1480935163
Hero Member
*
Offline Offline

Posts: 1480935163

View Profile Personal Message (Offline)

Ignore
1480935163
Reply with quote  #2

1480935163
Report to moderator
1480935163
Hero Member
*
Offline Offline

Posts: 1480935163

View Profile Personal Message (Offline)

Ignore
1480935163
Reply with quote  #2

1480935163
Report to moderator
"Your bitcoin is secured in a way that is physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter a majority of miners, no matter what." -- gmaxwell
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480935163
Hero Member
*
Offline Offline

Posts: 1480935163

View Profile Personal Message (Offline)

Ignore
1480935163
Reply with quote  #2

1480935163
Report to moderator
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 03, 2010, 02:21:50 AM
 #42

i5 is a different architecture than Core2. Maybe SSE in Core2 is broken and was fixed in i5. That means the original client is close to the fastest you can get on Core2. It's not a compiler thing. I compared the output for different architectures and -march=amdfam10 produces the fastest and smallest code. I would be surprised if a longer loop using the same instructions was faster on an older CPU.
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
August 03, 2010, 02:23:48 AM
 #43

Well, kudos to you for trying. Now if I can just get your code merged with the old cuda version on my macbook pro, I'll be a happy camper Smiley
vess
Full Member
***
Offline Offline

Activity: 141



View Profile WWW
August 03, 2010, 08:36:04 PM
 #44

Anyone able to send me a compiled version of this for windows? I'm interested to try it out on my AMD server.

I'm the CEO of CoinLab (www.coinlab.com) and the Executive Director of the Bitcoin Foundation, I will identify if I'm speaking for myself or one of the organizations when I post from this account.
impossible7
Newbie
*
Offline Offline

Activity: 18


View Profile
August 03, 2010, 09:49:12 PM
 #45

I kept running the patched version on 2 machines and the following has happened 5 times: bitcoind crashes and debug.log contains the following:

Code:
proof-of-work found
  hash: 00000000001c3530e42b2c7e1a20de01436882d0c1de0b63db6be8e6194255dd
target: 00000000010c5a00000000000000000000000000000000000000000000000000
CBlock(hash=00000000001c3530, ver=1, hashPrevBlock=0000000000253ab5, hashMerkleRoot=89541f, nTime=1280867359, nBits=1c010c5a, nNonce=3915571979, vtx=2)
  CTransaction(hash=4fcb8e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(000000, -1), coinbase 045a0c011c021b04)
    CTxOut(nValue=50.00000000, scriptPubKey=0xCE5264238BAC29160CDC9C)
  CTransaction(hash=8f2466, ver=1, vin.size=1, vout.size=1, nLockTime=0)
    CTxIn(COutPoint(77aaae, 1), scriptSig=0x01F561A9044BF348CEF6F4)
    CTxOut(nValue=5.00000000, scriptPubKey=OP_DUP OP_HASH160 0xB13A)
  vMerkleTree: 4fcb8e 8f2466 89541f
08/03/10 20:29 generated 50.00
AddToWallet 4fcb8e  new
AddToBlockIndex: new best=00000000001c3530  height=72112
ProcessBlock: ACCEPTED
sending: inv

I guess this means that a new block has been generated. But when I restart bitcoind the balance is still zero. When I ask for a list of generated blocks I get the following:

Code:
$ ./bitcoind listgenerated
[
    {
        "value" : 50.00000000000000,
        "maturesIn" : -1,
        "accepted" : false,
        "confirmations" : 0,
        "genTime" : 1280867359
    }
]
(listgenerated is from the patch at http://www.alloscomp.com/bitcoin/)

I guess this means that my client produced a block but it crashed before it was able to broadcast it.
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 03, 2010, 09:53:54 PM
 #46

did you run it on 32 bit machines? which version of the patch did you use?
impossible7
Newbie
*
Offline Offline

Activity: 18


View Profile
August 03, 2010, 09:56:47 PM
 #47

r121 from the svn patched with the patch from the post #21 running on a Opteron/x86_64
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 03, 2010, 10:00:35 PM
 #48

did it crash with a segfault and can you provide a backtrace (gdb bitcoind; run; bt)?
impossible7
Newbie
*
Offline Offline

Activity: 18


View Profile
August 03, 2010, 11:51:28 PM
 #49

I did segfault according to dmesg:

Code:
bitcoind[2469]: segfault at 0 ip 00007fe92c5b3f32 sp 00007fff15e5f6b0 error 4 in libc-2.11.2.so[7fe92c57e000+150000]

I don't have a stack trace.
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 04, 2010, 12:03:07 AM
 #50

Did your kernel write a coredump and if so can you mail me the binary + coredump to tcatm@gawab.com?
impossible7
Newbie
*
Offline Offline

Activity: 18


View Profile
August 04, 2010, 02:52:17 AM
 #51

I modified bitcoind so that it doen't fork to the background and now I can debug it with gdb. Next time it crashes gdb will give me a backtrace.
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 04, 2010, 03:00:49 AM
 #52

GDB can also generate coredumps with the command generate-core-file. It might be useful to reconstruct the cause for the segfault. Please note, that the coredump might include your wallet so it's probably a good idea to run bitcoind on a seperate datadir.
vess
Full Member
***
Offline Offline

Activity: 141



View Profile WWW
August 04, 2010, 01:34:44 PM
 #53

Just a comment that this would be easier to test if difficulty were set to '1' in the client.

I'm the CEO of CoinLab (www.coinlab.com) and the Executive Director of the Bitcoin Foundation, I will identify if I'm speaking for myself or one of the organizations when I post from this account.
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 04, 2010, 01:43:26 PM
 #54

Oh thats easy: Get two nodes on a seperate network and connect them using -connect=other_nodes_ip and a seperate/empty datadir.
impossible7
Newbie
*
Offline Offline

Activity: 18


View Profile
August 05, 2010, 06:40:16 AM
 #55

I had 5 machines running today and when I checked back 10 hours later, 4 of them had crashed, in the same way as with the previous times (i.e. right after they had generated a new block but before they broadcasted it).

I created a tarball containing the coredump, backtrace, binary and the sources I used to compile it including the compiled object files. You can get it from here (link removed). Hope that helps.

EDIT: Ok, I just noticed that both your patch and the patch for the getkhps rpc (from http://www.alloscomp.com/bitcoin/) modify the function BitcoinMiner in main.cpp (which is where the segfault occurs) so this must be the reason for the seqfaults. I will try to test it without the getkhps patch.
impossible7
Newbie
*
Offline Offline

Activity: 18


View Profile
August 05, 2010, 01:35:50 PM
 #56

Ok I tried again, this time with no extra patches. I just cloned your git tree and compiled it. It still crashes. Here's the stack backtrace:
Code:
#0  0x00007ffff710b1b5 in raise () from /lib/libc.so.6
#1  0x00007ffff710c5e0 in abort () from /lib/libc.so.6
#2  0x00007ffff71042d1 in __assert_fail () from /lib/libc.so.6
#3  0x00000000004628de in BitcoinMiner () at main.cpp:2741
#4  0x0000000000462d70 in ThreadBitcoinMiner (parg=0x391e) at main.cpp:2518
#5  0x00007ffff6ec3894 in start_thread () from /lib/libpthread.so.0
#6  0x00007ffff71aa07d in clone () from /lib/libc.so.6
I have also uploaded here (link removed) the sources with the object files as well as the a core dump and the binary.
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 05, 2010, 02:06:14 PM
 #57

That's not a real crash this time. It's an assert that fails in the miner. Most likely assert(hash == pblock->GetHash());. Can you run the test programm (explained in http://bitcointalk.org/index.php?topic=648.msg7096#msg7096)? If it fails, can you change -march=amdfam10 back to -march=native in makefile.unix, rm cryptopp/obj/*.o and recompile everything? What cpu are you running it on?
impossible7
Newbie
*
Offline Offline

Activity: 18


View Profile
August 06, 2010, 02:49:32 AM
 #58

The test program does not fail
Code:
$ ./test ../blocks.txt
SHA256 test started
70293
found solutions = 70293
total hashes = 139463136
total time = 63250 ms
average speed: 2204 khash/s
Does the test program run on a single thread?

Finally, I have the same problem with both -march=amdfam10 and -march=native. The cpu is a Opteron 2374.
tcatm
Sr. Member
****
qt
Offline Offline

Activity: 337


View Profile
August 06, 2010, 03:38:53 AM
 #59

Yes, test is single threaded. Is there any output on stderr? From the coredumps I can tell that there must be some output.

The problem seems to be hard to debug, though. Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.
knightmb
Sr. Member
****
Offline Offline

Activity: 308


Timekoin - Save Electricity, Don't Waste It!


View Profile WWW
August 06, 2010, 06:50:03 AM
 #60

<snip> Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.
When the difficulty changed, the first machine in my group to generate a block was the slowest one running the stock client (800 MHz E-machine) and it hadn't generated anything in over a week itself. So I guess every little bit helps, that's so many are interested in getting this to work on their machine.

Pages: « 1 2 [3] 4 5 »  All
  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!