Author: rasjid chan
Date: 12:54:58 08/27/05
Go up one level in this thread
On August 27, 2005 at 15:35:06, Mridul Muralidharan wrote:
>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
Not that I will ignore unnecessary memory access or don't try smaller arrays.
Actually I still pay attention but with a slightly better understanding now.
I rememember something Dr Hyatt mentioned before (if I am not wrong) about
sometimes passing relevant(huge) structure/pointer-to-structur as function
parameters. When one variable is accessed, the related stuffs are all pulled in.
eg.
struct {
int alpha;
int beta;
int best;
....
};
When we access best, we most likely would need alpha, beta and other related
things and they will just be next. Compiler optimization may not know we are on
chess programming so our help would make a faster chess program. These and other
things still do matter.
I should now be a little better as I do pick up hints here quite a lot.
Incidentally, I am not a professional in the computer field.
Best Regards
Rasjid
>
>
>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.