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

[joblo]

Again, it seems you got me all wrong, English is not my

W7-64-pro

MAC- AMD Intel
Git miner exit after 50 submits.
Git + code change in cpu-miner.c - work

Code:

if (rpc_pass && rpc_user)
     opt_stratum_stats &= (strstr(rpc_pass, "stats") != NULL) || (strcmp(rpc_user, "benchmark") == 0);

I collected everything under the window, not under linux (( Excuse me, I did not say immediately

Thanks for the clarification. Let me absorb it for a bit so I can understand.

Edit: OK the git test is valid but the git+code change test is invalid because stats collection was disabled.
The conclusion is the change I made in 3.5.5-pre (git) did not fix the problem. Is that correct?

a yes from me (judging from the git pre bin you sent)

i can give you teamviewer access to one amd windows machine for rapid testing if neccessary

Another try with logic:

1.1. felix reports x11evo
   1.1.1 works on Intel/Linux,
   1.1.2 fails on Intel/Win
   1.1.3 fails AMD/Linux
   1.1.4 fails AMD/Win

1.2 olddin reports x11evo
   1.2.1 not tested on Intel/linux
   1.2.2 work on Intel/Win
   1.2.3 not tested on AMD/Linux
   1.2.4 fails on AMD/Win

1.3. joblo reports x11evo
   1.3.1 works on Intel/Linux
   1.3.2 works Intel/WIN
   1.3.3 AMD Linux not tested
   1.3.4 AMD Win not tested.

2.1 felix reports timetravel
   2.1.1 works on Intel/Linux
   2.1.2 works Intel/Win
   2.1.3 AMD/Linux?
   2.1.4 fails on AMD/Win

2.2 olddin reports timetravel
   2.2.1 Intel/linux not tested
   2.2.2  fails Intel/Win
   2.2.3  AMD/Linux not tested
   2.2.4 fails AMD Win

2.3 joblo reports timetravel
   2.3.1 works Intel/linux
   2.3.2 works Intel/Win
   2.3.3 AMD/Linux not tested
   2.3.4 AMD/Win not tested

if the statements are correct there are a couple of discrepencies.

1.1.2 contradicts 1.2.2 and 1.3.2, felix and oldin disagree, joblo agrees with oldin
2.2.2 contradicts 2.1.2 and 2.3.2, felix and oldin disagree, joblo agrees with felix

I need a break, my brain hurts

Edit: in case architecture becomes relevent my test rigs are:

Intel Linux AVX2
Intel Win AVX2
Intel Linux AVX

They all work for both algos

[m1n1ngP4d4w4n]

Mine hurt just reading your post lol, good luck man, this one seems to be a pickle  

If you need more people testing, gimme a holler, i'll do some

[felixbrucker]

1.1. felix reports x11evo
   1.1.1 works on Intel/Linux,
   1.1.2 fails on Intel/Win
   1.1.3 fails AMD/Linux
   1.1.4 fails AMD/Win

amd/linux is untested from my side as i dont have my amds on linux unfortunately


on every machine (amd/intel) on windows the corei7-avx arch was used, on linux its not defined (build.sh used) and the own arch of the cpu (xeon e3-1265lv2) is used (it has avx but no avx2)

1.3. joblo reports x11evo
   1.3.1 works on Intel/Linux
   1.3.2 works Intel/WIN
   1.3.3 AMD Linux not tested
   1.3.4 AMD Win not tested.

interesting, so it indeed works on your intel in win, very strange

[felixbrucker]

joblo
 -"x11evo"
Checked on version 3.5.1 - it works on amd and intel well
version 3.5.5 - all rejects

-"MAC"
Yes, v 3.5.5 with code

Code:

if (rpc_pass && rpc_user)
     opt_stratum_stats &= (strstr(rpc_pass, "stats") != NULL) || (strcmp(rpc_user, "benchmark") == 0);

works good

remind-fx-6300, i3-2120

actually i believe 1.2.2 is also fail

[joblo]

joblo
 -"x11evo"
Checked on version 3.5.1 - it works on amd and intel well
version 3.5.5 - all rejects

-"MAC"
Yes, v 3.5.5 with code

Code:

if (rpc_pass && rpc_user)
     opt_stratum_stats &= (strstr(rpc_pass, "stats") != NULL) || (strcmp(rpc_user, "benchmark") == 0);

works good

remind-fx-6300, i3-2120

actually i believe 1.2.2 is also fail

You're right. So you both agree on 1.2 but I don't. I believe we have the same Intel architecture but different results.
I can workaround Timetravel by disabling stats by default but it looks like x11evo is going to be a lottery.

Felix, can you retest timetravel with older releases on AMD/Win?. Significant changes were made every release since
it was introduced. It might help to find in what release it broke for you, or if it was always broke.

[felixbrucker]

regarding arches: im avx only (also tested sse2 only), your windows intel setup is avx2 iirc

you could test your intel setup with sse2 bin to verify its working for you on win/intel

[felixbrucker]

Felix, can you retest timetravel with older releases on AMD/Win?. Significant changes were made every release since
it was introduced. It might help to find in what release it broke for you, or if it was always broke.

sure, do you by any chance have the link handy someone posted a while ago with all the builds (or was it only src?) ?

else some bins folder link would be great, i currently only store the latest version in my git bin repo

[joblo]

Felix, can you retest timetravel with older releases on AMD/Win?. Significant changes were made every release since
it was introduced. It might help to find in what release it broke for you, or if it was always broke.

sure, do you by any chance have the link handy someone posted a while ago with all the builds (or was it only src?) ?

else some bins folder link would be great, i currently only store the latest version in my git bin repo

Will do both.

Here are the links to older versions.

https://drive.google.com/file/d/0B0lVSGQYLJIZLVlyeWEwelkxMDQ/view?usp=sharing
https://drive.google.com/file/d/0B0lVSGQYLJIZV0V4NURXMS1pUXc/view?usp=sharing
https://drive.google.com/file/d/0B0lVSGQYLJIZSUp0SUV2b0F6Sjg/view?usp=sharing

x11evo is broken in 3.5.2 &3.5.3 and timetravel isn't availble in 3.5.1 so skip those.

Will update with test results on my avx2/win using the avx build I built for you.

Edit:

Some progress.

Timetravel works on 17-4790K (AVX2) Windows using 3.5.5-pre AVX as well as 3.5.4 AVX2. It continues
after 50 submits and stats message.

x11evo fails on the same machine with 3.5.5-pre AVX and 3.5.4 AVX2 .

Now that I can reproduce the failure on x11evo I have something to work with.  
Timetravel is still a mystery.

Edit: interesting point is the failures were different on x11evo with both loads. With AVX it failed
like you reported with a flood of rejects. With AVX2 the rejects were produced at a normal rate.

[felixbrucker]

amd/win corei7-avx:

3.5.2: timetravel: exits after 50 accepted shares
3.5.3: timetravel: exits after 50 accepted shares
3.5.4: timetravel: exits after 50 accepted shares
3.5.5-pre: timetravel: exits after 50 accepted shares

3.5.1: x11evo: works
3.5.2: x11evo: just exits
3.5.3: x11evo: just exits
3.5.4: x11evo: flooding rejects
3.5.5-pre: x11evo: flooding rejects


regarding timetravel and intel/win: it is expected to work, only amd doesnt work

Edit: interesting point is the failures were different on x11evo with both loads. With AVX it failed
like you reported with a flood of rejects. With AVX2 the rejects were produced at a normal rate.

interesting indeed, might give you something to work with

[joblo]

amd/win corei7-avx:

3.5.2: timetravel: exits after 50 accepted shares
3.5.3: timetravel: exits after 50 accepted shares
3.5.4: timetravel: exits after 50 accepted shares
3.5.5-pre: timetravel: exits after 50 accepted shares

3.5.1: x11evo: works
3.5.2: x11evo: just exits
3.5.3: x11evo: just exits
3.5.4: x11evo: flooding rejects
3.5.5-pre: x11evo: flooding rejects


regarding timetravel and intel/win: it is expected to work, only amd doesnt work

Edit: interesting point is the failures were different on x11evo with both loads. With AVX it failed
like you reported with a flood of rejects. With AVX2 the rejects were produced at a normal rate.

interesting indeed, might give you something to work with

Ok so the timetravel problem existed since I first implemented it. Another new lead.

I'm working on backing out some of the more aggressive optimizations from x11evo that provided
only small improvement. Those same aggressive optimizations are used in many other algos.
I fear there may be problems with other algos as well.

It may be that both x11evo and timetravel suffer from the same root cause [Edit: not likely if
timetravel broken in 3.5.1], and there may be other algos affected in different ways with different
combinations of CPU and OS.

I'll update when I've tested more.

[joblo]

I have a better definition of the x11evo problem. It was last know to work in 3.5.1.
In 3.5.2 I broke it with the swap macro in the x11 evo code. In 3.5.3 a code change
not in x11evo code broke it further. Fixing the swap macro bug still left the new bug.

I went back to 3.5.2 with x11evo.c from 3.5.1 and it works. I now have a starting point.
I just have to find what in 3.5.3 broke it again.

Edit: progress

x11evo from 3.5.4 works in 3.5.2 so the big optimization for x11evo is ok.
But that means the problem is in code used by many algos so it's going to
be harder to find.

[integrale]

look at this !

./cpuminer -x11evo -o stratum+tcp://mine.zpool.ca:3553 -u 1Cjq5f4ASXL5CpURWThYeNbtyB4ph98ex8 -p x

         **********  cpuminer-opt 3.5.5-pre  ***********
     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 = i7 2600

./cpuminer: no algo supplied
Try `cpuminer-opt --help' for more information.
sklave@miner-HP-Compaq-8200:~/joblo5p$


curious , on Core 2 it hashes   but no shares until now ca. 10 minutes each core shows around 4.5 mh/s
timetravel works great on all my Cpu´s

i7 2600 - core 2 e6600 - core 2 e6700     no problems nor troubles they all sharp like an Katana

[joblo]

look at this !

./cpuminer -x11evo -o stratum+tcp://mine.zpool.ca:3553 -u 1Cjq5f4ASXL5CpURWThYeNbtyB4ph98ex8 -p x

         **********  cpuminer-opt 3.5.5-pre  ***********
     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 = i7 2600

./cpuminer: no algo supplied
Try `cpuminer-opt --help' for more information.
sklave@miner-HP-Compaq-8200:~/joblo5p$


curious , on Core 2 it hashes   but no shares until now ca. 10 minutes each core shows around 4.5 mh/s

you forgot -a

don't bother testing x11evo anymore, I'm chasing down a problem.

[integrale]

sorry for that mistake , it´s late   omg

[joblo]

More progress wih x11evo.

I have it working on Win with most of the optimizations to it and other algos intact.
I started with 3.5.2 as a baseline then ported back the optimizations from 3.5.3 and 3.5.4
including the original x11evo fix and large optimization.

I don't know exactly what code broke it but I found 2 hash functions broken that worked
fine on Linux as well as other algos on Win.

I still need to do a performance comparison with 3.5.4 and possibly try to reimplement additional
optimizations to recover any lost speed without breaking it again.

No ETA for 3.5.5.

Edit: I broke it again. The x11evo optimization from 3.5.4 just won't work on Windows.

This works on both Windows and Linux

Code:

void evocoin_twisted_code( char *result, char *code )
{
    uint32_t h32, *be32 = get_stratum_job_ntime();

        h32 = be32toh(*be32);
        uint32_t count = getCurrentAlgoSeq(h32, INITIAL_DATE);
        getAlgoString(code, count);
        sprintf(result, "_%d_%s_", count, code);

}

This doesn't work on Windows but works on Linux

Code:

static __thread uint32_t saved_ntime = UINT32_MAX;

void evocoin_twisted_code( char *result, char *code )
{
    uint32_t h32, *be32 = get_stratum_job_ntime();

    if ( *be32 != saved_ntime )
    {
        h32 = be32toh(*be32);
        uint32_t count = getCurrentAlgoSeq(h32, INITIAL_DATE);
        getAlgoString(code, count);
        sprintf(result, "_%d_%s_", count, code);
        saved_ntime = *be32;
    }
}

[joblo]

I think I've gone as far as I can with x11evo and windows.

There is no windows targeted code in the function. The only suspicious code, betoh, is also called
in the working case. betoh is defined in a system library, with no local copies in the application.

There is nothing suspicious in the code additions that trigger the rejects. It's a simple if statement.
Using thread-safe variables works in other algos on windows.

The logic is sound nearly fail safe. If it fails true it loses the otimizations. If it fails false it won't
recalculate the permutation for a new ntime. I have confirmed the first pass triggers a new permutation
to be calculated so the first block should work. Only if the second block is not properly detected should
the miner start producing rejects. But it always produces rejects from the start

I tried disabling some compiler optimizations.

I tried rewriting the function in different ways, getting ntime from the threaded work.data instead of
global stratum.

I tried running cpuminer from msys shell as well as from dos with bundled DLLs. Neither work.

At this point I think I've eliminated anything related to the miner, which is as far as I'm willing to go
at this point.

The next step would be to compare assembly code between windows and linux. It should be identical, if not
it may be a compiler issue. On the other hand if the assembly code is identical the problem must lay
elsewhere in the system.

Although it would be a good way to get up to speed on x86 assembly it doesn't help solve the issue with
cpuminer-opt and x11evo.

I will implement a workaround to disable the optimization in twisted_code on Windows platforms.
This should work but so should have the optimization on Windows, The impact of this is x11evo
will perform slower on windows, the same rate as in 3.5.1. On linux it will benefit from the higher
hashrates in 3.5.4.

[joblo]

cpuminer-opt-3.5.5 is released.

x11evo is fixed on Windows but performs at the same hash rate as 3.5.1. Linux users
get the optimizations from 3.5.4.

AMD users reported that in 3.5.4 timetravel exitted after 50 submits. There are two parts to
this problem. First the stats were being collected by default, second doing so resulted in the
miner exitting.

The default has been changed to disable stats collection by default and must be enabled by
including the word stats in the password. Stats collection has not been tested in 3.5.5 on
an AMD CPU therefore it may still cause the miner to exit if enabled. AMD user are encouraged
to report their findings.

See OP for details.

[felixbrucker]

thanks for this


small note: the windows bin for sse2 was renamed to *-core2.exe instead of *-sse2.exe as in previous builds, i renamed it to sse2 in my miner repo to not break scripts already in place for previous versions

cheers

[joblo]

thanks for this


small note: the windows bin for sse2 was renamed to *-core2.exe instead of *-sse2.exe as in previous builds, i renamed it to sse2 in my miner repo to not break scripts already in place for previous versions

cheers

Ooops. I started using a script for each build for less typing. Was on autopilot renamed exe to match arch.

[felixbrucker]

also my amds are now running past 50 accepted shares on timetravel on windows, so not submitting the benchs prevented the issue