Wolf's XMR/BCN/DSH CPUMiner - 2x speed compared to LucasJones' - NEW 06/20/2014

[CrashOD]

minerd-wolf-07-09-14 hits me hard with a decrease in performance. ~120 h/s

using minerd from cpuminer-multi-wolf-06-09-2014.zip ~190 h/s

CPU is a 12 core Xeon E5-2430 V2 Is this expected?

I think that minerd-wolf-07-09-14 is only for non-AES-NI cpus. That would explain the drop in hashrate for you and why when I tried it at first I saw a major drop in speed.

[1714858008]

1714858008

[1714858008]

1714858008

[1714858008]

1714858008

[sleepdog]

Win64 binaries exist but require AES-NI.

If I compile from source should I be able to run it on a processor without AES-NI then?  I compiled it successfully in an Virtualbox Ubuntu 13.04 virtual machine (on a Win 7 host without AES-NI), but get:

Code:

[2014-05-31 09:46:38] Using JSON-RPC 2.0
[2014-05-31 09:46:38] 2 miner threads started, using 'cryptonight' algorithm.
Illegal instruction (core dumped)

upon starting up the miner.

Configure with --disable-aes-ni

Whereabouts do I need to put the "--disable-aes-ni" when compiling?

[pallas]

Whereabouts do I need to put the "--disable-aes-ni" when compiling?

./autogen.sh
CFLAGS='-march=native' ./configure --disable-aes-ni
make -j<numberofcores>

possibly "make clean" before "make"

[sleepdog]

Similar results here. I ran some tests with a dual E5520 server.

cpu-multi / LucasJones (these are the same thing, right?) v2.3.3 gets max 148 H/s and is pretty much always over 140.

Wolf's newly provided non-AES version gets 118 H/s max, with a range of 100 - 118.

Looks like any advantages of Wolf's miner come from the AES-NI code.

I've now complied and run Wolf's latest version on this same non-AES-NI machine under Linux and although there's a very slight improvement over windows it's still way slower than LucasJones' is under Windows.

So I can only assume my previous statement was correct and that any gains Wolf's version gives are down to the AES-NI parts of his code and you need a machine with AES-NI capable cpus to take full advantage of it.

[sk00t3r]

minerd-wolf-07-09-14 hits me hard with a decrease in performance. ~120 h/s

using minerd from cpuminer-multi-wolf-06-09-2014.zip ~190 h/s

CPU is a 12 core Xeon E5-2430 V2 Is this expected?

I think that minerd-wolf-07-09-14 is only for non-AES-NI cpus. That would explain the drop in hashrate for you and why when I tried it at first I saw a major drop in speed.

Thanks, guess I had a hard time reading lol. It clearly stated that it was for NON AES-NI. Not sure what I was thinking. THanks again.

[JohnD]

I get this error when i try to compile it:

Code:

root@prox8:~/cpuminer-multi# ./autogen.sh
configure.ac:133: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

How to solve that?

System is Debian wheezy 64bit.

[equipoise]

I'm not sure this will work, but did you tried:

Code:

./autogen.sh -m4_pattern_allow

[primer-]

I get this error when i try to compile it:

Code:

root@prox8:~/cpuminer-multi# ./autogen.sh
configure.ac:133: error: possibly undefined macro: AC_MSG_ERROR
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

How to solve that?

System is Debian wheezy 64bit.

Compile latest autoconf from source.

[ballot]

https://minergate.com/download/win32-cli

minergate has 32 bit miner but they restrict the pool 

[Hotmetal]

Hey..

Firstly, thank you for the awesome CPUMiner. It works like a charm.

Is merged mining possible with your / Wof's CPUMiner?

http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work
http://monetaverde.org/

Merged mining will allow you to mine MCN (MonetaVerde) in addition to to the major coin (XMR etc) without a reduction in hashrate.
I see its been asked before, but i was unable to find a conclusive response.

Regards,
Cami

[Hotmetal]

Btw.. Just thought i'd mention this:

Latest CPUMiner compiled from git: (24 x Intel(R) Xeon(R) CPU X5650 @ 2.67GHz)

Over a 20 minute duration:

[2014-08-02 20:25:25] accepted: 191/234 (81.62%), 230.74 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 192/235 (81.70%), 230.63 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 193/236 (81.78%), 230.61 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:31] accepted: 194/237 (81.86%), 230.16 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:40] accepted: 195/238 (81.93%), 231.01 H/s at diff 980 (yay!!!)

Then i removed all of the "optimizations" from the Makefile:

From:

