[LOCKED] cpuminer-opt v3.12.3, open source optimized multi-algo CPU miner

[ybelevi]

hello

i want to compile it on my linux machine.i was  download the file then extract it.write this commands but get error.how can i slove it
 regards

./autogen.sh
./configure CFLAGS="-O3"
make

error message

algo/cryptonight/cryptonight-aesni.c:251:2: warning: passing argument 1 of ‘kecc
In file included from algo/cryptonight/cryptonight-aesni.c:2:0:
algo/cryptonight/cryptonight.h:65:6: note: expected ‘uint64_t *’ but argument is
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory `/root/cpuminer-opt-3.1.4'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/cpuminer-opt-3.1.4'
make: *** [all] Error 2

[1714052286]

1714052286

[1714052286]

1714052286

[1714052286]

1714052286

[1714052286]

1714052286

[joblo]

hello

i want to compile it on my linux machine.i was  download the file then extract it.write this commands but get error.how can i slove it
 regards

./autogen.sh
./configure CFLAGS="-O3"
make

error message

algo/cryptonight/cryptonight-aesni.c:251:2: warning: passing argument 1 of ‘kecc
In file included from algo/cryptonight/cryptonight-aesni.c:2:0:
algo/cryptonight/cryptonight.h:65:6: note: expected ‘uint64_t *’ but argument is
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory `/root/cpuminer-opt-3.1.4'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/cpuminer-opt-3.1.4'
make: *** [all] Error 2

You're missing some stuff on the configure command line

./configure CFLAGS="-O3 -march=native" --with-curl --with-crypto

[joblo]

cpuminer-opt v3.1.5 available for download. AES_NI optimisations added to nist5 (+54%) and zr5 (+47%).

https://drive.google.com/file/d/0B0lVSGQYLJIZVnB3NkwyckxlTk0/view?usp=sharing

[joblo]

There has been some discussion in the pools forum about algo profitability normalisation and I thought
I'd post some norms for optimized cpuminer-opt algos. Measurements were taken using an i7-6700K with
8 threads running except cryptonight which performs best with 4 threads.

algo * norm = x11 equivalent

x11             = 1
x13             = .50
x14             = .48
x15             = .40
quark          = 1.6
qubit           = 1.45
lyra2re        = 1.25
lyra2rev2    = .65
nist5            = 1.97
neoscrypt    = .043
cryptonight = .00039

Compared with ccminer cpuminer-opt is most efficient with lyra2, then  x11, qubit and quark. The X algo efficiency drops
as the chains get longer because only the x11 functions are optimized.

I will update the OP to include these numbers for reference.

[joblo]

Algo naming is becoming a bigger issue. With the many variatoins of the blake algo in use Nicehash
has decided to use more technical name rather than vanilla etc.

To make handling aliases easier I have implemeted a little utility in cpuminer-opt to make it easier
to support aliases and avoid a long cascading switch/case. It can be easilly ported to ccminer.

Code:

// an algo can have multiple aliases but the aliases must be unique

#define ALGO_PROPER (1)
#define ALGO_ALIAS  (0)
#define NUM_ALIASES (11)

// Need to sort out all the blakes
// blake256r14 is apparently decred
// Vanilla was obvious, blakecoin is almosty identical to vanilla
// What is blake2s, pentablake?

const char* algo_alias_map[NUM_ALIASES][2] =
{
//   alias                proper
  { "blake256r8vnl",     "vanilla"     },
  { "blake256r8",        "blakecoin"   },
  { "cryptonight-light", "cryptolight" },
  { "droplp",            "drop"        },
  { "flax",              "c11"         },
  { "lyra2",             "lyra2re"     },
  { "lyra2v2",           "lyra2rev2"   },
  { "myriad",            "myr-gr"      },
  { "neo",               "neoscrypt"   },
  { "sibcoin",           "sib"         },
  { "ziftr",             "zr5"         }
};

// updates arg with proper algo name if it is a valid alias.
void get_algo_alias( char** algo_or_alias )
{
  int i;
  for ( i=0; i < NUM_ALIASES; i++ )
    if ( !strcasecmp( *algo_or_alias, algo_alias_map[i][ ALGO_ALIAS ] ) )
    {
      // found valid alias, return proper name
      *algo_or_alias = algo_alias_map[i][ ALGO_PROPER ];
      return;
    }
}

