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

on both Linux 14.04 and 16.04    same error on lyr2z as on yescrypt

may i ask your native language ?

I'm having problems following your description, possibly a language issue.
Is this a problem only on one version of Ubuntu? What about lyra2z too?

thanks for reply ,  compiled as described used march-native    same effect   tried with cor2 ,btver1,btver2,barcelona    yescrypt isnt working , now i have seen  lyra2z too

other algos  working flawless with such a good hashrate
same machine same OS ,
on epsylon miner it work with plain compile   nothing need to do
:/build.sh   > ./configure > make    finished succesfull and working yescrypt algo     hmmm any idea ?

dont make you headache because me , i can easily switch    more for other they maybe hang on it

The key for cryptonight performance is cache size and AES performance. 16MB cache is good for 8 threads
but AMD implementations of Intel technology tend to be inferiour.

You'll have to build a good case for large pages. It looks like a lot of trouble with inconsistent results. Nicehash
experimented with it, how did that work out?

Edit: here are some of the questions that need answering in addition to a typical pro-con.

1. What is large pages exactly?

2. What are the OS issues, What changes are required to the OS?

3. Implementation issues, how much code needs changing?

4. User issues, do users need to be root/admin to run cpuminer with large pages?

5. Performance issues, are there conditions where large pages decreases performance?

If you have links to info that answers these questions that's good. I'm a bit skeptical about this
and don't feel like doing all the research work. It also gives me time to decompress after the
Lyra2 issues.

That's a segfault.

How did you compile, specifically what options? AMD is tricky to compile properly.

good news   finding the strange edge

but for me not as the best , yescrypt wont working on the Amd´ @ Linux  tried different releases , arches  nothing
doing first hash then stopped with error   ( invalid memory write )   something like this , need to find translation to English   sorry.  

tested with Athlon II x 250 , 255

linux 14.04 , gcc 4.8.4    other algos i tested worked but bit slower on this Distro

i´ll switch back to 16.04 and see what happen

it looks then like this
          **********  cpuminer-opt 3.5.7  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU: AMD Athlon(tm) II X2 255 Processor
CPU features: SSE2
SW built on Feb 15 2017 with GCC 5.4.0
SW features: SSE2
Algo features: SSE2
Start mining with SSE2

[2017-02-15 19:20:09] Starting Stratum on stratum+tcp://mine.zpool.ca:6233
[2017-02-15 19:20:09] 2 miner threads started, using 'yescrypt' algorithm.
[2017-02-15 19:20:16] Stratum difficulty set to 1 (0.00002)
[2017-02-15 19:20:16] yescrypt block 121780, diff 0.060
Ungültiger Maschinenbefehl (Speicherabzug geschrieben)
boss@boss-GA-MA785GMT-UD2H:~/joblo7$

Nevermind. I found the problem. I was not freeing aligned memory correctly which leads to
"unpredictable behaviour". That describes it well, very unpredictable. This means the workaround
I implemented in 3.5.6 didn't really fix anything, it only changed the unpredictable behaviour.

It also explains why, when I fixed one algo, it broke another.

All Lyra2 algos should be completely functional in the next release.

The update on cryptonight is that prefetching did not nave a significant impact with the non-aes version.
It looks like that version was not as I/O bound due to the overhead of implementing aes in SW.
I'll make the change anyway as it might help on some CPUs.

Ryzen will be a cryptonight hashing beast.

8 cores, 16MB cache

I hope you can look into the huge pages stuff.

-a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:3333 -u YOUR_WALLET_ADDRESS -p x 

can't connect to the pools. What was wrong?

Ok, Jobblo, good work and thak you for all these infos.

Lyra2re is going to be a problem. During work on 3.5.6 I would fix lyra2re and it
would break lyra2rev2 or vice versa. I ended up splitting them them up and I got
both working on Linux. I simply assumed they would also work on Windows, but...

The only way to have them both may be to roll back some optimizations but that's not
an option I'm willing to consider. My goal is to be at the leading edge and won't be
slowed down by an algo on life support.

There a a couple of other things I can try but if they don't work I may have to relegate
lyra2re to the legacy branch.

Edit: Things are not looking good. I can't seem to fix lyra2re on Windows without breaking
something else.

The last known working version is v3.5.5, it's unchanged from the legacy version 3.4.12.
However, it does not benefit from the improvements to lyra2 introduced in v3.5.6.

I hereby declare lyra2 unsupported on Windows going forward. It is recommended Windows
users use v3.4.12 , link available in OP. Linux users can continue to use new versions.

Lyra2rev2 and lyra2z are not affected.

It will reduce the compute power of AVX2 code which will affect some algos, mostly Lyra2 based algos, algos that use
cubehash (x11 family) and Hodl, essentially any algo that reports AVX2 capability. However, if an algo is I/O bound a small
loss in compute power may not affect the hashrate significantly. I'd think twice before buying one for mining.

Edit: I expect the performance to be equal to AVX, maybe a little better.

Edit: I don't know what will happen to AVX2 intrinsic or assembly code. If Ryzen doesn't recongize AVX2 instructions it may
have to rely on the compiler not to generate them. That won't work for hardcoded AVX2. If, on the other hand, Ryzen
internally converts them to their AVX equivalent that won't be a problem.

small question to joblo (or anyone competent in that field, im not )

i just read the following about upcoming ryzen arch:


if this turns out to be true, does it have an impact on mining speeds? i suppose yes

cheers

Lol, thanks mate, cheers  

Now I have to do it. It'll be in the next release. Thanks.

V.3.5.7 Linux  i7 2600  4 threads

confirming increase + 20 h/s  from previous release

[2017-02-14 23:03:16] CPU #1: 1918 H, 63.90 H/s
[2017-02-14 23:03:20] CPU #1: 266 H, 64.07 H/s
[2017-02-14 23:03:20] Accepted 11/11 (100%), 5431 H, 254.85 H/s, 59C
[2017-02-14 23:03:21] CPU #2: 356 H, 64.00 H/s
[2017-02-14 23:03:21] Accepted 12/12 (100%), 4423 H, 254.74 H/s, 60C
[2017-02-14 23:03:22] CPU #3: 421 H, 63.04 H/s
[2017-02-14 23:03:22] Accepted 13/13 (100%), 2947 H, 254.56 H/s, 60C
[2017-02-14 23:03:25] CPU #0: 568 H, 63.05 H/s
[2017-02-14 23:03:25] Accepted 14/14 (100%), 1611 H, 254.15 H/s, 61C


Great job , thx Joblo

That would be great, i have a few old servers that would benefit from that, if it's not too much of a hassle for you  

Sent you a beer

Address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
TxId: 1c55626d7c10feacec581988396b367171b18810dadf90ea110038701d274f7c

Keep up the good work 

Correct I only optimized the AES version. I can port it to the non-aes version, it's a simple copy paste.

Oh it crashes. You could have said so.

Seems to be a Windows problem with lyra2RE. I hate it when it works on Linux but not on Windows.
I'm looking into it.

joblo, not critical, but....forgotten lyra2re
http://prntscr.com/e8sqcd  ore  http://prntscr.com/e8sr0b
same on intel cpuminer-sse42.exe