Author: Alessandro Damiani
Date: 12:35:44 01/17/04
Go up one level in this thread
>>>One possible shlight improvement in your approach is a lookup in precalculated >>>tables to save some calculations for diagonals, even if they are cheap: >>> >>>(s>>3)+(s&7) >>>7-(s>>3)+(s&7) >> >>I thought a table look-up instead of these simple instructions costs more. It >>seems I am still thinking in old architectures. > >No, it's negligible and may be not worth to think about. >I'm also a fan of direct register computation. >Anyway, with such small and very often used tables it is likely to get first >level cache hits (but of course 256 byte here and 256 byte there...). > >The code is longer with 3 or 4 instructions (and one additional mov) and if your >macros are expanded very often, a lookup may pay off, if the register pressure >is high. > >With AMD64 things may change again, due to more registers available and longer >encoding with absolute addresses. > >#define AttackDiagRightUp(s) (AFBrightup[s][SlideIndexRU[(s>>3)+(s&7)]]) > ^ ^ > Isn't that dangerous with macros? Right. I checked the source code. This error is only in the published file about Rotated Indices. It will be corrected. Thanks. >I suggest further conditional defines or inlines: > >#ifdef RAY_INDEX_PER_COMPUTATION >#define RayIndexRU(s) (((s)>>3)+((s)&7)) >#else >#define RayIndexRU(s) scRayIndexRU[s] >#endif > >#define AttackDiagRightUp(s) (AFBrightup[s][SlideIndexRU[RayIndexRU(s)]]) > I am not sure if the gain in speed pays of the effort of implementing this. I prefer to go for register computation and wait for my first 64bit machine and decide then. Since then the code won't change for a long time. Alessandro
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.