Topic: [ANN] CPU Miner Advanced v5.0.2.0 Beta By Spoetnik (Read 10098 times)

Man, your links are not working, can you reupload?

Hi,do you have plan to make a enhanced miner for cryptoknight?
Posted from Bitcointa.lk - #XrKnGbkuszBlDOGH

+1

Is 32Bit still in the works? I've got a few 32Bit machines still in play that run 24/7 that I'd like to try your miner on.

Thanks.

let me know if anyone needs me to upload the Lib's
it should work fine with the usual libs other miners use though..

the pre-compiled windows builds i uploaded are using,

Cpuminer   2.3.3
Jansson    1.3
OpenSSL  1.0.1e
Libcurl      7.36.0
PThreads  2.9.1.0

New version being added all builds for x64 pretty much two versions one built with MingW and one with VS2010 2013 actually

if people need 32bit build nag me about it but be warned there is a bug in the code i think that make the 32bit ver way slow
so for Jackpot coin if i use the coin devs orig miner i get 80kh/s on my 4770k with 6 threads my 32bit build i get about 140kh/s
and finally on my x64 build i get a bit more than 500kh/s.. i think i know what the problem is but been too busy to fix the 32bit issue.

anyway as usual i will add the links and updated change-log info to the first post.
i'm also going to update the preview pics.. it looks different now.

the last version i mentioned needed testing.. it's good now i think lol
no more cheat stuff..

new features and improvements and some bug fixes and overall better code and full x86/64 support for both MingW and Visual Studio.
I tested AVX on VS2010 and now AVX2 on VS2013 but MingW is still faster.

the most noticeable new feature will be the Window title info.. it says a bunch of stuff.
one of the good things about the window title info is i made it show the URL (everything after the double slashes)
i can't count how many times i have launched a CPU miner and then had no idea what the pool address i used was.. this will show you now
previously i would open Sysinternals Process Explorer and look at the command-line in there.

so i just have to clean up the code and pack it up and then review the code and see if i left garbage used for testing and make notes of key changes.
What i do is freeze making any changes to the code and build the binaries and i built so far x64 SSE2 / SSE4 / AVX2 (prob will do AVX v1 also and maybe 32bit versions)

Just a bump here saying i am a hair away from uploading, so within hours later on roughly.. didn't get bored of this and wander off lol

going to be adding a new version today i think and the change log would be 1000 pages long lol
most proud i am happy i last night finished up creating builds settings for Visual Studio 2010 debug + release and x86 and x64
and it still supports building with MingW so it was a LOT of work but this miner mod will now be compliant with x86 and x64 on all platforms now i think.
i spent a lot of time creating the VS2010 project configs so they are nice and clean and work well..
also i grabbed VS2013 and i will be building the AVX2 build it has in that new version i think to test speeds..
Currently between MingW and VS2010 speeds are about 500kh/s (x64 AVX VS2010) vs 550kh/s (x64 AVX2 MingW -march=native) on my 4770k optimized. (6/8 threads)
And i think it's impressive i squeezed that much speed out of a Visual Studio build lol

@SolidStateSurvivor
i suck at c/c++ even though i have been at over 10+ years.. prob is i am bad at math

anyway, i have done a lot and the more i do the more bugs i find etc etc
i fixed a bug that caused a race condition outputting the date/time..
it would get put out twice in a row before the log line.. i thought i fixed that issue last year lol
to fix it, the thread mutex lock should be started and stopped once.. not twice
i also thought i'd like the idea of another cmd-line to not show the date/time, i tried it (by accident) and it was ok.. i'd used it.

i'm really thinking that no matter what i do to the hashing algo it's just making things worse, as in some kind of cheat crap (based on pool data)
so i will leave in my last and best revision of it and advise people use the non cheat one..
USE the normal one preferably people unless you want to TEST.

i do think i will put scanhash() back and do separate functions for them based on the cheat cmd-line that should be faster code.
i've found some miner tweaks here and there too (in the hashing code)

i have added a lot more window data updated every 5 seconds and tweaked the averaging code
and i also think an alternative hashing speed log line showing the combined hash speed vs the per thread way it is now would be cool.

still didn't do multi-pool support yet or the 32bit windows VS2010 profiles/configs.. they are almost done lol

