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

[joblo]

sry just saw it on the first page.

Westmere Xeon E5649 now works fine, 2 CPU's are throwing ~700kH/s (using cpuminer.exe)

Sandybridge build on i5-2500K gets ~250kH/s

Older Xeon's E5540 (Gainestown) with only SSE2 support are starting miner but crashes every time after receiving first data (using cpuminer.exe)

Checking CPU capatibility...
        Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz
   CPU arch supports AES-AVX...NO.
   CPU arch supports SSE2.....YES.
YES.
Starting mining without AES-AVX optimizations...

Thank you for your testing, the crash of Gainstown is expected because it has no AES whatsoever. This proves
the Westmere build is not compatible with core2, another significant data point.

cpuminer-opt does work on core2 on linux (all algos) and Windows (all except hodl). This I have tested. You will
either have to compile your own with -march=native or ask CMB to do it for you.

Can you post the capabilities check results from the Westmere CPUs?

[joblo]

By the way, after that patch, I've found a bug:

Code:

Checking compatibility of this cpuminer and CPU (Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz)
   cpuminer expects SSE2:           YES.
   cpuminer expects AES:            no
   cpuminer expects AVX:            no
   CPU supports SSE2:               YES.
   CPU supports AES:                no
   CPU supports AVX:                YES.
   requested algo supports AES+AVX: YES.
[2016-06-03 04:57:04] 4 miner threads started, using 'hodl' algorithm.

See that "CPU supports AVX: yes"? That's a bug in has_avx(). For some reason the code you inherited returns yes if CPU either has AVX or OSXSAVE flag. Fix — https://github.com/hmage/cpuminer-opt/commit/5975fcf2ecad7057a254cc358e55434059124971

I looked into this a bit more and there is more to this bug than I first thought. The way the flags are defined is illogical
and does not agree with the wikipedia reference with no explanation for the discrepency. The coding does not seem
like a typical error. That's not the kind of definition you do by mistake. This bizarre definition also applies to the FMA3
flag. These flags are used in best_cpu_feature function so one would think that if anyone ever used that function
they might have noticed some bizarre results.

That is all to say there might be some legitimacy to the way the flags are defined. I noted in the wikipedia article that
the bit definitions were as of 2011. This suggests that the flags were different prior to 2011 which includes westmere.

Even if the coding is legitimate I would not have done it that way. I woul dhave defined the bits individually and
only used the compound expression when they were being read.

I'm not convinced it is a bug. It may be a relic of a previous CPUID format. But it's a moot point because I don't intend
to revisit this issue without a breakthrough.

[Roolieman]

sry just saw it on the first page.

Westmere Xeon E5649 now works fine, 2 CPU's are throwing ~700kH/s (using cpuminer.exe)

Sandybridge build on i5-2500K gets ~250kH/s

Older Xeon's E5540 (Gainestown) with only SSE2 support are starting miner but crashes every time after receiving first data (using cpuminer.exe)

Checking CPU capatibility...
        Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz
   CPU arch supports AES-AVX...NO.
   CPU arch supports SSE2.....YES.
YES.
Starting mining without AES-AVX optimizations...

Thank you for your testing, the crash of Gainstown is expected because it has no AES whatsoever. This proves
the Westmere build is not compatible with core2, another significant data point.

cpuminer-opt does work on core2 on linux (all algos) and Windows (all except hodl). This I have tested. You will
either have to compile your own with -march=native or ask CMB to do it for you.

Can you post the capabilities check results from the Westmere CPUs?

Here you go, Westmere capabilities check:

Checking CPU capatibility...
        Intel(R) Xeon(R) CPU           E5649  @ 2.53GHz
   CPU arch supports AES-AVX...YES.
   SW built for AES-AVX........YES.
   Algo supports AES-AVX.......YES.
Start mining with AES-AVX optimizations...

[2016-06-02 23:18:22] Starting Stratum on stratum+tcp://xre.suprnova.cc:2114
[2016-06-02 23:18:22] 24 miner threads started, using 'x11evo' algorithm.

[joblo]

Here you go, Westmere capabilities check:

Checking CPU capatibility...
        Intel(R) Xeon(R) CPU           E5649  @ 2.53GHz
   CPU arch supports AES-AVX...YES.
   SW built for AES-AVX........YES.
   Algo supports AES-AVX.......YES.
