Topic: [ANN]: cpuminer-opt v3.8.8.1, open source optimized multi-algo CPU miner - page 190. (Read 444067 times)

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 ;-)

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.

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.

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

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.

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

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.

Looks to compile okay up until this point:

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.

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


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 ?

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

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.

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.

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 want to thank you for all your hard work, without your work I'd still be stuck in the stone age. lol
I now can do the same hashrate on a laptop and one SR2 that I was getting with 3xSR2's and
one 32 core AMD rig and the bigger catch is I'm making more with much less power. Old scyptjane
miner was 1.38 hash 3xSR2 plus the AMD rig. I'm now seeing 1.5 hash on just a laptop & 1x SR2.  

I"m having a bit of a problem compiling on the AMD rig with errors. All same software but I may
need different library files on the AMD system? I had errors of missing files on the Intel systems
but those were easy found by what it posted the errors where about, but not so with the AMD system.
Of course the main OS that the VM sets on is Windows Server and could be playing apart with the errors.

Its been a really long day "up over 24h" now and I'm not at that rig so I will go into that more when I'm sure
to be able to give all the correct info. I'd like to make a donation to you for your hard work but that will
have to wait a bit only 0.2 BTC in my wallet at the moment, but once I get every thing swapped over that should change quickly.

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.

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.

Good point. The aesni check on an old cpu might return garbage results.

Hmmmm the check itself could be made of incompatible instructions.... every part of the code could. It's not just AES_NI but many other extensions as well.
You just can't compile for a pentium and expect it to run on a 386!