Author: Robert Hyatt
Date: 08:45:50 01/06/04
Go up one level in this thread
On January 06, 2004 at 10:13:45, Gerd Isenberg wrote: >On January 06, 2004 at 09:40:33, Robert Hyatt wrote: > >>On January 05, 2004 at 18:30:59, Uri Blass wrote: >> >>>On January 05, 2004 at 18:02:43, Sune Fischer wrote: >>> >>>>On January 05, 2004 at 17:47:51, Uri Blass wrote: >>>> >>>>>>IMO no. >>>>>>It is better to be safe than sorry, such a bounds check can easily be avoided by >>>>>>making the array a tad bigger. >>>>>>In a non-smp program you can make the array static, if you like. >>>>> >>>>>I think that even if the price is that in one of 1000 games you get wrong see >>>>>when the numbers of attackers is 16 or more than it then you will not be sorry. >>>>> >>>>>remember that usually one wrong evaluation is not enough to change the move. >>>> >>>>Most of the time, I'm pretty sure it is 99% of the time, there will be less than >>>>16 captures to the same square. >>> >>>I think that you can only say 99% of the time not more than 8 captures in the >>>same square inspite of the fact that I did not calculate statistics. >>> >>>>In that respect it's true the array is too big, but these rare cases still force >>>>you to do a bounds check every time you add a capturer. >>>> >>>>By making the array large enough for even the biggest theoretical capture >>>>sequence you _save_ these checks and that is what is important here. >>>> >>>>Remember the check is going to be made several times per SEE which could be done >>>>several times per node, so it's kind of speed critical. >>> >>>Remmeber that the check is only going to be done at most 4 times in common >>>cases(I think that in most cases you have even not more than 2 captures in the >>>same square for example 1.e4 e5 2.Nf3 Nc6 3.Nxe5 Nxe5 no more captures). >>> >>>I remember from experience with my program that allocating memory for varaibles >>>in functions is expensive and in the early days of movei I got a significant >>>speed improvement by having global arrays instead of having local arrays even in >>>cases that I did not need to use the global array out of the function. >>> >>>Uri >> >> >>Maybe there is some confusion here. There is _no_ cost for "allocating" >>local variables in a function. And I _do_ mean _NO_. These values are >>simply "on the stack" and when the function is entered, the stack pointer has >>some constant subtracted from it to leave a "hole" that is used to hold local >>function variables. no malloc() or anything like that is done by modern >>compilers, hence zero cost. > >Except you exceed some -128/+127 byte offsets for some other locals, >making bp-relative memory access instructions three bytes longer ;-) > >00401C32 89 45 94 mov dword ptr [ebp-6Ch],eax >.. >00401C3B 89 85 64 FF FF FF mov dword ptr [ebp-9Ch],eax > >What about AMD64 64-bit addressing modes? I fear it is even more important to >keep the local frame compact. Are there other alternatives for address offsets >than one byte with sign extenions or 8-bytes? OK, that's a good point. However, this seems to be an issue that can't be helped, although I guess for a single global array you avoid that offset problem..
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.