Start mining with AES-AVX optimizations...

[2016-06-02 23:18:22] Starting Stratum on stratum+tcp://xre.suprnova.cc:2114
[2016-06-02 23:18:22] 24 miner threads started, using 'x11evo' algorithm.

Thanks, more good info.

Based on the current implementation of the capabilities check, the fact the miner didn't crash
and the hash rate you're getting I believe you are mining with AES on that Westmere.

That changes things. I'm going to have to review previous data to see if it is consistent with this
new data. I'll also wait for more new data from other users.

[Epsylon3]

whitespace cleaner tool

Code:

alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"

[NeuroticFish]

Thanks for your fix, but it's still not working.



I get this and then crash. It's the same for nist5 and cryptonight.

[Epsylon3]

Your build doesnt look like the current git..

Code:

         **********  cpuminer-opt 3.3.4  ***********
...
Checking compatibility of this cpuminer and CPU (      Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz)
   cpuminer expects SSE2:           YES.
   cpuminer expects AES:            YES.
   cpuminer expects AVX:            YES.
   CPU supports SSE2:               YES.
   CPU supports AES:                YES.
   CPU supports AVX:                YES.
   requested algo supports AES+AVX: YES.
[2016-06-03 12:07:29] Starting Stratum on stratum+tcp://pwr.suprnova.cc:4242
[2016-06-03 12:07:29] 8 miner threads started, using 'nist5' algorithm.
[2016-06-03 12:07:32] Stratum difficulty set to 0.00390625
[2016-06-03 12:07:32] pwr.suprnova.cc:4242 nist5 block 20459
...
[2016-06-03 12:09:44] CPU #7: 3423.36 kH, 189.56 kH/s
[2016-06-03 12:09:44] accepted: 10/10 (100%), 35.45 MH, 1500.14 kH/s yes!
[2016-06-03 12:10:04] pwr.suprnova.cc:4242 nist5 block 20464

[USScrypto]

Nahalem CPUs like the i7 920 do NOT have AES supprot...

[ljglug]

 xeon e5 2670 X2 @361K  HMQ1725

This speed is not abnormal?

[joblo]

Thanks for your fix, but it's still not working.



I get this and then crash. It's the same for nist5 and cryptonight.

Thank you very much. This is important information. As mentioned in a subsequent post
your CPU actually uses the nehalem compile arch, the westmere build is incompatible.

This solves part of the mystery. There are two compile targets for 1st generation corei CPUs,
Nehalem which will not run the miners' AES code, and Westmere which will.

CMB has chosen to only support the AES optimizations with their binaries. I'm not sure why considering
the apparent interest, particularly with nehalem.

I continue to encourage Windows users to compile their own. That is always the best way

[hmage]

These flags are used in best_cpu_feature function.

That function isn't used anywhere. It's safe to delete it.

[hmage]

whitespace cleaner tool

Code:

alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"

To keep merge compatibility with joblo's google-drive dumps, I don't touch much. Cleaning up whitespace without joblo doing it in upstream will result in a lot of merge conflicts.

[joblo]

xeon e5 2670 X2 @361K  HMQ1725

This speed is not abnormal?

Yes.

[joblo]

whitespace cleaner tool

Code:

alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"

To keep merge compatibility with joblo's google-drive dumps, I don't touch much. Cleaning up whitespace without joblo doing it in upstream will result in a lot of merge conflicts.

What's the intended purpose? Whitespace is good.

[hmage]

whitespace cleaner tool

Code:

alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"

To keep merge compatibility with joblo's google-drive dumps, I don't touch much. Cleaning up whitespace without joblo doing it in upstream will result in a lot of merge conflicts.

What's the intended purpose? Whitespace is good.

Whitespace is good. Endspace at end of lines is not good. http://vim.wikia.com/wiki/Remove_unwanted_spaces

[joblo]

whitespace cleaner tool

Code:

alias trimfile="sed -r 's~[[:space:]]+\$~~g' -i"

To keep merge compatibility with joblo's google-drive dumps, I don't touch much. Cleaning up whitespace without joblo doing it in upstream will result in a lot of merge conflicts.

What's the intended purpose? Whitespace is good.

