I've made some updates to code to count collisions per minute rather than hashes per minute.

Some hashes generate 0 collisions, I've seen others generate up to 8.

Hashes per minute is a good metric to use if you're tweaking the speed of an algorithm.

Collisions per minute is a much better metric to judge your chances of finding a block. It is also much better to use when comparing algorithms which is what most end users of solo and pool miners will want to do.

Here's the code - it's a small adjustment.

https://github.com/InvictusInnovations/ProtoShares/commit/776832f419649211cb7b173ffb437e7d2af68b8b

I've mixed it up with another commit unfortunately - here's the relevant parts

main.cpp

lines

1329
1337
4611 - 4619
4623

main.h
1323

You need to store the birthday (50 bits, rounded up to 64 bits) and the nonce, 26 bits rounded up to 32 which is 12 bytes.

If you got fancy you could use 76 bits or 10 bytes rather than 12 and save 16% at the expense of some computation.

The current algorithm uses
64bits + 32bits -> 96 bits

Only 50 bits of the 64 bits are relevant, and only 26 bits of the 32 are relevant, so that's a total of 20 you can shave right away.

However, with current implementation 22 bits of the 50 can be immediately inferred from the location in the hash map, so there's another 22bits saving there too . . so a grand total of 28+26 is required - 54bits . . there'd be a little more calculation for all the bit-shifting, but not much. The algorithm could use as little as 432MB without much additional calculation and without loss of collisions.

So then does the current implementation have any implications for preferring less cores or anything like that?  Does mining with a higher # of cores result in more "stale blocks" for some reason?  Or would that not make a difference.

Yes, higher number of cores will mean more collisions, but longer hash time . . . longer hash time means blocks are more likely to be stale. It should be a fairly small effect after the first re-adjustment.

all my cores are maxed out, but is there any way to verify it's mining correctly?

hashespermin in getmininginfo shows 0 and the hashespersec command also shows 0

And is there any way to find out how many blocks you've found other than checking your balance?

./protosharesd getmininginfo
{
    "blocks" : 38,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 0.00000095,
    "errors" : "",
    "generate" : true,
    "genproclimit" : -1,
    "hashespermin" : 0,
    "pooledtx" : 0,
    "testnet" : false
}

./protosharesd gethashespersec
0

P.S. I love the idea of ProtoShares and BitShares

Yes, this should work, but takes 4 or 5 minutes before it reports figures.

Quote from: bytemaster on November 03, 2013, 06:31:21 pm

Until someone contributes an enhanced mining algorithm to the ProtoShares client you will require about 12 GB of RAM

The memory requirement for mining ProtoShares is 12GB?  Is it lower if you only mine on two cores?

Approximately additional 768MB per core - the GUI has an option to mine up to 4 (3 on win32 because of memory limitations), you can set it to more in the debug console (setgenerate true , but don't expect linear performance gains per core.

You can check the performance using 'getmininginfo' - there is a 'hashespermin' reading, which will have useful data after about 4 minutes or so.

It's possible you'll get better performance by running multiple instances of the client, rather than multiple processes in the same client, but the real performance gains are to be made with code optimization. There's a reasonably good algorithm in there, but poor memory access/threading.