Author: Robert Hyatt
Date: 11:42:48 01/06/04
Go up one level in this thread
On January 06, 2004 at 14:29:30, Tony Werten 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. > >Actually there is :) But only when compared to no local variables at all. In >that case no stack frame has to be set up. ( if there are at most 3 function >parameters and they are integers etc) > >Tony While I suppose you are technically correct, the mov ebp,esp and add esp,n is not much "overhead" in the context of machine cycles. :) Certainly nothing comparable to malloc() for instance. However there are cache issues as I have mentioned in another branch of this thread, that might be important.
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.