Whitespace is good. Endspace at end of lines is not good. http://vim.wikia.com/wiki/Remove_unwanted_spaces

So that command will only strip trailing whitespace, ok.

Edit: I ran the sed command on a test file and it did nothing, it didn't strip any whitespace.

[NeuroticFish]

Thank you very much. This is important information. As mentioned in a subsequent post
your CPU actually uses the nehalem compile arch, the westmere build is incompatible.

This solves part of the mystery. There are two compile targets for 1st generation corei CPUs,
Nehalem which will not run the miners' AES code, and Westmere which will.

For now I don't have the means and time to try my own compile, but whenever I can help with a run/test, just PM me and I'll give is a try.
And you... keep up the good work ! Thank you.

[joblo]

Ok, once more around the block with capabilities checks.

Edit: made some changes and added more examples.

Edit2: changed checking order to all AES variables first. For this quasi-debug release it
wil continue to perform all checks. The production version will only check SSE2 in AES fails.
For the debug release SSE2 support is taken literally but in the production version it will
mean (SSE2 && !AES) to the YES/NO response is more appropriate.

I am trying out a more detailed permissive check that will display all variables used
and hopefuly give an informative message to the user. I hope this balances out the need
for technical info and user-friendliness. The only risk is that the miner will always attempt
to mine and may crash if incompatible.

Here are some examples of the output most users are likely to see. I don't check for the newer features like AVX2
because they are not used in the decision making that determines the final message.

AES:

Code:

Checking CPU capatibility...
        Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
   CPU arch has AES...........YES.
   CPU arch has AVX...........YES.
   SW built for AES & AVX.....YES.
   Algo supports AES & AVX....YES.
   System supports AES & AVX..YES.
   CPU arch has SSE2..........YES.                   
   SW built for SSE2..........YES.
   System supports SSE2.......YES.
Start mining with AES-AVX optimizations...

SSE2:

Code:

Checking CPU capatibility...
        Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
   CPU arch has AES...........NO.
   CPU arch has AVX...........NO.
   CPU arch has SSE2..........YES.
   SW built for AES & AVX.....NO.
   SW built for SSE2..........YES.
   Algo supports AES & AVX....YES.
   System supports AES & AVX..NO.
   System supports SSE2.......YES.
AES not available, starting mining with SSE2 optimizations...

Nehalem CPU using Westmere build:

Code:

Checking CPU capatibility...
        Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
   CPU arch has AES...........YES.
   CPU arch has AVX...........NO.
   CPU arch has SSE2..........YES.
   SW built for AES & AVX.....YES.
   SW built for SSE2..........YES.
   Algo supports AES & AVX....YES.
   System supports AES & AVX..NO.
   System supports SSE2.......YES.
Unsupported CPU or SW configuration, miner will likely crash!

This will hopefully solve the issue for good. Only when this code has proven itself
will I consider turning enforcement back on.

At this time there are no pressing issues to prompt a new release. Too many releases in the past week.

I'll wait for more feedback from users especially those with 1st gen corei CPUs before releasing.
However I can provide the source code to those who can compile their own and are willing to share
their test results. This change only affects the CPU capabilities check at miner startup so if you don't
have any problems with that you don't need this and can wait for the general release.

[joblo]

Thank you very much. This is important information. As mentioned in a subsequent post
your CPU actually uses the nehalem compile arch, the westmere build is incompatible.

This solves part of the mystery. There are two compile targets for 1st generation corei CPUs,
Nehalem which will not run the miners' AES code, and Westmere which will.

For now I don't have the means and time to try my own compile, but whenever I can help with a run/test, just PM me and I'll give is a try.
And you... keep up the good work ! Thank you.

And thank you for the kind words. If you ever get the urge to try to compile your owm I'm here to help.

[Dabs]

I continue to encourage Windows users to compile their own. That is always the best way

How would I go about doing that? LOL. Is there a "free" Windows compiler out there? I have Xeon E5640.

I do have access to Visual Studio Community 2015; supposed to be the same as Professional without CodeLens.

On the other hand, is there some "newbie" guide to doing this with a fresh install of say, Debian 8.4? (Or would you recommend Ubuntu?)

I just made a Debian 8.4 VM. Maybe I'll do it over again.