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

I wouldn't use old direct links, I'd use the front page and download the current versions.

Take out "-t 2" and it will default to the number of cores in your CPU. Your i5s might work with a better build than core2, give
corei7 and corei7-avx a try.

I'm still tweaking the builds for older core-i CPUs, as you may have noticed by recent posts in this thread, so YMMV.

-t 4, or leave it to use all available cores


@joblo:

i have found this detailed guide: http://pastebin.com/p2cRgHxd

download packages are a bit old, should i use newer ones? all sf repos did not have newer ones

cheers

thanks QRV - I got my old i5s to work on cryptonight on nicehash

it only took 2 cores however

how do I get it to use all 4 cores?

start /high ?

Did you look at README.md. If you get stuck let me know where.

winbuild.sh will build for the native architecture "-march=native". My Windows bins were all compiled on haswell specifying
"-march=core-avx2" etc.

do you have by any chance a how to guide to setup the build environment on windows with mingw? i own amdfam10 and bdver1 hardware and can compile these targets (if the environment is setup it should be as easy as running winbuild.sh in msys shell i suppose)

i got to the point where i installed mingw32 (only "official" thing i found, mingw64 is hosted somewhere else and does not share the same installer and such) and the msys basics, but all READMEs mention one should install curl/ssl stuff in windows, have not found a good tutorial on this sadly

cheers

I've released v3.4.4b which reverts the changes to hodl. It was meant to fix a compile error on some early AES capable
CPUs but appears to be causing more problems than it solved. Windows binaries are unaffected.

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

Thanks, you also answered the question I forgot to ask, the performance was lower as I suspected. I going to shortly release
a patched version thet reverts the changes I made to hodl. It was done with incomplete information and appears to have
destabilized things.

Oddly my compiler doesn't accept brand names, only corei7-avx etc. I suscessfully compiled all targets except amdfam10.

sure thing, output is:   -march=                           ivybridge

miner compiled with march=core2, hashrate is a bit lower compared to 3.4.3 native compile

cheers

That's one of those CPUs from the early days of AES, this one doesn't have it. I presume you used -march=native,
that's the default in build.sh. Try -march=core2, that should work. Oddly every arch compiled for me but it was on
haswell HW.

Could you execute the following and tell me what it returns?

I gues it will be something like:

hi joblo, another problem:

the compile with build.sh on linux on a system without aes (i3-3120M) fails with


it seems this is since 3.4.4

cheers

Hi All - can anyone post a sample batch file for using this miner for mining at Nicehash? Many thanks

ok thanks

if you ever need direct access (ssh) to an amd system (the two cpus listed) to test code or something just pm me
unfortunately i dont think i have the skills needed to test this stuff myself

so long, great work
cheers

Sorry for the overtechnical explanation.

One of the big challenges is to write the best code for every CPU. That's not possible so different versions of the same functions
can be written and logic introduced to select the best one for a given CPU architecture. This logic can get quite complex. With just Intel
it's a linear problem. Only the top feature has to be identified, it can then be asumed that all lesser features are included.
When you add AMD to the equation that assumption no nonger applies.

I am still coming to grips with some of the pecularities of some early Intel AES CPUs. I'm hoping I can solve that one. AMD is going to
be more challenging, if not impossible, if similarly featured AMD CPUs perform diffferently than their Intel peers.

Lyra2 seems to be an extreme case because in some places the AVX code was only marginally better on Intel CPUs. A less efficient AVX implementation on AMD CPUs could actually make it slower.

My priorities are obviously going to be for the newest and most popular CPUs. It's also difficult to code for a CPU I can't test on.
If I ever get to trying to solve this issue, and that is unlikely, I would need a partner with the necessary CPU and the technical skills
to do the testing and report results.

It may be inconvenient for you but I suggest you choose whichever miner works best for each CPU. But you seem to have already
figured that out. 

im sorry if i did not fully understand everything, im not familiar with such low level code

avx is as fast as the scalar code and sometimes also requires the same amount of instructions, avx2 however is always faster
the cpus only have avx afaik

i took a look at the diff but im a bit lost there

whats the best thing to do in my case? if the "old" code that was faster on amd but slower on intel can not be integrated into the miner i will have to identify the slower algos and use the old version for these and newer versions for the other algos i suppose?

cheers

When I was doing the final tweaking of lyra I noticed that in some cases the AVX code required the same number of instructions
as the scalar code or that the AVX version appeared no faster than the scalar version. In fact there was one fucntion I did
not modify for AVX because it appeared to have no benefit. This is specific to AVX, AVX2 was always faster.

If your CPUs have only AVX it is possible the AMD implementation of it is less efficient that Intel's.

The reason for all this is the overhead in converting the data from scalar format to vector format and back again as AVX has
its own set of registers. With only a 2 to 1 gain with AVX instructions on lyra2 the AVX segment has to be big enough to overcome the
overhead. Short functions don't benefit as much.

If you want ot see what I'm talking about perform a diff on algo/lyra2/sponge.c.

As you know the situation with AMD and AVX is confusing and I don't think I could make it work perfectly even if I fully
understood it.

independently from this issue i noticed a medium decrease of lyra2re hashrate (not sure if other algos too) on amd cpu's using linux and the build.sh to compile the miner natively (3.4.1 vs 3.4.3/3.4.4)

fx 8320e went from 617kh/s to 550kh/s
a10-6800k went from 380kh/s to 359kh/s

current intel cpus however gained the noted slight lyra2re improvement of some 10-20kh/s

any idea why that is?

willing to test around with my setups if needed, can setup some ssh if needed

cheers

edit: this buffer overflow was the first of its kind, system setup software wise is identical on my systems, could only be hardware (old hdd)
i will just wait and see if it happens again

It apppears to have something to do with crypto but I have no idea what cpuminer code was running.

I'm also unfamiliar with how buffer overflow detection works on Linux. I didn't even know it existed and suspect
it involves special tools.

Since you have, presumably similar, systems that do work the key is to find out what is different between them.
Anythng from the host OS, the VM config, the guest OS, compile,  miner version, algo, anything that is different.
You could also try changing some variables, different algos, different cpuminer versions etc to try to change the
symptoms. Deciphering backtraces is difficult it should be fairly easy to identify if they are all identical. If you can
cause the symptoms to change it can lead you to what is causing it.

its also the first time i have seen this, im using ubuntu lxc container on debian (proxmox) everywhere and they are rock solid, no clue what is responsible for this.

so i suppose the printed mem map and stuff did not explain whats the issue?

cheers