New demonstration CPU miner available - page 25.

farmer_boy

newbie

Activity: 56

Merit: 0

Quote from: jgarzik on November 28, 2010, 03:07:15 PM

Quote from: farmer_boy on November 28, 2010, 02:27:11 PM

The 4way implementation is slower on my IntelCore2Duo. The 'c' implementation is about 20% slower than the one in mainline.

What platform? And, is it 32-bit or 64-bit?

I'm guessing my miner will be slower than mainline on 32-bit, because Crypto++ has a SHA256 32-bit assembly implementation, and I think mainline uses that on 32-bit platforms.

Quote

What exactly happens when I send the KILL signal to the program? Is there any chance that bitcoins are lost for example? The same question applies to all miner programs.

Miners submit work immediately, via HTTP JSON-RPC, as soon as they find a possible solution. You'll only lose bitcoins if you KILL in a rare situation where you found a solution and it has not yet submitted.

Platform: 64 bit Linux. 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 chance of creating one is so small...

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: farmer_boy on November 28, 2010, 02:27:11 PM

The 4way implementation is slower on my IntelCore2Duo. The 'c' implementation is about 20% slower than the one in mainline.

What platform? And, is it 32-bit or 64-bit?

I'm guessing my miner will be slower than mainline on 32-bit, because Crypto++ has a SHA256 32-bit assembly implementation, and I think mainline uses that on 32-bit platforms.

Quote

What exactly happens when I send the KILL signal to the program? Is there any chance that bitcoins are lost for example? The same question applies to all miner programs.

Miners submit work immediately, via HTTP JSON-RPC, as soon as they find a possible solution. You'll only lose bitcoins if you KILL in a tiny window of opportunity where you found a solution and it has not yet submitted.

farmer_boy

newbie

Activity: 56

Merit: 0

The 4way implementation is slower on my IntelCore2Duo. The 'c' implementation is about 20% slower than the one in mainline. Still, I understood from the announcement that it was not actually the intention to go faster, but simply to show how to write one. In terms of work required to get this miner to work, it is the best miner sofar. It compiled out of the "box" (git).

I would consider this experiment to be a complete success.

What exactly happens when I send the KILL signal to the program? Is there any chance that bitcoins are lost for example? The same question applies to all miner programs.

BitLex

hero member

Activity: 532

Merit: 505

Quote

Surely your bitcoin client is running multiple threads, to achieve 3800 khash/s, yes?

yes of course, it's 3800 running unlimited (=on all cores) on the AMD X3 bitcoin client,
thats a bit faster than your miner at default c=3x1020= 3060khash/s,
but only about half of what yours does at 4way=3x2400= 7200khash/s.
impressive!

on the older X2 the math goes
bitcoin client= 2000khash/s
jgarzik c=2x860= 1720khash/s
jgarzik 4way=2x1060= 2120khash/s
not that much, but still noticable.

and here's another one
Intel(R) Atom N270 @1600MHz (singlecore pretending to be 2) WinXP 32

bitcoin-client= 420khash/s (330 "limited to 1 core")

jgarzik's miner=
threads=1 c= 220khash/s
threads=2 c=2x164= 328khash/s

4way just slows it down to 196 on a single and 2x140 on 2threads.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: BitLex on November 27, 2010, 06:08:15 AM

AMD X3 720 @2.8GHz winXPx64
c=1020khash/s -> 4way=2400khash/s

default client-miner gets ~3800khash/s on this machine

AMD X2 BE-2350 @2.36GHz win7x64
c=860khash/s -> 4way=1060khash/s

default client-miner gets ~2000khash/s here, still a little improvement, but far from the one above.

It is strange that the default client-miner is so much faster for you. Surely your bitcoin client is running multiple threads, to achieve 3800 khash/s, yes?

Thanks for reporting results! cpuminer v0.2's hashmeter should be accurate. Note that cpuminer prints out speed for each thread, not a total for all threads:

Code:

[jgarzik@bd cpuminer]$ ./minerd -t2 -a4way
2 miner threads started, using SHA256 '4way' algorithm.
HashMeter(0): 16777216 hashes, 1828.44 khash/sec
HashMeter(1): 16777216 hashes, 1832.77 khash/sec

"HashMeter(0)" is thread #0. "HashMeter(1)" is thread #1.

Therefore, I am getting 3660 khash/sec in total.

teknohog

sr. member

Activity: 520

Merit: 253

555

Quote from: jgarzik on November 26, 2010, 04:45:54 PM

EDIT: If you lack jansson, current cpuminer.git will build an in-tree version. Thus, you may opt to fix the problem by... removing jansson from your system.

Cheers, this is now faster than mainline on an Atom D510

While a GPU miner is hogging one core, mainline gives about 305 khash/s, and cpuminer gives about 480. Both of these are using several threads for HT, which actually makes a huge difference.

One reason may be that the mainline client segfaults with -march=atom (gcc 4.5.1), but for cpuminer it works fine. Since the Atom has an in-order architecture, this again makes a big difference.

BitLex

hero member

Activity: 532

Merit: 505

some more tests with v0.2

AMD X3 720 @2.8GHz winXPx64
threads=1
c=1020khash/s -> 4way=2400khash/s

default client-miner gets ~3800khash/s on this machine, so if your HashMeter is a bit less wildly inaccurate now, 4way runs almost twice as fast.

AMD X2 BE-2350 @2.36GHz win7x64
therads=1
c=860khash/s -> 4way=1060khash/s

default client-miner gets ~2000khash/s here, still a little improvement, but far from the one above.

jgarzik

legendary

Activity: 1596

Merit: 1100

Curious users may find the following patch useful for observing bitcoin miner proof-of-work results. Current miners seem to work like this:

