This topic has appeared on the following day after vehre refused to quit. This is also a chance?
anyhow, I fail to see the interest claymore algo is way much faster... (if it is just to get the bounty.... at 50USD/hour, it would cost you more)
How do you know Claymore's is faster? This doesn't even work yet - it uses ONE GPU work-item and ONE thread.
Speaking of open-source gpu-miners... Wolf0, you might want to take a look at tsiv's latest release for cuda-miner... made a binary to mine on compute 2.1 and compute 2.0 (fermi) cards.
Maybe that can help?
My 1GB 560ti's get 200h/s each. Just saying.
Did that. While the code is not the bottleneck, I'll tell you - that code is SLOW. Also, a little painful to look at. Just to prove it, I'll give you a little bit of code that is a drop-in replacement for his ccminer that shows what I'm talking about:
http://pastebin.com/UqUJ7WKuLike I said, it won't make it much faster, because it appears the code is not the bottleneck - but if you just look at it, it makes you think, "WTF was he smoking?"
Another example - in the older versions of ccminer, he had this:
#define E2I(x) ((size_t)((*((uint64_t*)x) / AES_BLOCK_SIZE) & (MEMORY / AES_BLOCK_SIZE - 1)))
That was used four times in a loop that executes 252,144 times. Now, the compiler can optimize some of this away - AES_BLOCK_SIZE and MEMORY are both constants, 16 and 1 << 21 (0x200000, off the top of my head.) Divides are OUCH slow, but to be fair the compiler should fix that. Now, he has since replaced it with this, showing he's getting better:
#define E2I(x) ((size_t)(((*((uint64_t*)(x)) >> 4) & 0x1ffff)))
But he still doesn't seem to see the fail here - the result of E2I is multiplied by AES_BLOCK_SIZE without exception. Therefore...
((uint64_t *)x)[0] & 0x1FFFF0;
... can replace the whole E2I macro PLUS the multiply. Why? The first divide by AES_BLOCK_SIZE and the multiply by the same that is always done after cancel. By the way, idk if 32-bit ops are any faster or slower on the GPU, but you don't need 64-bit width - you're masking out everything anyway. So if 32-bit is faster:
((uint32_t *)x)[0] & 0x1FFFF0;
The 0 on the end is to mask out four bits - the bit shift down by four, then up by four would clear them, so an AND by zero does the same.
I'd like to thank tsiv for crediting me when he added my edits - he didn't have to, and I was a bit scathing.
