Author: Matt Taylor
Date: 23:33:30 01/30/03
Go up one level in this thread
On January 30, 2003 at 04:55:09, Bruce Moreland wrote:
>On January 29, 2003 at 23:29:36, Russell Reagan wrote:
>
>>http://members.home.nl/matador/chess840.htm#INTRO
>>
>>From Ed's page...
>>
>>switch (piece_type) { case 0 : goto empty;
>> case 1 : goto white_pawn; // evaluate white pawn
>> case 2 : goto white_knight; // evaluate white knight
>> case 3 : goto white_bishop;
>> case 4 : goto white_rook;
>> case 5 : goto white_queen;
>> case 6 : goto white_king;
>> case 7 : goto black_pawn; // evaluate black pawn
>> case 8 : goto black_knight;
>> case 9 : goto black_bishop;
>> case 10 : goto black_rook;
>> case 11 : goto black_queen;
>> case 12 : goto black_king; }
>>
>>
>>On one portion of Ed's discussion of Rebel (see above), he talks about using
>>"indirect addressing". I get the impression from Ed's words that this method is
>>supposed to fast. I understand his discussion to mean that if you create a
>>switch statement like he does, you create a jump table and avoid a bunch of
>>conditionals.
>>
>>However, in past discussions, I recall hearing that using a function pointer is
>>going to be at least as slow as conditional, so I asked someone, and was told
>>that Ed's example should be no different than using a function pointer or
>>virtual functions.
>>
>>Ed talks about this method as if it is a good thing to use. So what is the
>>advantage of it? Either someone is mistaken, or Ed and the guy I talked to are
>>talking about different things.
>
>If you have a bunch of cases in a switch statement, I think it is probably a
>good idea to have them sequentially numbered starting at zero, so the compiler
>has more options, which is what Ed is doing.
The compiler will sort them to determine whether or not it can efficiently use
jump tables. So far as I have seen, they are always laid out in memory exactly
as ordered. Thus it is preferable to put cases more frequently triggered first
(like pawns) and cases less frequently triggered last (king/queen). In the case
of a jump table, it makes no difference, but for if/then/else constructs it
does.
>The compiler should understand this case and produce good code without you
>having to get obscure and strange.
>
>In the example you posted, you don't have to have all of the goto's. You can
>put code in there like you are "supposed" to.
That is the best idea. I think a compiler that can recognize the goto stuff Ed
uses will also be able to efficiently convert a "regular" switch/case to a jump
table.
>It is very possible that the compiler will move code around anyway, so who knows
>what you will actually get, as opposed to what you are trying to get?
Not only possible, but probable. In the case of a switch/case, if a reasonably
small table can be generated, the compiler will convert it into a jump table.
(There is an algorithm to generate optimal tables from cases, but I do not
recall specifics.) In other cases, the compiler will use if/then/else when more
efficient.
>I think it's a bad idea to try to out-smart the compiler, certainly it is before
>you figure out that the compiler is doing something that needs out-smarting.
-Very- true.
>This speed stuff is worth thinking about, but it's way more important to think
>about move ordering, pruning, extensions, and good eval.
>
>bruce
-Matt
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.