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

[joblo]

Hi, I was trying to mine x11evo algo with my older Xeon 7030 (codename Paxville) processor, but it crashed.   HOdl is working fine. The processor has has sse2 and sse3 capabilities.

If you used the CMB binaries none of them support CPUs without AES, however cpuminer-opt does support
non-AES CPUs if you compile yourself. See README.md for instructions.

I have downloaded it from cryptomining-blog website. There is a sse2 executable which is working fine with other algos.

CMB hasn't compiled any builds for CPUs without AES. Some algos will still work on your CPU because they are not optimized
for AES. Please post the output at miner startup. If the algo says it has AES it will crash. If the algo doesn't have AES
it will work.

You will need to compile yourself to mine algos that have been optimized for AES. The instructions are in READSME.md.

[1714060074]

1714060074

[1714060074]

1714060074

[1714060074]

1714060074

[1714060074]

1714060074

[geenius]

Hi, I was trying to mine x11evo algo with my older Xeon 7030 (codename Paxville) processor, but it crashed.   HOdl is working fine. The processor has has sse2 and sse3 capabilities.

If you used the CMB binaries none of them support CPUs without AES, however cpuminer-opt does support
non-AES CPUs if you compile yourself. See README.md for instructions.

I have downloaded it from cryptomining-blog website. There is a sse2 executable which is working fine with other algos.

CMB hasn't compiled any builds for CPUs without AES. Some algos will still work on your CPU because they are not optimized
for AES. Please post the output at miner startup. If the algo says it has AES it will crash. If the algo doesn't have AES
it will work.

You will need to compile yourself to mine algos that have been optimized for AES. The instructions are in READSME.md.

Checking CPU capatibility...
                  Intel(R) Xeon(TM) CPU 2.80GHz
CPU features: SSE2 AVX AVX2
SW built on Jun  5 2016 with GCC 5.3.0
Build features: SSE2
Algo features: SSE2 AES
AES not available, starting mining with SSE2 optimizations...

I am a noob in compiling, I have never done it. I thought that you are interested 

[joblo]

Hi, I was trying to mine x11evo algo with my older Xeon 7030 (codename Paxville) processor, but it crashed.   HOdl is working fine. The processor has has sse2 and sse3 capabilities.

If you used the CMB binaries none of them support CPUs without AES, however cpuminer-opt does support
non-AES CPUs if you compile yourself. See README.md for instructions.

I have downloaded it from cryptomining-blog website. There is a sse2 executable which is working fine with other algos.

CMB hasn't compiled any builds for CPUs without AES. Some algos will still work on your CPU because they are not optimized
for AES. Please post the output at miner startup. If the algo says it has AES it will crash. If the algo doesn't have AES
it will work.

You will need to compile yourself to mine algos that have been optimized for AES. The instructions are in READSME.md.

Checking CPU capatibility...
                  Intel(R) Xeon(TM) CPU 2.80GHz
CPU features: SSE2 AVX AVX2
SW built on Jun  5 2016 with GCC 5.3.0
Build features: SSE2
Algo features: SSE2 AES
AES not available, starting mining with SSE2 optimizations...

I am a noob in compiling, I have never done it. I thought that you are interested 

Thanks, this is good info. It might help with the other problem being discussed.

[hmage]

Edit: I looked at the cpu_detect code and it uses cpuid at its heart. Howver, for AVX it also checks the XSAVE
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.

The logic in there is "AND" as requirement. Meaning both AVX and XSAVE have to be there. In cpuminer-opt it's "OR", meaning presence of either AVX or XSAVE will return has_avx()=true.

[My9bot]

get this error with 3.3.5

Code:

c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support for the \
  ^

Did you include CXXFLAGS="-std=gnu++11" in your configure?

thx for the hint

[joblo]

Edit: I looked at the cpu_detect code and it uses cpuid at its heart. Howver, for AVX it also checks the XSAVE
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.

The logic in there is "AND" as requirement. Meaning both AVX and XSAVE have to be there. In cpuminer-opt it's "OR", meaning presence of either AVX or XSAVE will return has_avx()=true.

That's not what you said earlier but you are now correct and I have already made the change.

[joblo]

CPUID status, will update with new info

Trying to fix a bug that isn't a bug just creates more bugs.

That's what happened with the AVX flag. The orignal implementation was correct. A detailed explanation
is avaiable in this file:

https://bitbucket.org/ariya/cpu-detect/src/cc2037e9bd0fb8cf12846dbfa4818fd813043972/base/cpu.h?at=master

So I've reverted.

The AVX2 flag isn't implemented by cpu-detect so I don't know if it requires the same logic ad AVX1. I will look into it further.

cpu_detect returns the AES flag directly from the cpuid register so it is still a complete mystery why it was misidentified
on the AMD Phenom2.

