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

Have you made any progress compiling on Windows with your i5-3330 using different -march= flags?
That AES error seems to be the current blocker.

I'm trying to recall anything I did outside of process in the mingw environment. All of the missing libraries were installed to
/msys/opt/windows_64, nothing was added to cpuminer.

Any #include that uses instead of "file.h" expects to find the file in /msys/opt/windows_64/include.
Unfortunately I didn't keep good notes while I was hacking and have to rely on memory

trying to compile for mingw64 i get this error (3.4.4b, march=native and march=core2):


im a bit lost there, anyone got an idea what the problem might be?

ahh i see, well loosing the colors then

thanks for the explanation!

Ok I understand now I think. Everything before "accepted", including the bold font code and the space is part of the applog prefix
that is automatically prepended to the output. If I changed that it would affect everywhere applog is called. Anyone parsing the
output should use --no-color option.

ok ill try

redirecting the miner output to file instead of the console reveals the structure of the text, like this:


lines starting with ESC/weird symbols are other colors than default grey, for example "accepted" messages are white and the "yes" is green

note that this "color code" starts right after the date/time and the space betweent date/time and the actual message is "colored"

this "colored" space could be moved before the coloring so if someone filters the output and wants to cut off the date/time they dont have to deal with removing the 9th char (or so) to preserve colors

cheers

I don't understand what you are saying.

That's interesting. It definitely isn't implemented that way in cpuminer and I don't recall seeing any code regarding
block finder. I will take a look at Pooler. If he has impmeneted it that way it's worth considering.

Edit: I just looked at he latest Pooler code and he still uses yay!!!/boooo for accepted/rejected shares with no indication
of finding a block. It's an interesting idea but I don't see anywhere that the pool communicates that info to the miner.

In my setup I didn't add any extra files to cpuminer but I did have to add some to /msys/opt/windows_64.

Right now your problem isn't the setup but the architecture selection. The 3330 is indeed Ivybridge and should have
both AES and AVX. Your compiler chose "ivybridge" but trips over the AES code. As I mentioned my compiler doesn't
accept brand names like ivybridge, only architecture names like core-avx-i and corei7-avx. Try compiling specifying
different architectures until the AES error goes away then we can compare what works with what should have worked

"start /low" - process will have low priority, useful when you have other more important processes running on your OS.

In ccminer there is a "yes!" - accepted share, "nooooo" - rejected share and "yay!!!" which is share that found a block.
I believe that it this come from pooler's original cpuminer.

So if you intend to change the format, how do you mark a share resulting a block find?

In general i like the idea of redesigning the output.
I would really love output format like SGminer here in cpuminer-opt (one can dream )

my only suggestion for the output (if you are going to change it): make the space before "accepted" before the coloring stuff, right now its like this:
[01;37m accepted[...]
to
 [01;37maccepted[...]

cheers

the cpu is a i5-3330, it has aes, though im pretty sure the only thing holding me back from compiling successfully is somehow PATH related

steps done:

downloaded the mingw32 installer and installed basics+msys (32bit) to C:\mingw
downloaded mingw64 (x86_64-6.2.0-posix-seh-rt_v5-rev0) to C:\mingw64
added various C:\mingw64 directories to the system PATH
started a msys shell (from c:\mingw\msys...)
compiled curl source with ./configure --host=x86_64-w64-mingw32 --prefix=/c/mingw64
merged pthread mingw64 dir with C:\mingw64 dir
merged OpenSSL-Win64 include dir into mingw64 include

started winbuild.sh, complained about curl.h, so i copied it into the cpuminer dir to not spend hours with the obviously not working PATH
same for openssl and pthread

after this it complained about some double initialization or something of time in sys/time.h, so i copied the mingw64 versions of the files into the cpuminer dir

after this only the gmp.h was missing and then the garbled output from thge screen above appeared


i think some bins/libs used to compile are still 32bit ones as the PATH or at least the PATH the msys shell uses do not use the mingw64 ones but the 32 bit

which steps did differ for your setup?

to my understanding mingw32 is only needed for msys (its not included in mingw64 it seems), is this correct? i would skip the whole mingw32 part if i could and only use mingw64 if this works too, so there is no chance some 32bit bins/libs are getting used

cheers

Good point about the people parsing the output!!!
Maybe make a switch to allow the new and improved vs. the legacy output just in case.

Thanks for your comment.

I agree the API should not be different among miners as well as primary command line options. Console output is a little
less rigid.

I believe the current format, with some variations, is the convention for cpuminer and ccminer only. Those variations include
displaying hash count as well as rate, and "yes!" "noooo" instead of "yeah!!!" "boooo". AMD miners and alternative miners
have completely different output formats. I don't feel bound by the current format if it can be improved.

Any change to the output format could  affect users who run filters on the output and expect a certain format. They would
have to modify their filters for the new format.

I think the current format has become the defacto standard.
Though I am all about being different, I.E. bleeding edge, and I support any change.

My only concern would be that no changes happen with how the API is presents data, which I am pretty sure this will not.

Proposal for change in output for share submissions.

old format:

[2016-08-27 21:09:13] accepted: 1791/1791 (100%), 11.93 MH, 461.52 kH/s yes!
[2016-08-27 21:09:13] accepted: 1791/1792 (99.9%), 11.93 MH, 461.52 kH/s nooooo

proposed new format:

[2016-08-27 21:09:13] Accepted: 11.93 MH, 461.52 kH/s, 1791/1791 (100%)
[2016-08-27 21:09:13] Rejected:  11.93 MH, 461.52 kH/s, 1791/1792 (99.9%)

Reason for change:

- shorter
- removes ambiguous "accepted" for both accepted and rejected shares
- eliminates unnecessary words "yes!" and "nooooo".

Comments?

What CPU? Did you compile native or specify -march=?

This error is in AES code, which suggests your CPU doesn't have it but the compiler thought it did.

Edit: In case it isn't obvious this is significant progress in helping me. If the compiler can't figure out the correct
architecture it can be specified manually.

that seemed to have worked, now it complains about missing gmp.h however

edit: added gmp.h from here http://cs.nyu.edu/~exact/core/gmp/index.html, now compile fails but im unsure why, windows building is pita



wonderful garbled text from msys

i guess i have done something wrong, might need a guide for dummies, will wait for someone else to build bins

cheers

If you got that far then it looks like your compile environment is setup correctly.

There are many different publishers but I installed from here:

https://slproweb.com/products/Win32OpenSSL.html

Download the 64 bit developper version.

ok, now im stuck with openssl, cpuminer compile wants openssl/aes.h, what do i need to install/download?

cheers