Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: speed question

Author: Uri Blass

Date: 10:56:22 02/20/03

Go up one level in this thread


On February 20, 2003 at 13:41:39, Dezhi Zhao wrote:

>On February 20, 2003 at 12:49:39, Uri Blass wrote:
>
>>On February 20, 2003 at 12:19:22, Dezhi Zhao wrote:
>>
>>>On February 20, 2003 at 06:26:39, Uri Blass wrote:
>>>
>>>>On February 19, 2003 at 10:45:27, Dezhi Zhao wrote:
>>>>
>>>>>On February 19, 2003 at 09:57:13, Uri Blass wrote:
>>>>>
>>>>>>On February 19, 2003 at 09:41:35, Dezhi Zhao wrote:
>>>>>>
>>>>>>>On February 19, 2003 at 06:39:49, Uri Blass wrote:
>>>>>>>
>>>>>>>>I try to do movei faster and there are things that are supposed to do it
>>>>>>>>slightly faster but for some reasons do it slower so I deleted them(Maybe it is
>>>>>>>>better if I ignore it because it is a compiler optimization noise but I do not
>>>>>>>>like to see the program slower even if it is only 0.1% slower).
>>>>>>>>
>>>>>>>>Note that I do not use now compiler optimization except optimize for speed with
>>>>>>>>visual C++6.
>>>>>>>>
>>>>>>>>
>>>>>>>>Here is an example:
>>>>>>>>My function of adding pawn moves to the stack of moves get 2 numbers(from,to).
>>>>>>>>
>>>>>>>>I found that special functions to generate white moves one square forward,white
>>>>>>>>moves 2 pawns forward,black pawns one square forward,...helped me to do movei
>>>>>>>>faster.
>>>>>>>>
>>>>>>>>Common sense say that now I do not need 2 numbers in my functions because
>>>>>>>>I always have to=from-8 in
>>>>>>>>
>>>>>>>>Here is my function.
>>>>>>>>to is always from-8 and the question is if I can take advantage of that fact.
>>>>>>>>
>>>>>>>>static void gen_quietblackslowpawns(int from,int to)
>>>>>>>>{
>>>>>>>>	gen_t *g;
>>>>>>>>	if (to<=7)
>>>>>>>>	{
>>>>>>>>		gen_promote(from,to);
>>>>>>>>		return;
>>>>>>>>	}
>>>>>>>>	g=&gen_dat[first_move[ply+1]++];
>>>>>>>>	g->m.b.from=(char)from;
>>>>>>>>	g->m.b.to=(char) to;
>>>>>>>>	g->m.b.promote=0;
>>>>>>>>	g->m.b.bits=16;
>>>>>>>>	#if MODE!=MODE_PERFT
>>>>>>>>	g->score = history[from][to];
>>>>>>>>	g->index=-10000;
>>>>>>>>    #endif
>>>>>>>>}
>>>>>>>
>>>>>>>I think you can get a little from that fact. It will save a few push and pop
>>>>>>>operations.
>>>>>>>
>>>>>>>By the way, if you really want to optimize this function, you should consider
>>>>>>>re-designing the b structure so that the move can be saved in a single write
>>>>>>>operation, instead of 4.
>>>>>>
>>>>>>Thanks for the advise but how do I do it
>>>>>>
>>>>>>I have the same data structure as tscp here(Note that 90% of my code is
>>>>>>different than tscp but I copied part of it's data structures).
>>>>>>
>>>>>>Here is my b structure
>>>>>>
>>>>>>typedef struct
>>>>>>{
>>>>>>	char from;
>>>>>>	char to;
>>>>>>	char promote;
>>>>>>	char bits;
>>>>>>}
>>>>>>move_bytes;
>>>>>>
>>>>>>typedef union
>>>>>>{
>>>>>>	move_bytes b;
>>>>>>	int u;
>>>>>>}
>>>>>>move;
>>>>>>
>>>>>>
>>>>>>I can think about deleting the b and have something like
>>>>>>g->m.u=from+(to<<8)+(promote<<16)+bits<<24) but the question in that case is if
>>>>>
>>>>>yes. you can go this way. for this function, the last 2 items are simple
>>>>>constants anyways.
>>>>>
>>>>>>it is not going to do accesing the varaibles slower because there are places in
>>>>>>the code when I use bits and now I will need to use things like u>>24.
>>>>>>
>>>>>>I have no idea about the price of these things so I cannot evaluate speed here.
>>>>>>
>>>>>>Uri
>>>>>
>>>>>Not that complicated if you think it twice.  I do know the semantics of bits
>>>>>thare. However I assume it is a flag. If it is the case, you do not need to do a
>>>>>shift to make it flat. Consider testing the other way without shift operations:
>>>>>u & (16 << 24)
>>>>>So you can avoid shift operations in many cases. So you still gain something
>>>>>here.
>>>>>
>>>>>dzhao
>>>>
>>>>I try it at this moment(I do not know if it is going to make the code faster so
>>>>I saved the previous code).
>>>>
>>>>The problem is how to make my code readable at the same time.
>>>>
>>>>I deleted the m.u and m.b.from,m.b,to,...
>>>>and have only m that is an integer.
>>>>
>>>>I try to use some defines
>>>>
>>>>#define mfrom (m&63)
>>>>#define mto ((m>>8)&63)
>>>>#define mpromote ((m>>16)&63)
>>>>#define mbits ((m>>24)&63)
>>>>
>>>>It was not enough so I added the following defines
>>>>
>>>>#define gen_dat_i_mfrom (gen_dat[i].m&63)
>>>>#define gen_dat_i_mto ((gen_dat[i].m>>8)&63)
>>>>#define gen_dat_i_mpromote ((gen_dat[i].m>>16)&63)
>>>>#define gen_dat_i_mbits ((gen_dat[i].m>>24)&63)
>>>>
>>>>I see that it is not enough and I need the same for other varaibles that are of
>>>>the same type.
>>>>
>>>>I do not like it so I went back to my previous code
>>>>
>>>>Thanks in advance for advices.
>>>>
>>>>Uri
>>>
>>>Here you may consider inline member functions, which give you the encapsulation
>>>and abstraction for free. The #define stuff is OK, but not as good.
>>>
>>>Such encapsulation and abstraction are valuable if you need to change such basic
>>>operations or data structure. Without them, you may face changing hundreds of
>>>scattered places, and if you miss a single one, you produce a bug.
>>>
>>>just a reminder:
>>>#define gen_dat_i_mpromote (gen_dat[i].m & (63 >> 16))
>>>is better than:
>>>#define gen_dat_i_mpromote ((gen_dat[i].m>>16)&63)
>>>
>>>The same apply to other test operations.
>>
>>I guess that you mean
>>#define gen_dat_i_mpromote (gen_dat[i].m & (63 << 16))
>>
>
>yes.
>
>>I guess that the laternative that I tried
>>
>>#define to(x) (((x)>>8)&255) was also bad
>>and better was
>>#define to(x) (((x)&255<<8)
>>
>>I guess that in that case I need to change some more code
>>
>>For example
>>
>>I have today some cases when I have
>>switch(m.bits)
>>case 1:
>>case 17:
>>...
>>
>>in that case I need to say case 1<<24 and in order not to have an ugly code
>>I need to have more constants for 2^24,2^24*17,...
>>
>>I can use
>>enum
>>{
>> bits1=16777216
>> bits17=
>>...
>>}
>>
>>Uri
>
>Rigth. You can name the constants by using either enum or #define. The same
>principle applies to the constants, not only for the cleaness but also for easy
>later modificafions.

Right. I remember that one of the rules that I read is not to use magic numbers
so it may be better to use names and not bit1 and bit17 but I guess that I will
start with bits1 and bits17 when only later I will do replace of every bit17
with a more significant name and after it replace of every bit1 with more
significnat name.

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.