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

[joblo]

I'm getting dizzy with all the direction changes. Now I'm on the mingw path to build a
windows version. Don't want to make any promises but if things go well there could be
a v3.1 soon with windows support.

I need some help with mingw on Linux. It compiles and builds cpuminer.exe bu it fails to
start because libcrypto-10.dll is missing.  I have mingw64-openssl-1.0.1j-1.fc20.noarch
installed and used the --with-crypto option so it looks ok on the linux end.

I installed openssl on windows and it still fails, seems libcrypto-10.dll wasn't included.

Google wasn't friendly. All kinds of people were offering the file but I know what that was about..

It's probably another noob issue but I need help with it.

Didn't someone tell me mingw was easy?

After peeling the onion with missing dll's  I ended up draggin along about ten of them.
But now there's something i've never seen.

cpuminer starts up but crashes on a call to parse-arg.  The function and the calls are all
in cpu-miner.c, there's nothng special about it just a simple function call. BUT wew nevr get
there. I have a printf on the line before the call to parse arg and another just inside the opening
brace in parse_arg and only one gets hit before the crash. Itg's crashing on a simple function call.

I dpn't know how to get past this.

I compiled sgminer on windows using mingw, it wasn't trivial but following the instructions I made it.
About your specific crash issue, is it code you wrote or modified, or was it there for long?
Maybe it's just some issue with memory allocation.

Tnaks for all your help Pallas, I reaklly apprecciate it even though I don't always say so.

The code that crashed was unchanged by me. It's part of the command line argument parsing
and I haven't gone near it. A hand written traceback looks like this:

parse_arg       <- crashes here beofre enterring parse_arg
parse_cmdline
main

I can't see it being a run time issue, it happened on two PCs. It must be a compile issue,
a reproduceable compile issue. The same code runs fine in linux.

But it gets worse, much worse.

After installing mingw I couldn't compile for linux anymore even though it was
in another source tree where I had never run mingw. Somehow mingw took over my system and
I could only compile for windows.

I managed to recover by uninstalling mingw and doing a make distclean but there a few moments of
panic.

It's just too risky to pursue this at this point. When my nerves settle down I may try again in the safety
of a VM but windows support is going to have to wait a little longer.

[1715398315]

1715398315

[1715398315]

1715398315

[1715398315]

1715398315

[1715398315]

1715398315

[1715398315]

1715398315

[pallas]

Safer and easier: a VM with windows and mingw in it.
No visual studio, no conflicts ;-)

[bobben2]

Hi Joblo.
An update on cpuminer 3.0.2 on Core 2 duo.
I managed to get it going - at least mining X11.

Code:

Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-23 17:25:40] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-23 17:25:40] 2 miner threads started, using 'x11' algorithm.
[2016-01-23 17:25:41] Stratum difficulty set to 0.016
[2016-01-23 17:25:41] hashpower.co:3533 x11 block 652575
[2016-01-23 17:25:47] CPU #1: 43.13 kH/s
[2016-01-23 17:25:47] CPU #0: 43.13 kH/s
[2016-01-23 17:25:54] hashpower.co:3533 x11 block 652576
[2016-01-23 17:25:54] CPU #0: 43.07 kH/s
[2016-01-23 17:25:54] CPU #1: 43.07 kH/s

As you can see the hashrate is not great, and even worse (actually half) if I dont override the return from the has_sse2() function which doesnt work in this case.
Here is a list of the changes I did to get it working:

../cpuminer-opt-3.0.2/algo/aes_ni/groestl/groestl-intr-aes.h <- Added #ifdef HAVE_AESNI to exclude the aesni code from being compiled.
../cpuminer-opt-3.0.2/algo/aes_ni/echo512/hash.c  <- remove inline keyword. Also added #undef AES_NI
..//home/arve/cpuminer/joblo3.0.2/cpuminer-opt-3.0.2/algo/ <- remove inline keyword in
qubit-aes.c
quark-sse2.c
quark-aes.c
../cpuminer-opt-3.0.2/cpu-miner.c line 1947 force cpu_sse2 = true

