Fruit's Board Representation?

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Postby Tom Likens » 29 Apr 2005, 15:41

Daniel Shawul wrote:
This sounds a bit less efficient (on x86 hardware) than the functional equivilant

#define A1_OFFSET 64
#define BOARD(sq) board_[(sq) + A1_OFFSET]


i use the pointer technique. how much is this slower?
I woder how deep i have to know c in order to program chess efficiently,cause everytime i think i improved there is something else that is better. May be it is better to study assembly and get it over with.
cheers
daniel


Hey Daniel,

Learning assembler is useful, just to understand the machine you're working on--
but I wouldn't recommend it just to make your program faster. I believe algorithmic
improvements give a greater return on your time investment. According to Christoph
Theron, Chess Tiger is written 100% in C and it's fast as hades. You might be able
to make the argument that a bit of inline assembly is useful for a bitboard
based program, but otherwise the days of pure assembly programs are lone gone.

As for there always been an improvement just around the corner, isn't that
a good thing? It's what keeps the hobby fresh and interesting.

regards,
--tom
Tom Likens
 
Posts: 41
Joined: 27 Oct 2004, 05:03

Postby Anonymous » 29 Apr 2005, 19:13

Daniel Shawul wrote:i use the pointer technique. how much is this slower?
I woder how deep i have to know c in order to program chess efficiently,cause everytime i think i improved there is something else that is better. May be it is better to study assembly and get it over with.


It is probably not worth it to try the offset vs. pointer method. I forgot to mention one important thing, too. When board_ is not global (so you pass it around by one way or the other between functions - of course you pass it by reference, not by value), you will need that indirection I mentioned, anyway. And the points I mentioned about the optimization will be also valid for arrays passed to functions - in this case they behave exactly as pointers, and will make some optimizations impossible.

I think, it can help to understand some inner workings, of how compilers and machines work (for example to understand, the point I tried to make: pointers make some optimizations impossible, and also need one indirection more than a normal array access). Those, who have programmed in assembler, will most probably be aware of these subtle points. But it won't be worth it to learn assembler for this. One exception really is some fast bitboard routines (which I luckily don't need). My engine does not use any assembly/inline assembly at all, and I doubt very much, I could make it significantly faster with assembler.

Sometimes, clever C code will be better in practice, even for some seemingly low level bitboard routines. I showed Robert Hyatt a firstone routine, that is faster, than his assembler. Similar for popcount. Those routines where tailored to 32 bit computers, however (the assembly is of course also tailored to one environment - even more. So no real disadvantage).

Regards,
Dieter
Anonymous
 

Postby Daniel Shawul » 30 Apr 2005, 06:05

Hi Tom and Dieter
Thanks for the suggestions.
I don't pass my board to funtions. I like to make
all of my funtions member funtions of the struct(c++ style).
I know this may be slower but i do it for code clarity.
I don't know how c++ handles this. May be it passes a pointer
to the member data to the member functions, and the slow down may
not be there.
If this is not the case and the speed up is >= 10% i might try it.
best
daniel
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Postby Daniel Shawul » 30 Apr 2005, 07:43

when i think about it, the *this* pointer of c++ does this purpose!
i mean
Code: Select all
pstack->eval()   ,and  eval(stack* psack)

are equal in speed. Am i right?
User avatar
Daniel Shawul
 
Posts: 366
Joined: 28 Sep 2004, 09:33
Location: Ethiopia

Postby Dann Corbit » 02 May 2005, 21:10

No essential difference in speed.

Code for clarity.

The place to improve speed is via a better algorithm.

Tweaks are a desperation measure and should be considered compiler version specific. You might get a ten % speedup on one version of a compiler and a ten % slowdown using the same compiler with the next version. In fact, I have seen this many times.

An algorithmic improvement generally gives better and better improvement with faster compilers and machines.

For sure, that is the most productive place to focus your energies.

IMO-YMMV.

P.S.
The way to find out where to work on the algorithm is with careful profiles of many different and frequently occurring chess situations.
Dann Corbit
 

Previous

Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 8 guests