Author: Gerd Isenberg
Date: 07:13:45 01/06/04
Go up one level in this thread
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?
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.