In my opinion it should be possible to add a switch when running configure to disable-aesni ?

[joblo]

Hi Joblo.
An update on cpuminer 3.0.2 on Core 2 duo.
I managed to get it going - at least mining X11.

Code:

Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-23 17:25:40] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-23 17:25:40] 2 miner threads started, using 'x11' algorithm.
[2016-01-23 17:25:41] Stratum difficulty set to 0.016
[2016-01-23 17:25:41] hashpower.co:3533 x11 block 652575
[2016-01-23 17:25:47] CPU #1: 43.13 kH/s
[2016-01-23 17:25:47] CPU #0: 43.13 kH/s
[2016-01-23 17:25:54] hashpower.co:3533 x11 block 652576
[2016-01-23 17:25:54] CPU #0: 43.07 kH/s
[2016-01-23 17:25:54] CPU #1: 43.07 kH/s

As you can see the hashrate is not great, and even worse (actually half) if I dont override the return from the has_sse2() function which doesnt work in this case.
Here is a list of the changes I did to get it working:

../cpuminer-opt-3.0.2/algo/aes_ni/groestl/groestl-intr-aes.h <- Added #ifdef HAVE_AESNI to exclude the aesni code from being compiled.
../cpuminer-opt-3.0.2/algo/aes_ni/echo512/hash.c  <- remove inline keyword. Also added #undef AES_NI
..//home/arve/cpuminer/joblo3.0.2/cpuminer-opt-3.0.2/algo/ <- remove inline keyword in
qubit-aes.c
quark-sse2.c
quark-aes.c
../cpuminer-opt-3.0.2/cpu-miner.c line 1947 force cpu_sse2 = true

In my opinion it should be possible to add a switch when running configure to disable-aesni ?

That's great news after another difficult day trying to get windows working.
The generic kernel is pretty slow as shown in the performce charts. Support is
more about compatibility than performance. The sse2 kernels are looking
pretty good, relatively speaking.

It seems the SSE2 check fails on your core2 but when you force it the SSE2 kernel
runs fine. Is that correct?

I'll restore all the compiler directives, I had removed them LOL, when I was hacking and slashing
the code an focussed only on the top tier.

I'll follow up on your findings, thanks a lot.

Edit: Another dramatic turn of events, this time a positive one!

Reenabling the AESNI_NI defines (and the companion OPTIMIZE_SSE2 has unlocked a ton
more performance thaty had been hidden by chainsaw approach.

X11 is up to 865 from 720 on my i7-4790K, but things aren't perfect, I see some rejects.
Some of the exposed code may not be perfect and may require a scalple to cut out the
cancer.

I've got a lot of work to do but I'm back on track.

BTW thanks for the excelllent report, very clear, complete, and precise. I followed it like  a script.

---------------------------------------------------------

Edit:

It looks like the dramatic sped increase was due to an error on my part. It seems the #define AES_NI
I put in miner.h isn't being seen. I had to #define it in every file that uses it. Clumsy but it works.

I'm building a debug tarbar so you can do some better testing. It will require you to make some small
code changes. I will send a PM with a link to the file.

Here's how it works:

Default is to enable and respect all AES_NI checks.

Edit: changed default configuration for your convenience.

Will disable AES_NI because we already know your CPU can't handle it

To force disable AES_NI you have to do two things before compiling:
    - in cpu-miner.c:1945 hard code cpu_aesni to false
 - remove #define AESNI from all algos, grep -r AES_NI to find them all, sorry

To force disable SSE2
  - in addition to the steps above hard code cpu_sse2 to false

These changes will affect kernel selection only, the start up capability check is still performed but not enforced.
This should solve the compile problem you had and allow you to do more testing.
The ugly workarounds are for the debug load only. I will investigate a more user firendly implentation
before release. Any suggestions welcome, including why the algos don't pick up the #define in miner.h

The goals of the further testing:

1. confirm the capability of your core2 CPU

2. determine if cpuminer-opt can correctly identify your CPU's capability level and select the appropriate kernel

3. compare sse2 vs x86_64 performance.

The first two are pretty obvious The third will allow me to extrapolate an estimate of the hash deficit of SSE2 vs AES_NI
and split it into the HW component and software component. How much of the loss is due purely due to the lack of
AES_NI and how much is due to other CPU optimizations in the latest generation.

Thanks for the great work.

[zTheWolfz]

Looks to compile okay up until this point:

Code:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
                 from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: [color=red]error[/color]: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
 _mm_aeskeygenassist_si128 (__m128i __X, const int __C)
 ^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
  tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
       ^
Makefile:1819: recipe for target 'algo/cryptonight/cpuminer-cryptonight-aesni.o' failed
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:2682: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive][color=red] Error [/color]1
make[1]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:599: recipe for target 'all' failed
make: *** [all] Error 2
thewolf2@thewolf2-VirtualBox:~/Desktop/cpuminer-opt-3.0.2$ error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’[color=red]error[/color]: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’

