Author: Ed Schröder
Date: 11:24:32 12/05/01
Go up one level in this thread
On December 05, 2001 at 14:11:58, Uri Blass wrote: >On December 05, 2001 at 13:55:19, Ed Schröder wrote: > >>On December 05, 2001 at 13:35:02, Uri Blass wrote: >> >>>On December 05, 2001 at 12:42:07, Ed Schröder wrote: >>> >>>>On December 05, 2001 at 06:46:07, Severi Salminen wrote: >>>> >>>>>>>#define color(target) (((info[target])>>3)&3) >>>>>>> >>>>>>> >>>>>>>my data.c file includes >>>>>>> >>>>>>>int info[64]; >>>>>>>int side; >>>>>>>int direction[64][64]; >>>>>>>int kingsquare[2]; >>>>>>>int pin[64]; >>>>>>> >>>>>> >>>>>>Perhaps the data types could be a reason for some microscopic effects. If the >>>>>>variable "side" is for instance of type "short", the compiler has to zero-extend >>>>>>the variable to word-size before indexing (because of the array access). >>>>> >>>>>But as you can see the variables are all ints. So no type conversions needed. I >>>>>believe there is just some stupid alignment thing happening or something and >>>>>that's why the program slows down a bit. I'd use side instead of color(sq) and >>>>>hopefully the speedup will show up later. >>>>> >>>>>Severi >>>> >>>> >>>>You could try to decrease the >>>> >>>>int direction[64][64]; >>>> >>>>by one, thus: >>>> >>>>int direction[63][64]; >>>> >>>>The result might be the compiler doesn't have to do an expensive multiply >>>>(*65) but is able to do a simple shift-left bits instruction (SHL 6) which >>>>shift left the bytes 6 times, thus a multiply by 64. >>>> >>>>Ed >>> >>>Thanks for your advices >>> >>>direction[i][j] gives information about the direction between every 2 squares(it >>>can get values 0-3 for rook directions 4-7 for bishops direction,-2 for knight >>>directions and -1 for no direction). >>> >>>Doing what you suggest mean ignoring the corner. >>> >>>It is possible that I should change my data structure and simply stop using this >>>big array >>> >>>Example: Instead of using >>> >>>if (direction[square][target]<3) in order to see if square and target are in >>>rook direction(I know that they are in queen direction because they are result >>>of pseudolegal king move in reply to check) >>> >>>I can use >>> >>>if ((file0(square)==file0(target))||(rank0(square)==rank0(target))) >>> >>>when I have: >>>#define fil0(i) ((i)&7) >>>#define rank0(i) ((i)>>3) >>> >>>Uri >> >> >>Well, I never leave it up to the compiler to decide things for me but that's >>easy becausese my background is assembler and my way of programming in C++ >>still is as close to assembler as possible. In your case I would program it >>as follows: >> >>static char direction [65*65]; // create an area big enough, using char > >I do not understand why 65*65 and 64*64 are enough(squares in the board are the >numbers 0-63) That is true, static char direction [63*63] will do the job. However I by definition always make areas bigger than needed. Its reason is that (in my case) many crashes (if not most) are caused by too short defined areas as I had to learn in practise. Feel free to follow the advice or not :) >>To access the table: >> >>int x,y, char result; >> >>result = direction [x<<6][y]; > >I guess that direction[x<<6|y] when 0<=x<=63 and the same for y is enough Naturally in this case the x value must be in the range of 0-63 otherwise the program will crash. Ed >> >>That is all. Any good compiler will produce fast code, something like: >> >>mov EAX,x >>mov EBX,y >>shl EAX,6 >>add EAX,EBX >>mov CL,direction[EAX] >>mov result,CL >> >>Note that in your case "char" is enough, it saves an extra SHL 2 (shift-left). > >thanks >I know nothing about assembler and I may try it. > >My code is only based on plain C. > >Uri
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.