I'm beginning to think dcrypt is no longer a CPU-only algorithm, judging by the concentration of hashpower of the past few days in a few addresses. we might need to come up with a new one hmm. as someone mentioned recently, the assumption of the unbounded scratch space is not true (i.e. you only need a small fixed amount of memory if you are willing to make certain trade offs), and it's operation intensive rather than memory intensive.
A little more fiddling around and I have gotten about a 20% speed improvement by aborting the hash function at count = 120. What makes my eye twitch a little is that I can get a 30% speed improvement on top of that by re-writing
void digest_to_string(u8int *hash_digest, u8int *string)
in
https://github.com/slimcoin/slimminer/blob/master/dcrypt_sha256.cto
char * byte_to_hex =
"000102030405060708090a0b0c0d0e0f"
"101112131415161718191a1b1c1d1e1f"
"202122232425262728292a2b2c2d2e2f"
"303132333435363738393a3b3c3d3e3f"
"404142434445464748494a4b4c4d4e4f"
"505152535455565758595a5b5c5d5e5f"
"606162636465666768696a6b6c6d6e6f"
"707172737475767778797a7b7c7d7e7f"
"808182838485868788898a8b8c8d8e8f"
"909192939495969798999a9b9c9d9e9f"
"a0a1a2a3a4a5a6a7a8a9aaabacadaeaf"
"b0b1b2b3b4b5b6b7b8b9babbbcbdbebf"
"c0c1c2c3c4c5c6c7c8c9cacbcccdcecf"
"d0d1d2d3d4d5d6d7d8d9dadbdcdddedf"
"e0e1e2e3e4e5e6e7e8e9eaebecedeeef"
"f0f1f2f3f4f5f6f7f8f9fafbfcfdfeff";
void digest_to_string(u8int *hash_digest, u8int *str)
{
register int si = 0;
register int i = 0;
for(; i < SHA256_DIGEST_LENGTH; i++)
{
memcpy(str+si,byte_to_hex + hash_digest[i]*2,2);
si+=2;
}
str[SHA256_LEN] = 0;
return;
}
Which gets rid of the expensive branch and shift operations and just replaces it with a lookup / copy. This function converts a sha256 digest (32 bytes) to a lower case hex string. This is called inside the mixer function every time the internal buffer expands because for some reason they couldn't have used just the byte values (wtf: where they intentionally making it resource intensive in a way that can easily be optimized away?) which means tens to thousands of times per hash.
I'm not a great programmer but thats why I'm a little concerned that I could get such a significant speed improvement. I'm sure someone who knows what they are doing could do much better.
I'm not saying the dcrypt function should be replaced. Thats up to you guys but from my perspective it seems like it was knocked together just to be a different but probably wont stay CPU only if it isn't GPU mined already. I think the important aspect is Proof of Burn not what hashing algorithm you use. As far as a fair distribution is concerned I think dcrypt has done its job and even if an ASIC is made for it eventually it wont be broken completely until sha256 is.