[joblo]

Looks to compile okay up until this point:

Code:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
                 from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
 _mm_aeskeygenassist_si128 (__m128i __X, const int __C)
 ^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
  tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
       ^
Makefile:1819: recipe for target 'algo/cryptonight/cpuminer-cryptonight-aesni.o' failed
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:2682: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:599: recipe for target 'all' failed
make: *** [all] Error 2
thewolf2@thewolf2-VirtualBox:~/Desktop/cpuminer-opt-3.0.2$ error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’

That's interesting. The code decided to fail the compile. I've never seen that before.
What CPU?

I presume this is v3.0.2? No one else has reported this problem. I'll be releasing v3.0.3 soon I hope,
if bobben2's testing goes well. Meanwhile I'l take a look at the code and try to figure out what's going on.

Edit: I compared the code to Wolf0' original and nothing stood out. You could try downloading again maybe
the download was corrupt.

[zTheWolfz]

Looks to compile okay up until this point:

Code:

In file included from /usr/lib/gcc/x86_64-linux-gnu/5/include/x86intrin.h:43:0,
                 from algo/cryptonight/cryptonight-aesni.c:1:
algo/cryptonight/cryptonight-aesni.c: In function ‘ExpandAESKey256_sub2’:
/usr/lib/gcc/x86_64-linux-gnu/5/include/wmmintrin.h:87:1: error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’: target specific option mismatch
 _mm_aeskeygenassist_si128 (__m128i __X, const int __C)
 ^
algo/cryptonight/cryptonight-aesni.c:26:7: error: called from here
  tmp4 = _mm_aeskeygenassist_si128(*tmp1, 0x00);
       ^
Makefile:1819: recipe for target 'algo/cryptonight/cpuminer-cryptonight-aesni.o' failed
make[2]: *** [algo/cryptonight/cpuminer-cryptonight-aesni.o] Error 1
make[2]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:2682: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/thewolf2/.local/share/Trash/files/cpuminer-opt-3.0.2'
Makefile:599: recipe for target 'all' failed
make: *** [all] Error 2
thewolf2@thewolf2-VirtualBox:~/Desktop/cpuminer-opt-3.0.2$ error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’error: inlining failed in call to always_inline ‘_mm_aeskeygenassist_si128’

That's interesting. The code decided to fail the compile. I've never seen that before.
What CPU?

I presume this is v3.0.2? No one else has reported this problem. I'll be releasing v3.0.3 soon I hope,
if bobben2's testing goes well. Meanwhile I'l take a look at the code and try to figure out what's going on.

Yes v3.0.2 It has 4x 6124 HE 1.8Ghz CPU's OCed to 2358Ghz easy 300k+ PPD Folding at Home rig.
16x2GB GSkill ram 32GB quad channel memory set. 4x Hyper12 coolers.
Motherboard H8QGi+F w/ Tech Station w/ 64GB SSD HDD. Old picture below with AMD video card it now host a GTX660Ti
v3.0.2 compiled fine on the Intel CPU I have test with so far. So it could be a AMD thing.
http://www.cpu-world.com/CPUs/K10/AMD-Opteron%206124%20HE%20-%20OS6124VAT8EGO.html