The owner of a Xeon without AES posted capabilities while attemting to use the CMB Westmere build and it showed some
interesting results. It correctly showed the CPU did not have AES but incorrectly displayed AVX and AVX2 as being
available.

This help define the problem, or should I say problems:

1. AVX shows available on non-AES CPU. This one might be understood and fixed with the correct reading of
this feature. I would need a volunteer with a non-AES CPU to test.

2. AES shows available on non-AES AMD CPU. Still a mystery but seems limited to AMD.

3. AVX2 shows available on non-AES CPUs. I have to reimplement this because it does not use cpuid.

I would like a volunteer or two because I don't like to publicly release code based on trial and error, which has
been happening for the past few releases. These volunteers would need to be able to compile their own, Windows
or Linux, doesn't matter. I hope I ave one volunteer already with an older AMD CPU. I would like a volunteer with
old Intel CPU particularly Westmere and Nehalem.

Investigation continues.

I found a bug in my implemetation of has_avx2, but it wasn't even being used in v3.3.5.

I'm going to put get_version back the way I found it and reimplement the parts I need.
I should have a test build avaiable later today if there are any volunteers.

Still no breakthrough of the AMD/AES issue.

[th3.r00t]

I would be nice if CPUz had open source so I could just copy their code. I found this, closest I found
to your CPU. Something I can work with to figure out what's wrong.

There's cpuid — http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz

Code:

wget http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz
tar xvf cpuid-20151017.src.tar.gz
cpuid-20151017/
make
./cpuid -1 | fgrep -i avx

@th3.rOOt, can you try this on your AMD, to see if it works? Thanks.

Edit: I looked at the cpu_detect code and it uses cpuid at its heart. Howver, for AVX it also checks the XSAVE
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.

This may help explain why AVX was misidentified, but there's also AES and AVX2. In cpu_detect there is no
mention of AVX2 and AES has no special handling. Did CPU AES get misindentified in previous releases?

The result on AMD Phenom II X4 940

Code:

urban@beast:~$ /home/urban/cpuid-20151017/cpuid -1 | fgrep -i avx
      AVX: advanced vector extensions         = false

[joblo]

I would be nice if CPUz had open source so I could just copy their code. I found this, closest I found
to your CPU. Something I can work with to figure out what's wrong.

There's cpuid — http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz

Code:

wget http://www.etallen.com/cpuid/cpuid-20151017.src.tar.gz
tar xvf cpuid-20151017.src.tar.gz
cpuid-20151017/
make
./cpuid -1 | fgrep -i avx

@th3.rOOt, can you try this on your AMD, to see if it works? Thanks.

Edit: I looked at the cpu_detect code and it uses cpuid at its heart. Howver, for AVX it also checks the XSAVE
bit (the ones hmage thinks are a bug) and also checks a kernel var for XSAVE, not done by cpuminer-opt.

This may help explain why AVX was misidentified, but there's also AES and AVX2. In cpu_detect there is no
mention of AVX2 and AES has no special handling. Did CPU AES get misindentified in previous releases?

The result on AMD Phenom II X4 940

Code:

urban@beast:~$ /home/urban/cpuid-20151017/cpuid -1 | fgrep -i avx
      AVX: advanced vector extensions         = false

Thanks. I think I have AVX and AVX2 fixed. Now I'll dig into AES a bit more.
Edit: Tested AVX2 on my Sandybridge, test passed. I don't have the HW to test AVX.

Edit2: I have a theory about AES. AMD implemented the AES flag in CPUID in Sep 2010.

https://support.amd.com/TechDocs/25481.pdf

Prior to its implementation it would be undefined. There is a backup, CPUID has a Highest Feature Function
which will return the latest available feature. If AMD has implemented that I may be able to work around
the AES flag issue and get something that works.

[joblo]

I am preparing a debug build to test some changes and collect more data.
I need a couple of volunteers to test specific changes I can't test myself.
Volunteers should be able to compile, Windows or Linux, doesn't matter.

AVX2 is should be fixed. I tested AVX2 on a Sandybridge.

AVX is hopefully fixed but I can't test it. I need a volunteer with a Westbridge CPU.

I added a call to get_highest_function just to see what it displays. It returns the family name
but they don't line up with -march. For example GHF returns Skylake or Ivybridge but not Haswell
or Sandybridge.

GHF seems to be implemented on AMD CPUs after 2010 but there is no detail so I have no idea what
to expect. I tried it on my Skylake and it said Skylake  but I need a volunteer with an AMD, prefereably
An AMD that has been known to be difficult and someone with a, sort of, Linux reference in their nik.

I will include a link to this article to make it easier to post your results. You know what I'm looking for
so don't make me ask.

