Re: [Bug-gnubg] Cache question

[Christian Anthon]

Hi Jon,

I assume you tested 2 ply. 4ply will continue to get faster with
increased cache sizes. At least until I ran out of my 2GB of memory.
But why do we need this large a cache when we only need to store
21+21^2+21^3+21^4 = 204204 positions to do a full 4ply, which is <
2^17 entries taking in to account that the current cache store two
positions per entry. It doesn't seem very rational.

Christian.


On Thu, Sep 3, 2009 at 12:27 PM, Jonathan Kinsey<address@hidden> wrote:
> As the cache gets larger it riches a natural plateau, in my initial tests
> this
> was at the current gui limit (4gb entries), I was looking at Ingo's results
> just
> yesterday and there was little (or no) improvement above 2^15 entries. The
> settings and position types will be a factor.
>
> It's quite easy to try out, just use the "set cache" command, you need to
> enter
> the number of entries in powers of 2 though, so the current maximum (2^22)
> would be:
> set cache 4194304
> just times this by 2 to increase the cache (obviously this doubles the
> memory
> usage as well).
>
> I'd be interested in your results as it might be worth changing the
> minimum/maximum and default settings displayed in the gui.
>
> Jon
>
> Michael Depreli wrote:
>>>From my tests the extra speed from using max cache although not huge
>> was worthwhile.
>> Given like you say>2gb is the norm (I have 4gb) would it be worth
>> having an even larger cache available in gnubg?
>>
>>
>> ------------------------------------------------------------------------
>> From: address@hidden
>> To: address@hidden
>> CC: address@hidden
>> Subject: Re: [Bug-gnubg] Cache question
>> Date: Thu, 3 Sep 2009 09:37:15 +0000
>>
>> The only reason is if the memory usage has any impact for you (running
>> several
>> copies at the same time for example), it's getting a lot less likely
>> that this
>> is the case with>2gb becoming the norm on new pcs.
>>
>> You might find that there is little difference in speed between the
>> maximum and
>> one-down setting (and this would save you 80mb of memory).
>>
>> Jon
>>
>> Michael Depreli wrote:
>>> I ran some brief tests using rollouts with different cache settings and
>>> larger cache produced faster results (not linear).
>>> Are there any known issues (bugs) running gnubg with cache set to max
>>> for evals and rollouts for plies up to 2?
>>> If not are there any reasons to not set cache to max?
>>>
>>> Michael
>>>
>>>
>>> ------------------------------------------------------------------------
>>> View your other email accounts from your Hotmail inbox. Add them now.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bug-gnubg mailing list
>>> address@hidden
>>> http://lists.gnu.org/mailman/listinfo/bug-gnubg
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>> Add other email accounts to Hotmail in 3 easy steps. Find out how.
>>
>> ------------------------------------------------------------------------
>> New! Receive and respond to mail from other email accounts from within
>> Hotmail Find out how.
>
>
>
>
> ________________________________
> View your other email accounts from your Hotmail inbox. Add them now.
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-gnubg
>
>