am__append_3 = -Ofast -flto -fuse-linker-plugin -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-if-convert-stores -fmerg
e-all-constants -fbranch-target-load-optimize2 -fsched2-use-superblocks -maes

to :

am__append_3 = -maes

The result?

[2014-08-02 20:26:44] accepted: 189/231 (81.82%), 289.83 H/s at diff 1384 (yay!!!)
[2014-08-02 20:26:45] accepted: 190/232 (81.90%), 290.09 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:03] accepted: 191/233 (81.97%), 291.41 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:07] accepted: 192/234 (82.05%), 290.47 H/s at diff 1384 (yay!!!)

There are numerous posts/warnings on-line about over-aggressive compile-time "optimizations".
Just thought I'd post my results/findings which concur.

Regards,
Cami

[Hotmetal]

Each optimization I tested worked on my CPU - I don't have all CPUs, so I can't test. That much of a reduction is odd, though... are you sure the test wasn't affected by other factors?

It's quite a difference. I have 8 of those monster servers that are freshly installed (+updated) with Ubuntu 14.04.
They are all identical and unused (no running services, crons etc..) but the results are rather inconsistent across each so perhaps something else could be influencing things.
I'll dig a bit deeper and see if anything comes of it.

[Hotmetal]

One thing I found rather interesting:

root@cami001:/# minerd --help
..
  -t, --threads=N       number of miner threads (default: number of processors)
..

root@cami001:/# grep processor /proc/cpuinfo | wc -l                     
24

root@cami001:/# /usr/local/bin/minerd -o stratum+tcp://x.x.x.x:x -p x -u xx
[2014-08-02 15:49:42] Using JSON-RPC 2.0
[2014-08-02 15:49:42] 31 miner threads started, using 'cryptonight' algorithm.
[2014-08-02 15:49:42] Starting Stratum on stratum+tcp://x.x.x.x:x

Out of interests sake, how/where is 31 processors being returned? If I set the thread count manually (-t 24), 24 threads are used and the H/S is extremely consistent.

[dewdeded]

You have 48 cores? (2-Core-CPUs?)

[PeaMine]

Each optimization I tested worked on my CPU - I don't have all CPUs, so I can't test. That much of a reduction is odd, though... are you sure the test wasn't affected by other factors?

It's quite a difference. I have 8 of those monster servers that are freshly installed (+updated) with Ubuntu 14.04.
They are all identical and unused (no running services, crons etc..) but the results are rather inconsistent across each so perhaps something else could be influencing things.
I'll dig a bit deeper and see if anything comes of it.

Going to check this out as well, running it without the optimizations.

[sandor111]

Btw.. Just thought i'd mention this:

Latest CPUMiner compiled from git: (24 x Intel(R) Xeon(R) CPU X5650 @ 2.67GHz)

Over a 20 minute duration:

[2014-08-02 20:25:25] accepted: 191/234 (81.62%), 230.74 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 192/235 (81.70%), 230.63 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:29] accepted: 193/236 (81.78%), 230.61 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:31] accepted: 194/237 (81.86%), 230.16 H/s at diff 980 (yay!!!)
[2014-08-02 20:25:40] accepted: 195/238 (81.93%), 231.01 H/s at diff 980 (yay!!!)

Then i removed all of the "optimizations" from the Makefile:

From:

am__append_3 = -Ofast -flto -fuse-linker-plugin -funroll-loops -fvariable-expansion-in-unroller -ftree-loop-if-convert-stores -fmerg
e-all-constants -fbranch-target-load-optimize2 -fsched2-use-superblocks -maes

to :

am__append_3 = -maes

The result?

[2014-08-02 20:26:44] accepted: 189/231 (81.82%), 289.83 H/s at diff 1384 (yay!!!)
[2014-08-02 20:26:45] accepted: 190/232 (81.90%), 290.09 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:03] accepted: 191/233 (81.97%), 291.41 H/s at diff 1384 (yay!!!)
[2014-08-02 20:27:07] accepted: 192/234 (82.05%), 290.47 H/s at diff 1384 (yay!!!)

There are numerous posts/warnings on-line about over-aggressive compile-time "optimizations".
Just thought I'd post my results/findings which concur.

Regards,
Cami

You should be getting atleast 400 H/s out of those CPUs (mine are hashing at 451 H/s)

[PeaMine]

Each optimization I tested worked on my CPU - I don't have all CPUs, so I can't test. That much of a reduction is odd, though... are you sure the test wasn't affected by other factors?

It's quite a difference. I have 8 of those monster servers that are freshly installed (+updated) with Ubuntu 14.04.
They are all identical and unused (no running services, crons etc..) but the results are rather inconsistent across each so perhaps something else could be influencing things.
I'll dig a bit deeper and see if anything comes of it.