but i was just testing the final hashing now and it's fast and good as i can get it unless i go with UncleBob's style of algo's (which is faster)
but if i do that Visual Studio and x64 won't compile it doesn't support asm for 64bit so i think it's good enough (and unlce bob used asm)

i just tested both VS2010 and MingW x64 builds normal hashing algo and i get average i think* 490kh/s (VS2010) and 500kh/s (gcc) using 6 threads on my i7 4770k (75% usage)
So since both are so close in speed i don't see any reason to break Visual studio support now that i added it and got it going perfect with no warnings
It's nice to be able to code and build / test in VS2010, then do a MingW build later when the code is final for that extra bit of speed..

so far i got the window title looking like this BELOW (updated every 5 seconds with average hash rate speeds) not sure how well that will work out on Linux though lol

oh yeah and i added resource data to the windows build when compiling with VS2010 for viewing properties on Windows ..and prob more stuff i can't remember hahaa

I went to the NTI in the late 90s, that's when I stopped coding C/C++ cuss it wasn't something I like to do.
Also because I had really nothing to contribute, every program you needed was out there, either in GPL, shareware/freeware/PD
or commercial. Now it looks like I should get coding again. God know it's needed when we design the ASICs.

I can compile and stuff on Linux, but my coding is a bit rusty, but I have an expert in London I could ask, lemme get back on that.

hmm i don't know what to suggest
i assumed if what ever code i use compiles fine with MingW that uses GCC
then it should be fine for linux guys.. that is what i always hoped anyway lol
unless i can get a distrib setup i don't know what else to say.. sad there is prob a 100 people who could help you here but i doubt any will..
coders aren't very helpful in this scene at all.

supporting both are a problem i tried to setup a timer and the code i want to use works for both
but on Linux it meant soemthing different so i had to wrap the Timer Benchmark feature in Windows defines.

Like this:

Hmm, nope that didn't work.

it took me some work but i went through every line of code *again and made prob a thousand edits
and now i got it compiling with Visual Studio 2010 and i am running the 64bit build right now compiled with VS2010

i just have to complete the 32bit configurations for debug and release.. and make sure it still builds on MingW.

I normally would add cpuminer code bases to a Visual Studio solution so i can view and edit source with Visual Assist X all black style
or some quick work with IDM's UltraEdit.. and Beyond Compare is massively useful !

having an IDE is nice.. notepad coding is gay lol

basically i was giving tips for MingW guys.

and i think your problem may be solved by adding color.h to the makefile.am file.

As I only compile / build on Linux, these things are hard to do, but I will what I can do to adopt it and incorporate these fixes into the Linux environment I'm using.

curl-config needs to be re-copied if your flipping back and forth from x86 to x64 builds too

C:\MinGW\bin\curl-config

the contents of that file need to be updated if flipping from one to the other (x86/x64)
reconfiguring LibCurl and running make clean etc will not fix this.. you HAVE to copy it manually yourself or do a cp command etc..

the first line says for me this

prefix=/c/mingw64
in file,
C:\MinGW\bin\curl-config
i am building on x64 right now..

if i do x86 now i need to go cd to the Libcurl folder and run "make clean"
configure for x86 then build..
after that i have to make sure,
C:\MinGW\bin\curl-config
says,
prefix=/c/mingw

of course your paths may be different guys
i installed MingW to my c drive on windows.

note:
there is three lines that are changed when switching back and forth in curl-config so don't just change that one i mentioned earlier
back up the original file and copy it back when needed or edit all three lines manually..

hey run clean.bat and try this and let me know if it works

the run mingW console.. then
cd /c/some/path/etc
./autogen.sh
...........if for windows x86
./configure --host=x86_64-w64-mingw32 CPPFLAGS="-DWIN32_LEAN_AND_MEAN" CFLAGS="-O3 -march=native -s"
----------else x64
./configure --host=x86_64-w64-mingw32 CFLAGS="-O3 -march=native -s"
make
  
if you get two errors about mstcip.h and another ms header use the define, WIN32_LEAN_AND_MEAN before windows.h in cpuminer.c
or you can copy the two files from the 64bit mingw64 install if you got it and copy them into the include folder you found them in the 64 bit version.
and if using LibCurl 7.36 you need to patch a file lol

