Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: My miscellany of minor chess programming problems ?

Author: Mridul Muralidharan

Date: 12:35:06 08/27/05

Go up one level in this thread


Hi Rasjid,

  However much cache we are provided with , we will could always do with more :)

  Even without much of overhead , the average memory that you access repeatedly
for a normal run of the program could easily overrun 512kb (if you dont watch it
carefully).
More so since a cache line is fetched (64/128 bytes each) - so this favours
repeated access within a cache line : if you access outside , then the line
could be replaced with new data (you will also suffer a penality for fetch ):
this sort of thrashing could become bad.

So by default , I try to avoid all obvious memory access which can be replaced
with computationally efficient code (not saying that what I have for mirror is
efficient !) - and a flip[] array seems to be one (imho) which could be replaced
since the computational overhead does not seem to be high - I could be grossly
wrong here since YMMV as usual.
Only testing could say (and also depends on how you access it ...) for what you
have written.

All the best with your program !
Regards,
Mridul


On August 27, 2005 at 14:55:31, rasjid chan wrote:

>On August 27, 2005 at 11:52:24, Mridul Muralidharan wrote:
>
>>Hi Rasjid ,
>>
>>  Some comments from my expierence.
>>
>>
>>1) cache miss is a very bad performance killer - and sometime not very
>>predictable why/when.
>>Ofcourse , this happens as the number of arrays that you use increase - need not
>>necessarily be large - a lot of distantly placed smaller array which are
>>sparsely used can also be equally worse.
>>
>>From what I find , there are places where you use arrays and where you use
>>computation - and the decision should be yours based on expierence.
>>In a tight loop running multiple times , a array can be better if it fits a
>>cache line.
>>
>>Some of the alternatives to precomputed arrays (like for distance , etc) use
>>conditional expressions - which can be equally bad and sometimes worse
>>(depends).
>>
>>So , my input on this point is - you just have to test and find it out :)
>>I tend to frown on alternatives which are 'big' and also containing a lot of
>>conditional expressions.
>>
>
>Thanks for your advice.
>
>My questions are basic as I vaguely know microprocessor architecture - except
>they have registers, instruction pointers,stack, etc enough for me to do C.
>
>I did tried ceratain things like using bitboards to do sliding attacks with
>precalculated diagonals[][] and conditonals, etc, but they seem a little slower
>than mainstream ox88 vRay[128+x-y]&vBISHOP method. But I have just thought about
>some improvements. So final is about testing.
>
>>
>>2) Regarding the use of flip and using conditional if(white/black) code : here
>>is something I use - maybe this will be slightly better ?
>>
>>#define MIRRORED_POS(_side , _pos)					\
>>	((((_side) << 6) - ((_side) << 3)) ^ (_pos))
>>
>>(I have white == 0 , black == 1 - you can ofcourse modify this for other forms).
>>
>
>Dr Hyatt just mentioned 512k cache so it seems quite a lot. I may still see
>as long as things are noticably better using flip macro.
>
>>3) I use a pv[ply][ply] approach - not 'cos it is better/easier - but since it
>>helps me in debugging :)
>>Once the engine becomes more mature , I usually skip to using a hash table
>>approach.
>>I dont like idea of maintaining duplicate info if I can help it - yes , a good
>>replace scheme is critical ofcoruse !
>
>Dr Hyatt just suggested backing up the pv, so I think at almost zero cost. ok
>for now
>
>
>>Vincent's scheme is pretty good , what is it that you did not understand in it ?
>
>In general Vincent target the expert audience. I do have some idea about the
>general replacement scheme and will slowly need to make things more certain.
>
>Best Regards
>Rasjid
>
>
>>
>>Hope this helps,
>>Regards,
>>Mridul



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.