Author: Robert Hyatt
Date: 10:31:25 10/24/03
Go up one level in this thread
On October 23, 2003 at 20:12:16, Vincent Diepeveen wrote: >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. Not if you use lib calls. You make the choice to do it in asm... There are plenty of apps that don't do this. You don't _have_ to do it that way. > >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!! > Utter bullshit. Crafty is a pure-C program. It has _replacement_ code for a few very small functions like PopCnt() and FirstOne()/LastOne() that is written in assembly. But it will compile and run fine _without_ any asm whatsoever. And there are no assumptions about "at which registers certain variables get put". That is your nonsense. >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!! > That is pure ignorance. I have some results from a quad opteron that is producing > 5 M nodes per second. Itanium has also produced very good numbers. I wish you would stop making numbers up or pulling numbers out of your hat that are meaningless in normal context. Did you notice that crafty on the k7 was _faster_ than the Itanium? That is simply wrong for any numbers Eugene has ever supplied. >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! Yes, that Itanium processor _really_ depends on a program being readable. If the compiler can't read it, it gets confused and produces poor code. Don't believe all the optimizer guides at all, readability is everything. (sarcasm off) > >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.