don't know what you are trying to do... but im still the most active dev on the project... which is not "deprecated" or "obsolete" as you are saying
CPU specific optimizations are free to be made by all. but its specific and not the goal of my fork which is meant to works on most platforms (including arm)
Where are your commits ? common... Are you just tweeking one algo for a special cpu/os and claiming you made the project (like sp) ?
There is still a lot to do on this project, like Wolf said, to handle at runtime specific variants of the algos (AVX, SSE, AES) and not at compile time which require a lot of binaries
edit: oh sorry, didnt see you put the sources, ok its a good start... i see so often infected binaries on the cloud
![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
but advice, change the project name, original cpuminer is pooler's project and their version number is already 2.4.2 ->
https://github.com/pooler/cpuminerHi Tanguy.
Thanks for your input, as the precedessor of my fork I have a lot of respect for your opinions on the matter. Also in respect
to Pooler I'll remame it and bump the lelease number to 3.0 to avoid overlap.
I'd like to think of our forks coexisting where I would focus on the older algos while you would continue with the emerging
algos and infrastructure improvements. I might do some of that also. I'm targetting lyra2v2 as the next most important
algo to work on. I might take a look at argon2 also, it also has its roots in cpuminer-multi and pooler design so it should
be easy to integrate. It will also gove me some practive adding a ne algo the optiopns list. I'll keep you informed of what
I'm up to so we don't trip over each other. I love that the modules are almost plug and play.
I fear I've already introduced some bloat as I have different files for each variant of each algo. There is a lot of cloned code
in each file but my problems with multiple definitions at link time drove me do do that. Once I understand what the hell
I'm doing wrong I can merge the common code and shrink the code size significantly. I also like the idea of a single binary
does that does all the cpu identification and kernel selection transparently. Maybe some of it can be applied to ccminer also.
I'm not intentionally tweaking for specific CPUs, I want to maintain full backward compatibility but some of my optimizations
may help on some CPUs and hurt on others. Things like inlining are affected by cache size. Even with my CPU some hash
functions were faster inlined while others weren't. Quark for example is faster if the hash function and alomst everything below
it is inlined while x11 is faster if the hash function is not inlined, but everything below it is. I'm trying to work my way
from the bottom inlining and testing and i stop inlining when the inlined code segment gets too large and cache performance
starts to suffer. I'm almost done that.
It's funny you mentioned SP. While doing some tinkering with static and inlining I was wondering if that's what SP was
doing. Maybe I am but I'm not asking for donations, just giving back to the community in a non-monetary way. I want to
cooperate with you and the other developpers and avoid the sniping that goes on in the other thread.
I didn't mean to offend with my comments about CPU mining being obsolete, I'm just trying to be realistic and manage
my expectations. I thought CPU mining was obsolete before I discovered cpuminer-multi and got interested again.
Now I'm excited by what I have been able to do in the past coule of weeks. A good morale boost with mining revenue
so low lately.
I hear you about the name. I could stick with cpuminer-multi if you're ok with that or come up with a new variant.
Thanks again for your hard work with so many projects and I look forward to maybe graduating to ccminer some day.