patch tool_hugehelp.h like this..

then make sure to use the disable command for curl when setting it up..

x64 LibCurl configure cmd-line example.

anyways...
edit Makefile.am contents below (added color.h now)

no i almost uploaded a 32bit version i was packing it and testing an noticed some bugs so i got coding again..
i can upload 32bit but it's going to be waaay slower than x64 but prob faster than the 32bit version the JPC coin dev posted.

hmmm interesting and thanks for the feedback i wondered before if that would be a problem eh
i didn't think it would since i have been building on MingW and MingW64,
it would be a little bit of work to get rid of the colors but i'll look into it and see what i can do..
i have tried to keep it Linux + Windows eh even though i am mostly into windows coding and don't have any Linux distribs running for testing at the moment.

i was just trying to get it running on visual studio 2010 but got almost done and got some old errors and got tired of doing it.. some other time lol

also x86 / 32bit is working but all optimization flags i try with MingW seem to be a hell of a lot slower than the 64bit counterpart builds for some odd reason.

in the last year i have started over making a cpu miner mod using chunks of hashing algo's from other mods
but i am getting tired of starting over again and hope to just stick with this one and port new coins to this one and only this one now.

got some good features planned and coming and already did some..
right now i am testing out having the average hash rate shown in the window title every 5 seconds
Note: currently as *always the colored hash lines in the console show the fastest (submitted good share) hash rate.
So i was thinking it would be good to see what the average hash rate is going on in the background if using the quiet cmd-line..
i always run in quiet mode eh..
Also detected new block messages are normally suppressed as well as debug reject reason in quiet mode but i enabled them for a good reason..
If someone is getting a lot of bad shares and the reason they see is because it says "Job Not Found"
people really may want to consider tuning their scan time (probably lower)
although i have considered adding a cmd-line option to hide the "new block" msg's..

i also added some color and fixed up the benchmark code a bit.. it should be a lot better soon.
and i also added a cmd-line to enable cheat mode testing so no more multiple builds needed..
i think i did a ton of other crap too i forget and will have to compare the files before i do a changelog update again lol

it's a lot of screwing around cleaning up the source code folder and putting together a new packages of builds eh
but of someone wants the build i am currently running for haswell or SSE2 or SSE4 just say so and i can upload just that one .exe pretty damn fast lol

so far the only way i know to build for x86 / 32bit windows is to re-compile the LibCurl install and that is a big time consuming pain the ass
i want to see later if there is some way i can have both compiled and installed setup so i just have to configure again in the mod folder only..
it means i am coding with x64 so i have to delete everything and rebuild for x86 then i have to rebuild it back to x64 again..
and even on a fast machine LibCurl takes time
i have a sick fast SSD (Samsung 840 EVO 256GB SSD Sata III) and my 4770k cpu only uses like 10% when compiling but it still takes a while lol
edit: i also am using G.SKILL Trident X Series 16GB (2 x 8GB) DDR3 2400 - Memory i paid good money for running with xmp profile at 2400mhz

a couple things i want to add..
- Multi pool fall back support (i can pretty much copy and past it from cudaminer)
- Diff modifier via cmd-line (same i can get it from cudaminer or an sgminer mod) so far i have been hard coding values for testing in the last year.
- more hash stats in console window.. i was thinking of maybe something like this...  CMA v5.5.5.5 [current% kh/s] [avg% kh/s] [highest% kh/s]
currently i am seeing a 5 second polled avg but i wrote the code and never did that before and i am not sure what i am doing lol
i had gettimeofday() start in Main then in MinerThread at the end i had it check if time has been 5 seconds and if so update the console window
and then start a new timer basically..
but what i am not sure of is what i should use to average it out..
i have tried 2 or 3 variables combined..
avg = (lowest_hash + hashrate) /2;
or
avg = (lowest_hash + hashrate + highest_hashrate) /3;

edit:
i tried also,
avg = (lowest_hash + highest_hashrate) /2;
but that seemed the most out of whack out of the three averaging strategies i can think of..

For curiosity's sake, I tried building v5.0.1.0 on Linux, but I only get errors, yet this is posix type source code these are the results of the Debianesque jury:


Maybe I could get rid of all the colours, but there are still LOG_TEST and LOG_SPECIAL issues to deal with.