Increment nonce in block header
Double-SHA256 hash the block header
If some number of high bits are zero, stop hashing, and perform an exhaustive proof-of-work validation check: Decompose the sha256 hash result into a 256-bit integer, and compare that integer with the target.
Otherwise, loop back to step #1.

The net result is that it is entirely normal to stop hashing, perform proof-of-work validation, and fail.

The following simple patch will log such failures to the debug log. Again, it is normal to see these sorts of events pop up occasionally.

Code:

diff --git a/main.cpp b/main.cpp
index acfcbc9..1c5ca69 100644
--- a/main.cpp
+++ b/main.cpp
@@ -3273,8 +3273,11 @@ bool CheckWork(CBlock* pblock, CReserveKey& reservekey)
uint256 hash = pblock->GetHash();
uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();

- if (hash > hashTarget)
+ if (hash > hashTarget) {
+ printf("proof-of-work check FAILED...\n hash: %s\n target: %s\n"
+ hash.GetHex().c_str(), hashTarget.GetHex().c_str());
return false;
+ }

//// debug print
printf("BitcoinMiner:\n");

jgarzik

legendary

Activity: 1596

Merit: 1100

Ok, I think I've fixed 4way. The 4way scanhash was only patching the base nonce into the data block, rather than the nonce successfully found using the vector SSE2 code. The code now seems to be successfully finding hashes with a large amount of zero bits.

Version 0.2 has been pushed out to git repo, and Windows installer has been updated. See top of thread for updated URLs. See NEWS file or git repo for full list of changes.

SHA1: 61809a3f09363ab9d83e7b727909e70d2e1a3f8c cpuminer-installer-0.2.zip
MD5: bdcf1b956688f46cd8591656887cb3a6 cpuminer-installer-0.2.zip

Edit: just generated a testnet block w/ 4way. Looks like it's working.

jgarzik

legendary

Activity: 1596

Merit: 1100

Added VIA padlock support, in git.

Completely untested -- I don't have the hardware.

jgarzik

legendary

Activity: 1596

Merit: 1100

Updated the git repo (Linux) and http://yyz.us/bitcoin/cpuminer-installer.zip (Windows) to fix hash meter problems.

Size: 1858209
SHA1: c9c2695b7f6708956dfe9b06e02a28fdc0cf46c9
MD5: 144e2c7d61d739a267bb623122e103e7

Quote from: BitLex on November 26, 2010, 08:28:24 PM

--algo=4way pretends to work, burns CPU and stuff, but only shows 0.00khash/s all time and some PROOF...false msgs, so i think it doesn't.

I fixed the 0.00 khash/s problem, but it looks like the algorithm might be returning incorrect hashes. I marked it "EXPERIMENTAL" in --help for now.

BitLex

hero member

Activity: 532

Merit: 505

--threads scales nicely with cores, unfortunately it drags GPU-miners down (a lot) when running on all cores,
but i guess most GPU miners won't care about one CPU more or less anyway. Grin

--algo=4way pretends to work, burns CPU and stuff, but only shows 0.00khash/s all time and some PROOF...false msgs, so i think it doesn't.

--url works just fine, all my (non-client) miners are connected to a single node

tested on 64bit XP & 7

jgarzik

legendary

Activity: 1596

Merit: 1100

Note that the khash/sec calculations are known to be buggy, so you cannot trust those numbers Sad

Will try to fix that soonish, so people may accurately compare numbers with other installations.

BitLex

hero member

Activity: 532

Merit: 505

yay! now it works.

running at ~50% on dual-, 30-40% on a triple-core only (at default settings), but it works.
gonna play with settings later.

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: BitLex on November 26, 2010, 06:27:55 PM

Quote

I'd be interested to see how well this works on Vista, XP, 7, ...

complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP,
am i missing something?

Updated the installer at http://yyz.us/bitcoin/cpuminer-installer.zip

Does the problem still exist?

EDIT: Here are the checksums for the latest Windows installer zipfile...
   Size: 1978933 bytes
   SHA1: fdea8a045db5e09b7441a4059fbdba186490e742
   MD5: e60dbfb7c3b458c2a98e71cb295f9b7d

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: slush on November 26, 2010, 07:08:44 PM

Quote from: BitLex on November 26, 2010, 06:27:55 PM

complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP,
am i missing something?

Same here (WinXP)

Clearly my installer-maker is having a problem Sad

Will investigate (though probably tomorrow).

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: satoshi on November 26, 2010, 05:02:41 PM

You should try it with tcatm's 4-way SSE2 SHA in sha256.cpp.

Added. Users may select this by enabling SSE2 instructions in their compiler during build, and then

Code:

$ minerd --algo=4way

will select the 4way implementation, rather than the default 'c' implementation. Run "minerd --help" to make sure 4way is listed as an available option first; if not, you did not build with SSE2 enabled (-msse2, or many values of -march=xxx).

slush

legendary

Activity: 1386

Merit: 1097

Quote from: BitLex on November 26, 2010, 06:27:55 PM

complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP,
am i missing something?

Same here (WinXP)

jgarzik

legendary

Activity: 1596

Merit: 1100

Quote from: BitLex on November 26, 2010, 06:27:55 PM

Quote

I'd be interested to see how well this works on Vista, XP, 7, ...

complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP,
am i missing something?

Try adding c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\ to your PATH, then run minerd.exe?

BitLex

hero member

Activity: 532

Merit: 505

Quote

I'd be interested to see how well this works on Vista, XP, 7, ...

complaining about "libcurl-4.dll missing" (although it's there at c:\CPU-miner\usr\i686-pc-mingw32\sys-root\mingw\bin\) it won't even start on 64bit XP&7, 32bit XP,
am i missing something?

Topic: New demonstration CPU miner available - page 25. (Read 386323 times)