Going to check this out as well, running it without the optimizations.

Without optimizations:

[2014-08-03 00:58:53] accepted: 4/4 (100.00%), 195.91 H/s at diff 5000 (yay!!!)
[2014-08-03 00:59:04] accepted: 5/5 (100.00%), 195.29 H/s at diff 5000 (yay!!!)
[2014-08-03 00:59:07] accepted: 6/6 (100.00%), 194.45 H/s at diff 5000 (yay!!!)
[2014-08-03 00:59:08] accepted: 7/7 (100.00%), 194.69 H/s at diff 5000 (yay!!!)


With:
[2014-08-03 01:00:28] accepted: 3/3 (100.00%), 369.24 H/s at diff 5000 (yay!!!)
[2014-08-03 01:00:36] accepted: 4/4 (100.00%), 369.24 H/s at diff 5000 (yay!!!)
[2014-08-03 01:00:36] accepted: 5/5 (100.00%), 369.23 H/s at diff 5000 (yay!!!)
[2014-08-03 01:00:52] accepted: 6/6 (100.00%), 369.14 H/s at diff 5000 (yay!!!)

Crazy how efficient those optimizations are.
Though sadly needs to be around 440+ or so for current difficulty to break even.

[Hotmetal]

You should be getting atleast 400 H/s out of those CPUs (mine are hashing at 451 H/s)

How though? I've tried on a variety of *very expensive* hardware from Dell.
Each has 100gigs of ram, 24 cpus, etc..

Ubuntu 14.04:

# sysctl -w vm.nr_hugepages=72  (confirmed that it is set)
# git clone https://github.com/wolf9466/cpuminer-multi.git
# cd cpuminer-multi
# ./autogen.sh
# ./configure CFLAGS="-march=native"
# make
# make install
# screen -d -m -S minerd /usr/local/bin/minerd -o stratum+tcp://mro.pool.minergate.com:45560 -p x -u x
# screen -r (after a few hours of running)
[2014-08-03 06:05:25] accepted: 3952/7916 (49.92%), 288.94 H/s at diff 444 (yay!!!)

example of hardware: 24 CPUs - Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
another example:       24 CPUs - Intel(R) Xeon(R) CPU X5650  @ 2.67GHz

[sandor111]

You should be getting atleast 400 H/s out of those CPUs (mine are hashing at 451 H/s)

How though? I've tried on a variety of *very expensive* hardware from Dell.
Each has 100gigs of ram, 24 cpus, etc..

Ubuntu 14.04:

# sysctl -w vm.nr_hugepages=72  (confirmed that it is set)
# git clone https://github.com/wolf9466/cpuminer-multi.git
# cd cpuminer-multi
# ./autogen.sh
# ./configure CFLAGS="-march=native"
# make
# make install
# screen -d -m -S minerd /usr/local/bin/minerd -o stratum+tcp://mro.pool.minergate.com:45560 -p x -u x
# screen -r (after a few hours of running)
[2014-08-03 06:05:25] accepted: 3952/7916 (49.92%), 288.94 H/s at diff 444 (yay!!!)

example of hardware: 24 CPUs - Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
another example:       24 CPUs - Intel(R) Xeon(R) CPU X5650  @ 2.67GHz

Don't set threads equal to number of CPU threads, that is wrong.
The general rule is threads = floor(L3 cache / 1024)
Use this: num_threads=$(($(cat /proc/cpuinfo | grep "cache size" | uniq | cut -d":" -f2 | cut -d" " -f2)/1024))
Should be 12 for X5650

[Hotmetal]

Don't set threads equal to number of CPU threads, that is wrong.
The general rule is threads = floor(L3 cache / 1024)
Use this: num_threads=$(($(cat /proc/cpuinfo | grep "cache size" | uniq | cut -d":" -f2 | cut -d" " -f2)/1024))
Should be 12 for X5650

You sir, are a legend. Why does it automatically set thread count to ~cpu count?

Using your formula:

[2014-08-03 13:19:33] accepted: 12/12 (100.00%), 514.93 H/s at diff 444 (yay!!!)
[2014-08-03 13:19:34] accepted: 13/13 (100.00%), 513.02 H/s at diff 444 (yay!!!)
[2014-08-03 13:19:35] accepted: 14/14 (100.00%), 528.15 H/s at diff 444 (yay!!!)
[2014-08-03 13:19:35] accepted: 15/15 (100.00%), 525.17 H/s at diff 444 (yay!!!)

Perhaps this should be added to the original post? Its a BIG improvement.

Thanks! (Now to deploy this on a motherload of machines :/)