Yeah might get some extra exposure in the Marketplace at the least.
Minor slack update. The elastic slack now has a trello channel which will get auto-updates from the newly created trello board to track the development backlog. Just to reiterate, this is in preparation for managing feedback once the main-net is released.
In my opinion, this is a must have for crypto projects that want to remain transparent, and empower the community to stay involved.
Anyone can view the trello board here:
https://trello.com/b/fPdyn5VpDev's and other team members feel free to PM me for a member add on the trello board if you want to utilize it sooner.
Nice work Selsonblue...I've added a couple of items where I know the miner needs enhancements. Maybe this will encourage others to get involved. Of course there are lots of other needed improvements to the miner...
Here is a more comprehensive list of the enhancements that I know the miner needs. As I've stated all along, this is just a prototype miner, I'm sure others can improve on it greatly.
Also,
I'm not asking for people to tell me how to solve for these issues...I already know how to fix each of them, I'm just not interested at this time. I'm just hoping this may help others get more involved and help out.
1) OpenCL Enhancement 1 - I don't own any GPU's so my OpenCL logic is very basic. Right now it uses a very simplistic approach to determine the number of cores to mine with. This needs to be enhanced, but I don't have the hardware to try out the code with.
2) OpenCL Enhancement 2 - ElasticPL uses 64bit floating point arithmetic...but not all devices support 64bit floats. Right now, the if the miner doesn't support 64 bit floats, it won't use OpenCL. Ultimately, it would be better if the miner checks to if the job even requires floats, and if not, it should be able to use OpenCL...or better yet...some floating point operations don't require 64 bits...check if it uses those.
3) OpenCL Enhancement 3 - Create AMD / NVIDIA specific code to optimize the miner for those GPUs....but remember, no one knows what you'll be mining...it's all up to what logic the author submits in the job...so it needs to be very flexible.
4) Mining Algo Switching - The algo to determine which job to mine is pretty simplistic. You can choose the most profitable job, the easiest job, etc. First it would be great if the community came up with a list of the various ways the miner could determine which job to mine, then the mining logic could be updated accordingly.
5) C / OpenCL Code Generator - Currently this code generator uses recursive logic. This puts a limit on how deep the AST tree can be based on the hardware...but, I have a check in place to make sure the miner doesn't exceed it's limits. We may want to switch the code generators to use an iterative approach instead (see the WCET logic for an example). I created a prototype of it but it is ugly and hard to maintain. Maybe someone can come up with something better.
6) WCET Calculations - I modified the calculation to better represent the complexity of the code, but it really needs some additional work. Someone could spend some time truly figuring out the relative weights of the various operators / functions to better determine how complex the job is.
7) CPU Thread Priority - When I built the miner I removed all thread prioritization logic (remember I never intended this miner to ever be used). EK added some simple logic back for Linux users, but there is nothing for Windows users...someone could add all this back in.
8 ) Miner Options - I'm sure there are more options that would make the user more user friendly...
This is all I can think of for now.
