Author Topic: Algorithm efficiency with memory usage  (Read 6250 times)

0 Members and 1 Guest are viewing this topic.

Offline timegrinder

  • Newbie
  • *
  • Posts: 14
    • View Profile
Re: Algorithm efficiency with memory usage
« Reply #3 on: November 17, 2013, 10:02:07 am »
Okay cool, thanks for that - must just be a bandwidth issue causing a bottleneck for me then, as at 4095 I end up with 90Col/min after a few hours but with 2048 it's 99col/min.

Thanks again!

Offline FreeTrade

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 700
    • View Profile
Re: Algorithm efficiency with memory usage
« Reply #2 on: November 17, 2013, 09:50:52 am »
Yes. The algorithm in the stock client uses a bucket size, I think it allows for 8 entries. Once that's full, it starts discarding new entries - although they are checked for collisions before being discarded. About 10% get discarded. So we lose about 1% of collisions. Doubling the bucket size means fewer entries are discarded, or better, doubling the number of buckets means there are fewer entries in each bucket and can be searched faster.   
“People should be more sophisticated? How are you gonna get that done?” - Jerry Seinfeld reply to Bill Maher

Offline timegrinder

  • Newbie
  • *
  • Posts: 14
    • View Profile
Algorithm efficiency with memory usage
« Reply #1 on: November 17, 2013, 09:14:59 am »
Hello,

I did a search of the forum but unfortunately wasn't coming up with much in way of a question this side of the fence.

(This is mostly a question specifically for the algo designer / developers)

I'm interested to know if there is actually a theoretical (eg, based on the algorithm/code specifically) of running with higher memory usage (eg, default is 512, but while some are working toward lower memory usage there is a mod by Tydus to permit 1024/2048/4096 MB RAM per thread.

I haven't seen a terrible difference in collisions/min when testing between these (in fact running with 2048MB appears to be 1-5% more col/min than 4096MB (Which I assume is a memory bandwidth/latency issue).

Generally speaking however what I'd like to know is - all things being equal is more memory actually better per thread where possible? Is there a larger hash table stored in memory to use as a reference? (Meaning that it may be more likely to find a meaningful collision?) or is the thread only going to operate within a small amount of that hash space?

At the moment I'm trying to do some tests myself (Which is as simple as running the program at different settings at ~24H at a time to see if one gets more shares and/or consistently runs higher col/min) but as far as I can tell those statistics would be completely arbitrary as it could be complete fluke whether or not a collision is valid or if there's a pattern to it.

Overall if I don't make sense feel free to ask (or yell at me if it's been explained already somewhere else, I unfortunately wasn't sure what keywords to search for beyond a couple that didn't seem to get me the answer I was looking for).

Thanks,