Edit: I tested GHF on a couple of other machines and both my haswell and sandybridge returned ivybridge.
This will clearly be of no use because the range of ivybridge spans two compile architectures.
But it's included just as a curiosity.

[ReiMomo]

It crashes with Cryptonight. I have an i7 4770K.

[joblo]

It crashes with Cryptonight. I have an i7 4770K.

What file or self compile? Can you post ouput displayed at startup?

Edit: just tried it on my i7 6700K and no problems.

[antonio8]

Using the build from crypotoblog as I am on Windows 7 64bit and have a i7 4790k (haswell).

When using the cpu miner- cpuminer-haswell-broadwell the miner will not run but it does with just cpuminer and cpuminer-sse2 on 3.3.5 and 3.3.4. I have no idea why it does not work on the first.

[hmage]

That's not what you said earlier but you are now correct and I have already made the change.

You might have a case of selective memory, because this is exactly what I said earlier:

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.

Bolded the "or" for you.

[ReiMomo]

It crashes with Cryptonight. I have an i7 4770K.

What file or self compile? Can you post ouput displayed at startup?

Edit: just tried it on my i7 6700K and no problems.

Video
http://tinypic.com/player.php?v=14jz284%3E&s=9#.V1SzM2fmpkg

I'm using the one from cryptomining-blog.
With this line: cpuminer-haswell-broadwell -a cryptonight --benchmark

[joblo]

It crashes with Cryptonight. I have an i7 4770K.

What file or self compile? Can you post ouput displayed at startup?

Edit: just tried it on my i7 6700K and no problems.

Video
http://tinypic.com/player.php?v=14jz284%3E&s=9#.V1SzM2fmpkg

I'm using the one from cryptomining-blog.
With this line: cpuminer-haswell-broadwell -a cryptonight --benchmark

Thanks, I watched the video and it helped. I've reproduced the problem with the CMB binaries and also by compiling
myself on Windows. As mentioned previously it works on my Skylake with Linux so it seems it's limited to Windows.

Anyways I have some work to do. In the meantime you can use Wolf0's cryptonight miner, windows binaries avaialble.
It shouldn't be too hard to find on github.

I have a lot of work to do. I haven't touched cryptonight in a long time and may not have tested it when I started
supporting Windows.

[joblo]

cpuminer-opt v3.3.5 is available.

Fixed hodl on Windows with non-AES CPUs. New build procedure for Windows, see README.md.
This fix is only significant for Windows users who compile their own on non-AES CPUs. Cryptomining
Blog does not build binaries for non-AES CPUs.

Rewrote CPU capabilities check to provide more info and be less verbose. It is implemented in permissive
mode meaning that mining will always be attempted. The miner may crash or perform at less than optimum.

This should close any remaining issues for now. It is recommended that all users upgrade even those who don't
like to update every release.

Download source:

https://drive.google.com/file/d/0B0lVSGQYLJIZVVp5aGxFVm1qVE0

Check CMB or OP for Windows binaries availability.

Cryptomining Blog has now included an SSE2 build.

http://cryptomining-blog.com/wp-content/download/cpuminer-opt-3-3-5-windows.zip

[joblo]

That's not what you said earlier but you are now correct and I have already made the change.

You might have a case of selective memory, because this is exactly what I said earlier:

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.

Bolded the "or" for you.

Faulty maybe, but not selective.

As it turns out (bitwize) anding them and testing for zero doesn't work either. Have to test each bit seperately.

[hmage]

Bad choice of words, sorry.

[th3.r00t]

I am preparing a debug build to test some changes and collect more data.
I need a couple of volunteers to test specific changes I can't test myself.
Volunteers should be able to compile, Windows or Linux, doesn't matter.

AVX2 is should be fixed. I tested AVX2 on a Sandybridge.

AVX is hopefully fixed but I can't test it. I need a volunteer with a Westbridge CPU.

I added a call to get_highest_function just to see what it displays. It returns the family name
but they don't line up with -march. For example GHF returns Skylake or Ivybridge but not Haswell
or Sandybridge.

GHF seems to be implemented on AMD CPUs after 2010 but there is no detail so I have no idea what
to expect. I tried it on my Skylake and it said Skylake  but I need a volunteer with an AMD, prefereably
An AMD that has been known to be difficult and someone with a, sort of, Linux reference in their nik.

I will include a link to this article to make it easier to post your results. You know what I'm looking for
so don't make me ask.

Edit: I tested GHF on a couple of other machines and both my haswell and sandybridge returned ivybridge.
This will clearly be of no use because the range of ivybridge spans two compile architectures.
But it's included just as a curiosity.

I'm volunteering for testing.
Can test on AMD (SSE2, no AVX) both Windows and Linux, aswell on Core i7-4790K (AVX) on Linux and AMD FX-7600P (AVX) on Windows.