http://www.superbiiz.com/detail.php?name=MB-H8QGIF&c=FR&pid=7cf0fe6d5b2d53d138f6a5a40fa803c7e448d1f83de651ede82ab086f2bcae9c&gclid=Cj0KEQiA5oy1BRDQh6Wd572hsfkBEiQAfdTPCggsWJEaG_HfIyWyY5szrIbLSFr5yVUv96QTKBmyJGoaAs068P8HAQ

[joblo]

I presume this is v3.0.2? No one else has reported this problem. I'll be releasing v3.0.3 soon I hope,
if bobben2's testing goes well. Meanwhile I'l take a look at the code and try to figure out what's going on.

Yes v3.0.2 It has 4x 6124 HE 1.8Ghz CPU's OCed to 2358Ghz easy 300k+ PPD Folding at Home rig.
16x2GB GSkill ram 32GB quad channel memory set. 4x Hyper12 coolers.
Motherboard H8QGi+F w/ Tech Station w/ 64GB SSD HDD. Old picture below with AMD video card it now host a GTX660Ti
v3.0.2 compiled fine on the Intel CPU I have test with so far. So it could be a AMD thing.
http://www.cpu-world.com/CPUs/K10/AMD-Opteron%206124%20HE%20-%20OS6124VAT8EGO.html

http://www.superbiiz.com/detail.php?name=MB-H8QGIF&c=FR&pid=7cf0fe6d5b2d53d138f6a5a40fa803c7e448d1f83de651ede82ab086f2bcae9c&gclid=Cj0KEQiA5oy1BRDQh6Wd572hsfkBEiQAfdTPCggsWJEaG_HfIyWyY5szrIbLSFr5yVUv96QTKBmyJGoaAs068P8HAQ

We'll that explains it. Wolf0 has used some scary optimization techniques that he got directly from Intel and
the compile failed in Intel code. My guess is it's a trick to prevent inlining on the competition's CPUs to make
their's look better. Good one.

[pallas]

Both 3.0.2 and Wolf0's cryptonight do compile fine on my amd fx.

[joblo]

Both 3.0.2 and Wolf0's cryptonight do compile fine on my amd fx.

But I've just discovered 3.0.2 cryptonight is broken.

I've prepared a debug build for bobben2 to address his compile problems on an older CPU
(not the same issue you replied to). I've got a start toa solution but I want to make sure
I've properly isolated the AES_NI code from the compiler. For now I need to #define the
swiitch in every file that references it even though it's #defined in miner.h which everyone
#includes. Probably just another noob mistake.

I think I can get configure to pass the swutch to the compile environment the same way
it does for the package version. I might even be able to get configure to determine the CPU
architecture on its own (it would have to be accurate) and make the whole process
transparent to the user. Otherwise it wold be an option to the configure script.

I'm learning but there are still areas where I seem to repeatedly make the same mistake.

[bobben2]

Hi Joblo.
An update on cpuminer 3.0.2 on Core 2 duo.
I managed to get it going - at least mining X11.

Code:

Checking CPU capatibility...
        Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
AES_NI: No.
SSE2: No, start mining without optimizations...

[2016-01-23 17:25:40] Starting Stratum on stratum+tcp://hashpower.co:3533
[2016-01-23 17:25:40] 2 miner threads started, using 'x11' algorithm.
[2016-01-23 17:25:41] Stratum difficulty set to 0.016
[2016-01-23 17:25:41] hashpower.co:3533 x11 block 652575
[2016-01-23 17:25:47] CPU #1: 43.13 kH/s
[2016-01-23 17:25:47] CPU #0: 43.13 kH/s
[2016-01-23 17:25:54] hashpower.co:3533 x11 block 652576
[2016-01-23 17:25:54] CPU #0: 43.07 kH/s
[2016-01-23 17:25:54] CPU #1: 43.07 kH/s

As you can see the hashrate is not great, and even worse (actually half) if I dont override the return from the has_sse2() function which doesnt work in this case.
Here is a list of the changes I did to get it working:

