I am really sorry for being a dick. I understand. I code myself mainly on genetic pipelines and it takes ages for making a pipeline of data such that other people can easily understand and use it. So plain and simple sorry
But I believe in competition. SGminer is probably the most versatile windows based GPU miner I have seen. I would like to see better softwares pushing limits on each front. So no hard feelings. Please accept my humble apologies
Oh no, honey, you weren't a dick. Don't think that.
I'll do my very, very best to ensure we have monthly updates at the
minimum.
I just want the community to understand that it is being worked on, actively. At least twelve hours a day on my end. It just takes time, because in addition to this, I have technical writing + pro bono stuff. Would it help if, maybe, I kept a sort of diary/journal showing what we accomplished for the day with SGMiner-GM?
THE LINUX BINARIES RUN WELL AND MINE ZCASH--
But the mining algorithm for Zcash (ZEC) needs to be updated and optimized. The algorithm mines at about 1/2 the speed of Optiminer and Claymore's ZEC mining engines. BUT, I am sure that Wolf0 and OhGodAGirl can bring SGminer-GM up to speed soon.
For the brief while that I tested the miner, an 8GB Sapphire RX 470 OC mined at about 80Sols/s without errors. The familiar SGminer statistic display was a joy to watch.
Please keep up the progress! --scryptr
Thank you so much, scryptr. Your words always inspire us to keep going.
I'm going to work on updating ZEC to SA v5. In addition to that, I've been closely following zawawa and nerdralph's optimizations + ideas. I'm working to implement those.
Why is so difficult to develop the sgminer for the ZCash? Can you just remove some optimisation from your own miner and then implement it in sgminer?
Hm.
I want to imagine you're a junior copyeditor, and your boss slaps a giant textbook of notes. It was penned in medical shorthand - doctor chickenscratch.
You're going to have to take that textbook and translate it into plain English. Difficult, right?
On top of that, you have a bunch of new notes from another doctor - this one Scottish - that you also need to weave into the textbook. Lots of 'wae', 'nae', 'tae' and 'shite' (though that one's easy to figure out). It's still in chickenscratch, but you don't have many Scottish friends, so it takes you a while to decipher the sentence. Even worse, this doctor has really awful handwriting! Some of it just looks like poorly drawn
waves to you.
Your boss keeps adding notes from other doctors - all different ethnicities and backgrounds, all different writing styles.
Starting to get the big picture?
Now, let's get a little more technical:
Programmers will now how annoying it is to maintain another coder's work. Especially if it's not properly commented. Well, sgminer-gm (and other versions) aren't. Commit messages didn't follow a proper convention (subject explains WHAT changed, body explains WHY); huge blocks of code have no comment, so you need to figure out what's going on; documentation was not updated; there are old dependencies; there are a few faults, and that happens when having a large, open source project.
Some kernels have unique ways of handling, for example, Stratum: let's look at cryptonight (Monero). There's a custom function in util.c (built by previous sgminer developers) called json_array_string() which makes a strdup() of the actual string buffer returned by jansson. Usually, we free() all those buffers. Well, cryptonight, for example, doesn't do that - it doesn't return an array, so we have to pull the string values straight out of jansson, rather than using the custom sgminer function.
Starting to see the difficulty? It takes a lot of analyzing HOW a kernel works, then looking at HOW you can think of putting this into SGMiner-GM in a way that won't break anything else. And believe me, breaking happens. Oh, and bugs. So many bugs. And then you have to test, test, test. On both Linux, and Windows. And testing a mining program isn't as simple as just running it, waiting a few moments, then calling it a good day; you need to let it treat it like you would a hardware stress test for stability.
Let's look at scanhash_opencl. This should not have any algorithm dependent code - but it does. A function pointer (that points to different kernel dispatch functions) needs to step out and dish out stuff, based on the algorithm. And the goto statements need to be removed. But there are a lot of them. A lot.
It's not as simple as just plugging in a line of code, either. So many files need to be changed. I want drag and drop kernel support, I really do, but...that won't happen. With SGMiner-GM, at least. Folks have probably snooped and found out what we're planning, but, that's a post for another time and potentially another place.
