An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only)

[pooler]

Pooler,

 Don't you think that NVidia CUDA can run some new assembly code for Scrypt more fast than a CPU?
 I'm asking this because I see that some guys are working on a open source miner for SolidCoin (a.k.a Shitcoin) that run on CUDA...

Best!
Thiago

I might be wrong, but doesn't SolidCoin use a different algorithm?
Apart from that, I'm not a GPGPU expert in any way, but I don't think computing Scrypt on a GPU would be efficient, at least not with the hardware that is available at the moment.

[1714003532]

1714003532

[1714003532]

1714003532

[exahash]

The Pentium D's are running fresh installs of Ubuntu 10.04 64-bit, up to date "aptitude dist-upgrade" and rebooted.  

The artforz miner was pulled from git yesterday with "git pull https://github.com/ArtForz/cpuminer" as was pooler's "git pull https://github.com/pooler/cpuminer"  Both were compiled with CFLAGS="-march=native -O3 -Wall -msse2"

I even tried copying over the binaries that were compiled on the sempron and xeon boxes but got the same results.

I'm thinking there's either something about the P4D's that makes them bad at scrypt, or I've got a bios or OS setting messed up somewhere.

It seems odd that they are 2.8 GHz dual-core chips with each thread doing exactly half it's GHz in khash/s.  Maybe there is some instruction that takes two clock cycles which only takes one in newer chips?

If I can get some time, I might go try Windows and/or Ubuntu 11.10 on one of them to see if it makes a difference.

Yes, I would like to see the performance in 32-bit mode. The Pentium D's were very early 64-bit cpus, and are not as good at SSE as later Core-based models, but I expected them to get some improvement from the new code.

I put Ubuntu 11.10 i386 on one of the Pentium D boxes and it's not good - it only sees one core, with ArtForz's miner doing 0.84 kh/s and pooler's miner running at 1.26 kh/s

There might be an smp kernel, but I'd rather go back to the amd64 build and just count my blessings at 1.48 kh/s x2.

[kjlimo]

Intel Core 2 Duo P8700 went from 1.15 khash/s to 3.4khash/s!

[Intention]

Pooler,

 Don't you think that NVidia CUDA can run some new assembly code for Scrypt more fast than a CPU?
 I'm asking this because I see that some guys are working on a open source miner for SolidCoin (a.k.a Shitcoin) that run on CUDA...

Best!
Thiago

I might be wrong, but doesn't SolidCoin use a different algorithm?
Apart from that, I'm not a GPGPU expert in any way, but I don't think computing Scrypt on a GPU would be efficient, at least not with the hardware that is available at the moment.

They do use a different algorithm, funny enough I remember asking him if it used scrypt back on IRC when they launched SC2 since it was supposed to be cpu only and he said yes.

[pooler]

We finally managed to build a 32-bit binary for Mac OS X 10.4, here it is:
http://dl.dropbox.com/u/828037/minerd_for_OSX_10.4.zip
Many thanks to SockPuppet, who did all the hard work!

Running minerd.exe on Windows with no parameters causes a gpf.

Known bug

That should be fixed now.
I have also added a couple lines of code to auto-detect the number of cores when the number of threads is not specified. This already worked under Linux, but now it should work under Windows, too. (Thanks to diki for testing and for the new binaries!)

Please note that I have changed a few default values in the latest release. The default URL is now http://127.0.0.1:9332/, and the retry parameter has been defaulted to -1, i.e. "retry indefinitely".
This release also changes the "PROOF OF WORK RESULT" message to include information about submitted shares and total hash rate. (Thanks to inlikeflynn!)

[pooler]

We finally managed to build a 32-bit binary for Mac OS X 10.4, here it is:
http://dl.dropbox.com/u/828037/minerd_for_OSX_10.4.zip
Many thanks to SockPuppet, who did all the hard work!

Running minerd.exe on Windows with no parameters causes a gpf.

Known bug

That should be fixed now.
I have also added a couple lines of code to auto-detect the number of cores when the number of threads is not specified. This already worked under Linux, but now it should work under Windows, too. (Thanks to diki for testing and for the new binaries!)

Please note that I have changed a few default values in the latest release. The default URL is now http://127.0.0.1:9332/, and the retry parameter has been defaulted to -1, i.e. "retry indefinitely".
This release also changes the "PROOF OF WORK RESULT" message to include information about submitted shares and total hash rate. (Thanks to inlikeflynn!)

Well tells us the secret so we can build it ourselves...

Code:

gcc  -O3 -pthread -arch x86_64 -o minerd minerd-cpu-miner.o minerd-util.o minerd-scrypt.o -L/opt/local/lib -lcurl -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lidn -lssl -lcrypto -lssl -lcrypto -lz -lz compat/jansson/libjansson.a -lpthread 
Undefined symbols:
  "_x64_scrypt_core", referenced from:
      _scanhash_scrypt in minerd-scrypt.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [minerd] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

In the above gcc line you miss a couple object files.
I didn't change any build-related file in this release, however, so that's a bit strange.
Have you tried running a clean clone/autogen/configure/make?

[pooler]

Yes was problem with old configure.am I copied over however now I get.

{code}

I guess this is the first time you try to compile the new miner on that machine, because I didn't change the assembly code in the latest release, and you are getting errors on that.
What version of gcc/binutils are you using? I think I saw those errors already on some older versions.

