Author: Vincent Diepeveen
Date: 17:12:16 10/23/03
Go up one level in this thread
On October 23, 2003 at 13:08:05, Christophe Theron wrote: >On October 23, 2003 at 07:04:17, José de Jesús García Ruvalcaba wrote: > >>On October 23, 2003 at 05:55:12, Daniel Clausen wrote: >> >>>On October 23, 2003 at 05:31:26, José de Jesús García Ruvalcaba wrote: >>> >>>>In a programming course (several years ago) we had to write the final project >>>>for two different plattforms (in my case an old HP9000 and a PC under FreeBSD), >>>>and the source code had to be identical, no changes allowed. I agree that it is >>>>not really difficult, only some discipline is needed. >>> >>>It really depends on the program. >>> >>>The GUI-part is easily platform-dependent. >> >>Yes, of course. In our case, we were allowed to use #IFDEF statements to check >>the environmental variables, but the source files had to be identical (strictly >>speaking the source code was not identical for both compilers, but you get what >>the teacher meant). Disciplined students (like me) had a strict separation >>between platform-dependent and platform-independent code. >> >>>(like Arena, xboard, winboard etc) >>>There are toolkits around, which are available for multiple platforms, but most >>>aren't. >>> >> >>Correct. But even if you use these toolkits, it still makes sense to keep the >>platform-dependent code to a minimum. >> >>>The engine itself could easily be platform-independent, except for a small part. >> >>A chess engine is a good example for a program that can be written almost >>completely portable. >> >>>(like multi-threading etc) Of course, as soon as you write something in Asm it >>>looks different, but if it's just a tiny part, that's easy to port too. >>> >>>Sargon >> >>Portable code has some performance issues. It is probably not the best idea for >>performance critical tasks. In case somebody writes non-portable but faster code >>(or even assembler), I think it is a good idea to keep a portable (slower) >>version of the same functions. But I have self not written any code line in >>years, so do not take me too seriously (: >>José. > > > >The source code of Chess Tiger is portable (using #if in some places) and can be >compiled for the following platforms >* DOS (several compilers) >* Windows >* PalmOS >* Linux (not completely finished, but close) DIEP: IRIX, Linux (x86 but also Itanium2), Windows, Palm PC, Windows CE, HP-UX, SUN/Solaris, Alpha!! Most don't even work at alpha because 'long int' == 64 bits there!!!!! Everything the engine needs works both for all endian forms and shapes as it's bytecode. Very important is that the parallel code is also very portable code. >I don't use ASM and I don't want to use ASM, that's why achieving portability >has been possible. We completely agree at the basic principle. I have a few defines of course for which code to use to lock. That's nearly always system dependant. Even within linux it's completely different for itanium platform than for x86 when using multiprocessing. For this reason i find for example crafty a very bad example of how to write code. Nearly every function it calls in the end is platform dependant! Even assuming at x86 at which registers certain variables get put!! What i also do avoid in diep is writing out code for black and white. I have neat loops there where easily possible: for( side = 0 ; side <= 2; side++ ) I sure can win a few % there. Another thing i avoid is mixing 8 bits with 32 bits code. I really try to avoid mixing different types whereever possible. Only for node counts i have 64 bits variables, simply because 32 isn't enough there. >I view portability and readability as more important than the few percent >performance I could get from writing some parts in ASM. Again i agree completely. A very good example is that in so many patterns in my evaluation i can speed diep a very little bit up by doing next: Current code: if( board[sq_xx] == piece && color[sq_xx] == xside .... Trivially i can rewrite this ugly by writing out black & white. Another way to speed this up in what i think is ugly: if( !((board[sq_xx]-piece)|(color[sq_xx]-xside)) .... All together i'm sure i can get diep like that 20% faster with all those dirty tricks (assembly even more perhaps), especially the 8 bits code would rock at the K7 (and do poor at the opteron). Yet i prefer to write neat code and not need to work fulltime every year like Frans Morsch just to be ready for the next cpu :) Each new generation cpu diep profits MORE from than other bad coded programs. Take for example going from K7 to itanium2. specint crafty K7 2.0Ghz : 1163 specint crafty itanium2 1.3Ghz : 907 DIEP K7 2.0Ghz == itanium2 1.3Ghz Crafty doesn't even seem to profit from the fact that it's a 64 bits processor, where diep which is a 32 bits program and where the tiny 16KB L1 caches from the itanium2 are not helping much either!! The only reason why diep is so fast at itanium2 without doing a thing for it except a few hours of PGO (where i didn't need to be present), is because diep is PORTABLE, very well readable and so on! Note that i didn't find any PGO options yet in visual c++ NET 2003 7.1. BAD BAD BAD!!!!!!!!! > Christophe
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.