../cpuminer-opt-3.0.2/algo/aes_ni/groestl/groestl-intr-aes.h <- Added #ifdef HAVE_AESNI to exclude the aesni code from being compiled.
../cpuminer-opt-3.0.2/algo/aes_ni/echo512/hash.c  <- remove inline keyword. Also added #undef AES_NI
..//home/arve/cpuminer/joblo3.0.2/cpuminer-opt-3.0.2/algo/ <- remove inline keyword in
qubit-aes.c
quark-sse2.c
quark-aes.c
../cpuminer-opt-3.0.2/cpu-miner.c line 1947 force cpu_sse2 = true

In my opinion it should be possible to add a switch when running configure to disable-aesni ?

That's great news after another difficult day trying to get windows working.
The generic kernel is pretty slow as shown in the performce charts. Support is
more about compatibility than performance. The sse2 kernels are looking
pretty good, relatively speaking.

It seems the SSE2 check fails on your core2 but when you force it the SSE2 kernel
runs fine. Is that correct?

I'll restore all the compiler directives, I had removed them LOL, when I was hacking and slashing
the code an focussed only on the top tier.

I'll follow up on your findings, thanks a lot.

Edit: Another dramatic turn of events, this time a positive one!

Reenabling the AESNI_NI defines (and the companion OPTIMIZE_SSE2 has unlocked a ton
more performance thaty had been hidden by chainsaw approach.

X11 is up to 865 from 720 on my i7-4790K, but things aren't perfect, I see some rejects.
Some of the exposed code may not be perfect and may require a scalple to cut out the
cancer.

I've got a lot of work to do but I'm back on track.

BTW thanks for the excelllent report, very clear, complete, and precise. I followed it like  a script.

---------------------------------------------------------

Edit:

It looks like the dramatic sped increase was due to an error on my part. It seems the #define AES_NI
I put in miner.h isn't being seen. I had to #define it in every file that uses it. Clumsy but it works.

I'm building a debug tarbar so you can do some better testing. It will require you to make some small
code changes. I will send a PM with a link to the file.

Here's how it works:

Default is to enable and respect all AES_NI checks.

Edit: changed default configuration for your convenience.

Will disable AES_NI because we already know your CPU can't handle it

To force disable AES_NI you have to do two things before compiling:
    - in cpu-miner.c:1945 hard code cpu_aesni to false
 - remove #define AESNI from all algos, grep -r AES_NI to find them all, sorry

To force disable SSE2
  - in addition to the steps above hard code cpu_sse2 to false

These changes will affect kernel selection only, the start up capability check is still performed but not enforced.
This should solve the compile problem you had and allow you to do more testing.
The ugly workarounds are for the debug load only. I will investigate a more user firendly implentation
before release. Any suggestions welcome, including why the algos don't pick up the #define in miner.h

The goals of the further testing:

1. confirm the capability of your core2 CPU

2. determine if cpuminer-opt can correctly identify your CPU's capability level and select the appropriate kernel

3. compare sse2 vs x86_64 performance.

The first two are pretty obvious The third will allow me to extrapolate an estimate of the hash deficit of SSE2 vs AES_NI
and split it into the HW component and software component. How much of the loss is due purely due to the lack of
AES_NI and how much is due to other CPU optimizations in the latest generation.

Thanks for the great work.

The cpu check fails on this computer and I suspect cpuid has been disabled in the BIOS.  I will check when I get a chance.

I downloaded the code you sent.  I had to do the following mods to get it to compile.

1. Commented out #define AES_NI and Added #ifdef AES_NI to effectively comment out code in algo/cryptonight/cryptonight-aesni.c.
2. Added #undef AES_NI in algo/aesni/echo512/hash.c
since miner.h is not included.
3. Added #ifdef AES_NI_ON a lot of places in algo/aesni/groestl/groestl-intr-aes.h

After these changes, I could leave both
#define AES_NI
#define AES_NI_ON 1
in miner.h and it compiled/runs fine.

Hashrates:
With cpu_sse2 = false I get
[2016-01-24 13:05:53] CPU #0: 25.50 kH/s
[2016-01-24 13:05:53] CPU #1: 25.50 kH/s
Set to true:
[2016-01-24 13:06:36] CPU #0: 43.38 kH/s
[2016-01-24 13:06:36] CPU #1: 43.38 kH/s

EDIT: You might want to move the calls to has_aes_ni() and has_sse2() to the top of main()  and make the boolean flags
global.  So that these functions are not called every pass of the main loop.  No need to call these more than once 

[joblo]

The cpu check fails on this computer and I suspect cpuid has been disabled in the BIOS.  I will check when I get a chance.

I downloaded the code you sent.  I had to do the following mods to get it to compile.

1. Commented out #define AES_NI and Added #ifdef AES_NI to effectively comment out code in algo/cryptonight/cryptonight-aesni.c.
2. Added #undef AES_NI in algo/aesni/echo512/hash.c
since miner.h is not included.
3. Added #ifdef AES_NI_ON a lot of places in algo/aesni/groestl/groestl-intr-aes.h

After these changes, I could leave both
#define AES_NI
#define AES_NI_ON 1
in miner.h and it compiled/runs fine.

Hashrates:
With cpu_sse2 = false I get
[2016-01-24 13:05:53] CPU #0: 25.50 kH/s
[2016-01-24 13:05:53] CPU #1: 25.50 kH/s
Set to true:
[2016-01-24 13:06:36] CPU #0: 43.38 kH/s
[2016-01-24 13:06:36] CPU #1: 43.38 kH/s

EDIT: You might want to move the calls to has_aes_ni() and has_sse2() to the top of main()  and make the boolean flags
global.  So that these functions are not called every pass of the main loop.  No need to call these more than once 

I've di there was already some cpuid checks in the code that will all have to be consolidated/ It's not a priority
because the check is not expensive and is only really done at startup.

Your x86_64/SSE2 performance ratio is 25.0 / 43.38 = .58
my 4790K  is 266 / 472 = ,56

That's pretty close. If effect your CPU SSE2's performance is just as good as mine. My only advantage
is the addition of AES_NI and possibly higher power efficiency. There' slife in those old CPU yet.

I'll take some time to digest the rest of your report, I just woke up.

[pallas]

I can confirm that old intel cpus (>= core2) can have performance/power similar to much newer amd processors.
So don't buy amd cpus for mining... well... do not buy any cpu for mining ;-)

[joblo]

I can confirm that old intel cpus (>= core2) can have performance/power similar to much newer amd processors.
So don't buy amd cpus for mining... well... do not buy any cpu for mining ;-)

Agreed, just use what you already have, which is why I'm trying to suport older HW.

[joblo]

The cpu check fails on this computer and I suspect cpuid has been disabled in the BIOS.  I will check when I get a chance.

I downloaded the code you sent.  I had to do the following mods to get it to compile.

1. Commented out #define AES_NI and Added #ifdef AES_NI to effectively comment out code in algo/cryptonight/cryptonight-aesni.c.
2. Added #undef AES_NI in algo/aesni/echo512/hash.c
since miner.h is not included.
3. Added #ifdef AES_NI_ON a lot of places in algo/aesni/groestl/groestl-intr-aes.h

After these changes, I could leave both
#define AES_NI
#define AES_NI_ON 1
in miner.h and it compiled/runs fine.

Hashrates:
With cpu_sse2 = false I get
[2016-01-24 13:05:53] CPU #0: 25.50 kH/s
[2016-01-24 13:05:53] CPU #1: 25.50 kH/s
Set to true:
[2016-01-24 13:06:36] CPU #0: 43.38 kH/s
[2016-01-24 13:06:36] CPU #1: 43.38 kH/s

EDIT: You might want to move the calls to has_aes_ni() and has_sse2() to the top of main()  and make the boolean flags
global.  So that these functions are not called every pass of the main loop.  No need to call these more than once  

I've di there was already some cpuid checks in the code that will all have to be consolidated/ It's not a priority
because the check is not expensive and is only really done at startup.

Your x86_64/SSE2 performance ratio is 25.0 / 43.38 = .58
my 4790K  is 266 / 472 = ,56

That's pretty close. If effect your CPU SSE2's performance is just as good as mine. My only advantage
is the addition of AES_NI and possibly higher power efficiency. There' slife in those old CPU yet.

I'll take some time to digest the rest of your report, I just woke up.

I think I have something that works. I justhave to bundle it up and build another debug load for you.
It should run straight out of the box on your CPU.

But things aren't perfect. There are two problems I had to workaround.

The #define AES_NI in miner.h is not being seen in any files that reference AESNI. I therefore had
to add #define AES_NI in every file  with any reference to AES_NI code.

The other problem is that has_sse2() isn't working so I hard coded it.

I tested it 4 ways:

1. AES_NI defined and march=native: my normal environment

2. AES_NI defined and march=core2. this fails to compile as expected.

3. AES_NI not defined and march=native, this compiles but performs at SSE2 rates as expected

4. AES_NI not defined and march=core2. this simulates your environment and works at SSE2 rates
    as expected.

The only thing now is to confirm it works with the default build instructions on your machine and
performs at SSE2 levels.

Follow up items:

investigate why #define in miner.h not seen

Investigate has_sse2 failure

Investigate ways to define AES_NI from the configure command line,

It's currently setup so simulate a CPU without AES_NI and with SSE2

Edit: PM sent

[bobben2]

The cpu check fails on this computer and I suspect cpuid has been disabled in the BIOS.  I will check when I get a chance.

I downloaded the code you sent.  I had to do the following mods to get it to compile.

1. Commented out #define AES_NI and Added #ifdef AES_NI to effectively comment out code in algo/cryptonight/cryptonight-aesni.c.
2. Added #undef AES_NI in algo/aesni/echo512/hash.c
since miner.h is not included.
3. Added #ifdef AES_NI_ON a lot of places in algo/aesni/groestl/groestl-intr-aes.h

After these changes, I could leave both
#define AES_NI
#define AES_NI_ON 1
in miner.h and it compiled/runs fine.

Hashrates:
With cpu_sse2 = false I get
[2016-01-24 13:05:53] CPU #0: 25.50 kH/s
[2016-01-24 13:05:53] CPU #1: 25.50 kH/s
Set to true:
[2016-01-24 13:06:36] CPU #0: 43.38 kH/s
[2016-01-24 13:06:36] CPU #1: 43.38 kH/s

EDIT: You might want to move the calls to has_aes_ni() and has_sse2() to the top of main()  and make the boolean flags
global.  So that these functions are not called every pass of the main loop.  No need to call these more than once  

I've di there was already some cpuid checks in the code that will all have to be consolidated/ It's not a priority
because the check is not expensive and is only really done at startup.

Your x86_64/SSE2 performance ratio is 25.0 / 43.38 = .58
my 4790K  is 266 / 472 = ,56

That's pretty close. If effect your CPU SSE2's performance is just as good as mine. My only advantage
is the addition of AES_NI and possibly higher power efficiency. There' slife in those old CPU yet.

I'll take some time to digest the rest of your report, I just woke up.

I think I have something that works. I justhave to bundle it up and build another debug load for you.
It should run straight out of the box on your CPU.

But things aren't perfect. There are two problems I had to workaround.

The #define AES_NI in miner.h is not being seen in any files that reference AESNI. I therefore had
to add #define AES_NI in every file  with any reference to AES_NI code.

The other problem is that has_sse2() isn't working so I hard coded it.

I tested it 4 ways:

1. AES_NI defined and march=native: my normal environment

2. AES_NI defined and march=core2. this fails to compile as expected.

3. AES_NI not defined and march=native, this compiles but performs at SSE2 rates as expected

4. AES_NI not defined and march=core2. this simulates your environment and works at SSE2 rates
    as expected.

The only thing now is to confirm it works with the default build instructions on your machine and
performs at SSE2 levels.

Follow up items:

investigate why #define in miner.h not seen

Investigate has_sse2 failure

Investigate ways to define AES_NI from the configure command line,

It's currently setup so simulate a CPU without AES_NI and with SSE2

Edit: PM sent

Hi joblo,
The package you sent almost built out of the box, but only after I modified the build.sh
I removed the -p switch and added -march=native.

With your original build.sh, the following two files threw compiler errors:
1. algo/sse2/groestl/grso-asm.c    <- will not accept the -p switch.   Perhaps the function call is using too many registers when in profiling mode
2. algo/aes_ni/echo512/hash.c    <- tons of errors when not building with -march=native

After fixing build.sh the produced executable ran fine.
I also built on one of my Haswell I5s, but mining X11 shares never got accepted...

EDIT: It Does accept shares on my I5.  But the hash is much lower than the "standard" version (cpuminer-opt-3.0.2) -
84 vs 128 kH/s per thread.

[joblo]

I think I have something that works. I justhave to bundle it up and build another debug load for you.
It should run straight out of the box on your CPU.

But things aren't perfect. There are two problems I had to workaround.

The #define AES_NI in miner.h is not being seen in any files that reference AESNI. I therefore had
to add #define AES_NI in every file  with any reference to AES_NI code.

The other problem is that has_sse2() isn't working so I hard coded it.

I tested it 4 ways:

1. AES_NI defined and march=native: my normal environment

2. AES_NI defined and march=core2. this fails to compile as expected.

3. AES_NI not defined and march=native, this compiles but performs at SSE2 rates as expected

4. AES_NI not defined and march=core2. this simulates your environment and works at SSE2 rates
    as expected.

The only thing now is to confirm it works with the default build instructions on your machine and
performs at SSE2 levels.

Follow up items:

investigate why #define in miner.h not seen

Investigate has_sse2 failure

Investigate ways to define AES_NI from the configure command line,

It's currently setup so simulate a CPU without AES_NI and with SSE2

Edit: PM sent

Hi joblo,
The package you sent almost built out of the box, but only after I modified the build.sh
I removed the -p switch and added -march=native.

With your original build.sh, the following two files threw compiler errors:
1. algo/sse2/groestl/grso-asm.c    <- will not accept the -p switch.   Perhaps the function call is using too many registers when in profiling mode
2. algo/aes_ni/echo512/hash.c    <- tons of errors when not building with -march=native

After fixing build.sh the produced executable ran fine.
I also built on one of my Haswell I5s, but mining X11 shares never got accepted...

EDIT: It Does accept shares on my I5.  But the hash is much lower than the "standard" version (cpuminer-opt-3.0.2) -
84 vs 128 kH/s per thread.

[/quote]

Thanks very muchfor your testing. I have never used the build script so thanks for that too.

Your haswelll performnce was lower because I rigged AES_NI to always be false and force it
to use the SSE kernels.

Test Passed!

I'll have a new release out later today thanks to your testing.
Cryptonight support coming, and maybe one or two more.

[Epsylon3]

i got the same issue with the sse grso-asm.c with GCC 4.8.4 (ubuntu server 14.04.3 LTS)

look like the asm() style is incorrect

[joblo]

cpuminer v3.0.3 is released.

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

It fixes support for SSE2 capable CPUs, core2 family, and adds support for 2 more algos.

The build instructions have changed, a new option is required for SSE capable CPUs.
See the README.md file for details. See also the OP for more dtails about this release.

I seem to have lost some hash in a few algos. I'll have to try to find it or maybe I
smoked it.

I will now take a little break and recharge before diving in to Windows again. This will
likely be the last release in the 3.0 stream unless there are urgent issues or Windows
continues to be delayed.

A special thanks goes out to bobben2 for his excellent testing which helped solve the
SSE2 issues.

Enjoy

[joblo]

i got the same issue with the sse grso-asm.c with GCC 4.8.4 (ubuntu server 14.04.3 LTS)

look like the asm() style is incorrect

Thanks for popping in. I welcome and encourage your involvement.

Edit: I've nere like ubuntu, even before they changed their desktop.
I like Mint better but I still prefer the red hat family. If only I didn't have to
add extra repositories all the time. I like te init system better although
I'm still not comfortable with systemd. I flip flop betwen Fedora and Centos
depending on wether I need  the latest features.