// example of usage

           case 'a':
              get_algo_alias( &arg );

              for (i = 0; i < ALGO_COUNT; i++)
              {
                  v = (int) strlen(algo_names[i]);
                  if (v && !strncasecmp(arg, algo_names[i], v))
                  {
                        if (arg[v] == '\0')
                        {
                                opt_algo = (enum algos) i;
                                break;
                        }
                        if (arg[v] == ':')
                        {
                                char *ep;
                                v = strtol(arg+v+1, &ep, 10);
                                if (*ep || v & (v-1) || v < 2)
                                        continue;
                                opt_algo = (enum algos) i;
                                opt_scrypt_n = v;
                                break;
                        }
                  }
              }

              if (i == ALGO_COUNT)
                 show_usage_and_exit(1);

           break;

The current implementation requires the array size to be hardcoded. I tried terminating with NULLs but all
I got were segfaults and bus errors. If any C gurus out there know how to do it properly please advise.

[pallas]

Could you post the code which segfaults, so I can have a look?

[joblo]

cpuminer-opt v3.1.6 is out.

Download:

https://drive.google.com/file/d/0B0lVSGQYLJIZcnJOU0VsWTBWZG8/view?usp=sharing

Support for the following algos was added, pool tested:
  x14 with AES_NI optimisations
  blake
  vanilla (blake256r14vnl on nicehash).
  blake2s, requires custom diff on yiimp: -p d=0.2

Added blakecoin & fresh algos, benchmark tested only.

Added aliases for vanilla and blakecoin to match nicehash names:
   blake256r8vnl = vanilla
   blake256r8    = blakecoin

[joblo]

Could you post the code which segfaults, so I can have a look?

I'l have to recode it, will send via pm.

In brief i tried 2 things:

1. char **algo_aliases = ...

The last entry has the second level pointer (algo_aliases->alias) is set to null with no sub-array.
I test with algo_aliases[ i ]==null

2. char * algo_aliases[num_aliases][2] = ...

The last entry has the sub-array with both names set to null (head->algo-aliases->alias->name, head->algo_aliases->proper->name )
I test with *algo_aliases[ i ][alias]==null   (extra deref for head pointer)

I have a couple of ideas to mix the two methods to see if something works, but it's just trial and error. If it doesn't work
out I'll send you the code.

Thanks for your interest.

[pallas]

const char algo_alias_map[][2][] = {

...

{NULL, NULL}
}

if (algo_alias_map[n][0] == NULL)

should work.

[joblo]

const char algo_alias_map[][2][] = {

...

{NULL, NULL}
}

if (algo_alias_map[n][0] == NULL)

should work.

Almost worked, needed to make a slight adjustment:

