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

pooler

hero member

Activity: 838

Merit: 507

Quote from: iongchun on December 23, 2011, 02:14:59 AM

Quote from: pooler on December 21, 2011, 07:32:42 PM

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.

Not only with the stock gcc 4.2, I tried to compile with gcc 4.6 from MacPorts, the result is the same.
Maybe it is a problem of as, the GNU-based assembler of Mac OS X.

You are probably right. What version of binutils ('as' is part of binutils) is giving you problems?

iongchun

member

Activity: 75

Merit: 10

Quote from: pooler on December 21, 2011, 07:32:42 PM

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.

Not only with the stock gcc 4.2, I tried to compile with gcc 4.6 from MacPorts, the result is the same.
Maybe it is a problem of as, the GNU-based assembler of Mac OS X.

kjlimo

legendary

Activity: 2086

Merit: 1031

I still haven't seen much "doubling" in difficulty or hash rate yet...

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Come-from-Beyond on December 22, 2011, 12:43:24 PM

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"...

Well the larger implication is that once shared and upgraded it no longer provide anyone any advantage.

So say you made a miner that was 200% hashrate on same hardware. Double the money right? Sure until you share it. Eventually everyone will be doubling their hashrate, so global hashrate will double, so difficulty will double and you are right back making the same revenue as when you were using your 100% miner.

Still sharing info is always good for the network (although not for your personal profits). Hypothetically says an attacker already had a 200% hashrate miner. Obviously he isn't going to share. Now with 1000 CPU he has the same hashing power as 2000 avg defender CPU. In effect the network effective strength is half of what is appears to be. However if you share your 200% hashrate miner it neutralizes that potential advantage.

As the miner's get more and more efficient (approaching theoretical max performance of CPU) the confidence grows that nobody has an "unfair" advantage.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

5 kh/s just 1 thread?

Remember remember the 5th of November

legendary

Activity: 1862

Merit: 1011

Reverse engineer from time to time

Quote from: Come-from-Beyond on December 22, 2011, 12:43:24 PM

Quote from: Remember remember the 5th of November on December 22, 2011, 11:01:39 AM

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

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: Remember remember the 5th of November on December 22, 2011, 11:01:39 AM

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"...

terrytibbs

hero member

Activity: 560

Merit: 501

Quote from: DeathAndTaxes on December 22, 2011, 11:24:01 AM

Quote from: terrytibbs on December 22, 2011, 11:20:34 AM

Quote from: DeathAndTaxes on December 22, 2011, 11:05:24 AM

Quote from: Come-from-Beyond on December 22, 2011, 05:05:24 AM

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."

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: terrytibbs on December 22, 2011, 11:20:34 AM

Quote from: DeathAndTaxes on December 22, 2011, 11:05:24 AM

Quote from: Come-from-Beyond on December 22, 2011, 05:05:24 AM

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

hero member

Activity: 560

Merit: 501

Quote from: DeathAndTaxes on December 22, 2011, 11:05:24 AM

Quote from: Come-from-Beyond on December 22, 2011, 05:05:24 AM

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

donator

Activity: 1218

Merit: 1079

Gerald Davis

Quote from: Come-from-Beyond on December 22, 2011, 05:05:24 AM

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.

Remember remember the 5th of November

legendary

Activity: 1862

Merit: 1011

Reverse engineer from time to time

Quote from: Come-from-Beyond on December 22, 2011, 05:05:24 AM

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.

Come-from-Beyond

legendary

Activity: 2142

Merit: 1009

Newbie

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

sd

hero member

Activity: 730

Merit: 500

Quote from: Come-from-Beyond on December 22, 2011, 01:34:54 AM

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

legendary

Activity: 2142

Merit: 1009

Newbie

Quote from: bulanula on December 21, 2011, 07:19:56 PM

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

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.

pooler

hero member

Activity: 838

Merit: 507

Quote from: ?? on ??

Quote from: pooler on December 21, 2011, 07:11:03 PM

Quote from: ?? on ??

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.

bulanula

hero member

Activity: 518

Merit: 500

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

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

pooler

hero member

Activity: 838

Merit: 507

Quote from: ?? on ??

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.

pooler

hero member

Activity: 838

Merit: 507

Quote from: ?? on ??

Quote from: pooler on December 21, 2011, 05:14:09 PM

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!

Quote from: Remember remember the 5th of November on December 19, 2011, 09:58:49 PM

Quote from: HolodeckJizzmopper on December 19, 2011, 09:47:57 PM

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

hero member

Activity: 838

Merit: 507

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!

Quote from: Remember remember the 5th of November on December 19, 2011, 09:58:49 PM

Quote from: HolodeckJizzmopper on December 19, 2011, 09:47:57 PM

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!)

Topic: An (even more) optimized version of cpuminer (pooler's cpuminer, CPU-only) - page 67. (Read 1958260 times)