[bulanula]

I was going mad here telling everyone there has to be better performance for Intel CPUs but I was seen a lunatic

It has finally arrived but sadly since everyone will upgrade, there will not be any profitability increase. Thanks though !

[pooler]

Yes was problem with old configure.am I copied over however now I get.

{code}

I guess this is the first time you try to compile the new miner on that machine, because I didn't change the assembly code in the latest release, and you are getting errors on that.
What version of gcc/binutils are you using? I think I saw those errors already on some older versions.

The binutils I just installed from MacPorts it made no difference same error.

Code:

gcc -version
i686-apple-darwin10-gcc-4.2.1: no input files

binutils @2.21_0

Hey, wait, you are on a Mac! I thought you were under Linux, sorry. Unfortunately gcc 4.2 seems to have some problems with macros in assembly code.
In order to get it to compile, SockPuppet had to expand all the macros by hand. Unfortunately I cannot just use his version in the main package, because the code becomes very hard to read. But I think you can contact him if you want the modified sources.

[Come-from-Beyond]

I was going mad here telling everyone there has to be better performance for Intel CPUs but I was seen a lunatic

It has finally arrived but sadly since everyone will upgrade, there will not be any profitability increase. Thanks though !

We heard u. The profit comes from better performance on older machines (new ones get less boost). Also with improved miner we have better chance to survive 51% attacks.

PS: I know at least 2 guys who wrote faster LTC miners but since they have not published their sources nor compiled binaries we shouldn't take this into account. So why bother about such things? Any program can be improved indefinitely.

[sd]

Also with improved miner we have better chance to survive 51% attacks.

Not unless you assume the people doing the 51% attack already have the faster miner.

[Come-from-Beyond]

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

[Remember remember the 5th of November]

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

You don't seem to understand. If they were using the same miner as we did before, then with the new one, the dark pool has twice the speed now, but we have also increased it.

[DeathAndTaxes]

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.

[terrytibbs]

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.

You are wrong. This code increases the hashing rate more for specific architectures than it does for others. An attack by one of the weaker architectures (AMD right now, if I'm not mistaken) can still be mitigated if everyone switches to this.

[DeathAndTaxes]

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.

You are wrong. This code increases the hashing rate more for specific architectures than it does for others. An attack by one of the weaker architectures (AMD right now, if I'm not mistaken) can still be mitigated if everyone switches to this.

That would assume the distribution of Intel vs AMD is materially different between an attacker and a defender.  A botnet is a collection of semi-random computer systems with a wide variety of hardware.  The defenders likewise are running on a wide variety of hardware.      Sure if all the "good guys" had Intels and all the botnets had nothing but AMD chips then the software improvement would change the balance but that dynamic doesn't exist.

Technically a botnet has more control of its nodes.  So a botnet could be assured that all its nodes are running the most efficient software.  If only a fraction of the "good guys" upgrade to more efficient software then the improved code would actually shift the balance away from the defenders.   Luckily there is a direct financial incentive to upgrade.  If you don't upgrade your revenue/profits will decline.  If you do upgrade you avoid lower profits.

[terrytibbs]

Quality of a miner the attackers use doesn't matter. More power we have - stronger we are.

No.  All that matters is relative strength.  Since good miners and bad miners have equal access to the same code and all upgrade than nothing has changed.

You are wrong. This code increases the hashing rate more for specific architectures than it does for others. An attack by one of the weaker architectures (AMD right now, if I'm not mistaken) can still be mitigated if everyone switches to this.

That would assume the distribution of Intel vs AMD is materially different between an attacker and a defender.  A botnet is a collection of semi-random computer systems with a wide variety of hardware.  The defenders likewise are running on a wide variety of hardware.      Sure if all the "good guys" had Intels and all the botnets had nothing but AMD chips then the software improvement would change the balance but that dynamic doesn't exist.

Technically a botnet has more control of its nodes.  So a botnet could be assured that all its nodes are running the most efficient software.  If only a fraction of the "good guys" upgrade to more efficient software then the improved code would actually shift the balance away from the defenders.   Luckily there is a direct financial incentive to upgrade.  If you don't upgrade your revenue/profits will decline.  If you do upgrade you avoid lower profits.

Botnets aren't our only enemy. We are also fighting possible future ASIC or FPGA implementations. Come-from-Beyond beyond is correct in saying that "[the] more power we have - [the] stronger we are." You, on the other hand, are incorrect in saying that "all that matters is relative strength."

[Come-from-Beyond]

You don't seem to understand. If they were using the same miner as we did before, then with the new one, the dark pool has twice the speed now, but we have also increased it.

Now I got it. U r right.

PS: Seems to me I shouldn't publish my miner that works at 2.5 rate (2500 h/s for 1 GHz of cpu). Just to prevent its usage for a so-called "dark pool"...

[Remember remember the 5th of November]

You don't seem to understand. If they were using the same miner as we did before, then with the new one, the dark pool has twice the speed now, but we have also increased it.

Now I got it. U r right.

PS: Seems to me I shouldn't publish my miner that works at 2.5 rate (2500 h/s for 1 GHz of cpu). Just to prevent its usage for a so-called "dark pool"...

Glad that got sorted out.

As for the miner, the Atom CPU which is 1.6Ghz can do over 5Kh/s with the new miner.

[Come-from-Beyond]

5 kh/s just 1 thread?