const char *algo_alias_map[][2] = {

Thanks.

[joblo]

const char algo_alias_map[][2][] = {

...

{NULL, NULL}
}

if (algo_alias_map[n][0] == NULL)

should work.

Almost worked, needed to make a slight adjustment:

const char *algo_alias_map[][2] = {

Thanks.

Still had to work a few things out, got mixed up with operator precedence:
char * a[] means a array of char pointers, not a pointer to an array.

The working version will be in the next release, just missed 3.1.6.

Code:

// an algo can have multiple aliases but the aliases must be unique

#define PROPER (1)
#define ALIAS  (0)

// Need to sort out all the blakes
// blake256r14 is apparently decred
// Vanilla was obvious, blakecoin is almosty identical to vanilla
// What is blake2s, pentablake?

const char* algo_alias_map[][2] =
{
//   alias                proper
  { "blake256r8vnl",     "vanilla"     },
  { "blake256r8",        "blakecoin"   },
  { "cryptonight-light", "cryptolight" },
  { "droplp",            "drop"        },
  { "flax",              "c11"         },
  { "lyra2",             "lyra2re"     },
  { "lyra2v2",           "lyra2rev2"   },
  { "myriad",            "myr-gr"      },
  { "neo",               "neoscrypt"   },
  { "sibcoin",           "sib"         },
  { "ziftr",             "zr5"         },
  { NULL,                NULL          }   //add new aliases above this line
};

// if arg is a valid alias for a known algo it is updated with the proper name.
// No validation of the algo or alias is done, It is the responsinility of the
// calling function to validate the algo after return.
void get_algo_alias( char** algo_or_alias )
{
  int i;
  for ( i=0; algo_alias_map[i][ALIAS]; i++ )
    if ( !strcasecmp( *algo_or_alias, algo_alias_map[i][ ALIAS ] ) )
    {
      // found valid alias, return proper name
      *algo_or_alias = algo_alias_map[i][ PROPER ];
      return;
    }
}

[joblo]

const char algo_alias_map[][2][] = {

...

{NULL, NULL}
}

if (algo_alias_map[n][0] == NULL)

should work.

Almost worked, needed to make a slight adjustment:

const char *algo_alias_map[][2] = {

Thanks.

Still had to work a few things out, got mixed up with operator precedence:
char * a[] means a array of char pointers, not a pointer to an array.

The working version will be in the next release, just missed 3.1.6.

Code:

// an algo can have multiple aliases but the aliases must be unique

#define PROPER (1)
#define ALIAS  (0)

// Need to sort out all the blakes
// blake256r14 is apparently decred
// Vanilla was obvious, blakecoin is almosty identical to vanilla
// What is blake2s, pentablake?

const char* algo_alias_map[][2] =
{
//   alias                proper
  { "blake256r8vnl",     "vanilla"     },
  { "blake256r8",        "blakecoin"   },
  { "cryptonight-light", "cryptolight" },
  { "droplp",            "drop"        },
  { "flax",              "c11"         },
  { "lyra2",             "lyra2re"     },
  { "lyra2v2",           "lyra2rev2"   },
  { "myriad",            "myr-gr"      },
  { "neo",               "neoscrypt"   },
  { "sibcoin",           "sib"         },
  { "ziftr",             "zr5"         },
  { NULL,                NULL          }   //add new aliases above this line
};

// if arg is a valid alias for a known algo it is updated with the proper name.
// No validation of the algo or alias is done, It is the responsinility of the
// calling function to validate the algo after return.
void get_algo_alias( char** algo_or_alias )
{
  int i;
  for ( i=0; algo_alias_map[i][ALIAS]; i++ )
    if ( !strcasecmp( *algo_or_alias, algo_alias_map[i][ ALIAS ] ) )
    {
      // found valid alias, return proper name
      *algo_or_alias = algo_alias_map[i][ PROPER ];
      return;
    }
}

After all that it might have been simpler to list all the aliases in ALGO_NAMES and
use multiple case statements for algo with aliases. 

[th3.r00t]

The new version 3.1.6 returns only invalid (low-diff) shares with zr5 algo on ziftrpool.io
AKAIK v3.1.5 worked just fine with that pool.

There is some more room for improvement, especially on zr5.

With scmorse/ziftr-cpu which is ig0tik3d/ziftr-cpu with stratum,
I get about 640 khash on Core i7-4790K CPU @ 4.40GHz and with your miner I got as close to 600 khash...

Just my 2 cents.

[joblo]

The new version 3.1.6 returns only invalid (low-diff) shares with zr5 algo on ziftrpool.io
AKAIK v3.1.5 worked just fine with that pool.

There is some more room for improvement, especially on zr5.

With scmorse/ziftr-cpu which is ig0tik3d/ziftr-cpu with stratum,
I get about 640 khash on Core i7-4790K CPU @ 4.40GHz and with your miner I got as close to 600 khash...

Just my 2 cents.

Thanks for the feedback, I'll look into it.

Edit: No rejects for me with default options at yiimp. I also reviewed the code and found no changes that would affect zr5.
Can you confirm that 3.1.5 & 3.1.6 behave differently? Could you also try yiimp?

When I mine the diff is reported as .013. You could try setting the diff manually. On yaamp clones it is in the password
string ( -p d=n ), but your pool may be different.

Edit2: I took a look at the scmorse implementation and i might be able to do better. His implemetation does not use the
aes-ni optimized groestl. If I can integrate that it should hash even faster.

[joblo]

The new version 3.1.6 returns only invalid (low-diff) shares with zr5 algo on ziftrpool.io
AKAIK v3.1.5 worked just fine with that pool.

There is some more room for improvement, especially on zr5.

With scmorse/ziftr-cpu which is ig0tik3d/ziftr-cpu with stratum,
I get about 640 khash on Core i7-4790K CPU @ 4.40GHz and with your miner I got as close to 600 khash...

Just my 2 cents.

Thanks for the feedback, I'll look into it.

Edit: No rejects for me with default options at yiimp. I also reviewed the code and found no changes that would affect zr5.
Can you confirm that 3.1.5 & 3.1.6 behave differently? Could you also try yiimp?

When I mine the diff is reported as .013. You could try setting the diff manually. On yaamp clones it is in the password
string ( -p d=n ), but your pool may be different.

Edit2: I took a look at the scmorse implementation and i might be able to do better. His implemetation does not use the
aes-ni optimized groestl. If I can integrate that it should hash even faster.

Merging my optimizations with scmorse gave a 33% increase to zr5 but I'll wait to release it until your issue is understood.

[th3.r00t]

The new version 3.1.6 returns only invalid (low-diff) shares with zr5 algo on ziftrpool.io
AKAIK v3.1.5 worked just fine with that pool.

There is some more room for improvement, especially on zr5.

With scmorse/ziftr-cpu which is ig0tik3d/ziftr-cpu with stratum,
I get about 640 khash on Core i7-4790K CPU @ 4.40GHz and with your miner I got as close to 600 khash...

Just my 2 cents.

Thanks for the feedback, I'll look into it.

Edit: No rejects for me with default options at yiimp. I also reviewed the code and found no changes that would affect zr5.
Can you confirm that 3.1.5 & 3.1.6 behave differently? Could you also try yiimp?

When I mine the diff is reported as .013. You could try setting the diff manually. On yaamp clones it is in the password
string ( -p d=n ), but your pool may be different.

Edit2: I took a look at the scmorse implementation and i might be able to do better. His implemetation does not use the
aes-ni optimized groestl. If I can integrate that it should hash even faster.

Merging my optimizations with scmorse gave a 33% increase to zr5 but I'll wait to release it until your issue is understood.

Well after recompile of v3.1.6 on my Ubuntu box there is no low-diff rejects on ziftrpool.io
v3.1.5 is also good, but little bit (about 5 khash) slower.
Guess it was something wrong with the previous compile...   (I think I used ./build.sh script)

33% more harshrate on ZR5 sounds just AWESOME!  
I expect that my Core i7-4790K will go upto ~800 khash...
Just to compare - an older GPU, AMD HD6870 makes 860-900 khash average with wolf's GPU miner @ 845 MHz...

[joblo]

cpuminer-opt v3.1.7 is available for download:

https://drive.google.com/file/d/0B0lVSGQYLJIZdVZlczRsVlFGUWs/view?usp=sharing

New in v3.1.7

For users:

  - zr5 algo +33% AES_NI and SSE2 optimised, +98% since v3.1.4

For developpers:

  - better handling of algo aliases
  - better handling of hashrate display

Recently added algos:

  - x14 with AES_NI optimisations
  - blake
  - blake2s
  - vanilla (blake256r14vnl).
  - x17, blakecoin & fresh algos, benchmark tested only.

Recently improved algos:

  - nist5 +54% AES_NI optimised.
  - c11   +27% AES_NI optimised.
  - SSE2 hashrate increases in many algos.

See first post and for more details including normalisation factors.

[joblo]

The new version 3.1.6 returns only invalid (low-diff) shares with zr5 algo on ziftrpool.io
AKAIK v3.1.5 worked just fine with that pool.

There is some more room for improvement, especially on zr5.

With scmorse/ziftr-cpu which is ig0tik3d/ziftr-cpu with stratum,
I get about 640 khash on Core i7-4790K CPU @ 4.40GHz and with your miner I got as close to 600 khash...

Just my 2 cents.

Thanks for the feedback, I'll look into it.

Edit: No rejects for me with default options at yiimp. I also reviewed the code and found no changes that would affect zr5.
Can you confirm that 3.1.5 & 3.1.6 behave differently? Could you also try yiimp?

When I mine the diff is reported as .013. You could try setting the diff manually. On yaamp clones it is in the password
string ( -p d=n ), but your pool may be different.

Edit2: I took a look at the scmorse implementation and i might be able to do better. His implemetation does not use the
aes-ni optimized groestl. If I can integrate that it should hash even faster.

Merging my optimizations with scmorse gave a 33% increase to zr5 but I'll wait to release it until your issue is understood.

Well after recompile of v3.1.6 on my Ubuntu box there is no low-diff rejects on ziftrpool.io
v3.1.5 is also good, but little bit (about 5 khash) slower.
Guess it was something wrong with the previous compile...   (I think I used ./build.sh script)

33% more harshrate on ZR5 sounds just AWESOME!  
I expect that my Core i7-4790K will go upto ~800 khash...
Just to compare - an older GPU, AMD HD6870 makes 860-900 khash average with wolf's GPU miner @ 845 MHz...

I haven't looked at build.sh since the fork, I should clean it up. Thanks for the tip about scmorse.

[joblo]

Hot on the heels of cpuminer-opt v3.1.7 comes v3.1.8 with more optimisations.

https://drive.google.com/file/d/0B0lVSGQYLJIZVllmU01wSGpvRjA/view?usp=sharing

New in v3.1.8

  - sib algo optimised:
      +116% AES_NI & SSE2
       +63% SSE2

  - nist5 algo SSE optimised, in addition to previous AES_NI optimizations
      +111% AES_NI & SSE2
       +68% SSE2

  - c11 algo +57% optimized for AES_NI & SSE2

[th3.r00t]

Very nice bump in hashrate for ZR5! 

v3.1.7 - goes to 830-840 khash
v3.1.8 - goes to 825-830 khash

Read something about SSE2 optimisations on some algos - does that means that I can use your miner in AMD cpus that have SSE2 (since they lack AES-NI support)?

P.S. You are very welcome for the scmorse's tip.
Right now I'm making your miner default for my i7 cpu.