Author: Dieter Buerssner
Date: 18:42:18 09/15/01
Go up one level in this thread
On September 15, 2001 at 16:17:52, Vincent Diepeveen wrote: >On September 15, 2001 at 15:23:29, Bruce Moreland wrote: > >>On September 15, 2001 at 14:30:40, Vincent Diepeveen wrote: >> >>>On September 15, 2001 at 11:14:36, Sune Fischer wrote: >> >>>> bb ^= mask[to_square]; // remove the bit >>>> >>>> movelist[++counter].from=from_square; >>>> movelist[counter].to=to_square; >>>> movelist[counter].piece=QUEEN; >>>> movelist[counter].capturedpiece=enemy.piece[board.id[to_square]]; >>> >>>this looks ugly. Using a pointer here would be way faster. >> >>Not necessarily. If the "counter" variable is enregistered by the compiler, you >>end up with about the same thing as if you used a pointer, but it also depends >>upon how large the elements of "movelist" are. > >If compilers optimized very well, then our problems would be solved Bruce, >we could go write our programs in JAVA or C++ and let the compiler handle >the problems of not allocating and removing objects. I don't agree. There are too many priciple things that just cannot be optimized, as one would like. Especially when pointers come into play. If you take the adress of an object at some point, many optimiatation possibilities are just gone, because of alias issues. The same is true for the references pointed out in the other post. Actually, I found that gcc optimizes array code too well too often for x86 (not for alpha or MIPS, when I tested last). Often this will need additional variables for the pointers magicially used, where the indexed access is de facto free often on x86, as Bruce has explained. Most of my numerical code runs faster when optimized with -O with gcc, instead of optimizing it with -O2, where, at the time I checked, all array code was converted to pointer code. However, in the above example counter seems to be a global variable. Here most probably a pointer really will be faster. And, in exact this case, I also would use a pointer. >Also we would be able to use old Qbasic code in a very efficient way then. > >That's not what happens however. Usual it's smart to NOT trust the compiler. > >When patterns get complex then i saw that visual c++ makes huge optimization >errors. > >Like if i check for 2 non-array/pointer entities for being zero: You mean if (a == 0 && b == 0) ? >if( a & b ) > then do this and that; Which is neither the same as if (a & b) or a if (a && b) > to produce some crap assembly: > CMP EAX,0 > JNZ LOOP > CMP EDX,0 > JNZ LOOP1 integral type a, b; if (!(a|b)) do this will produce something like or eax, edx jnz some_label and does not have the disadvantages of your "+" method. And, to get a bit more on topic. Something like above can be useful for bitboards, that are "home-made" by two 32 bit variables. bitboard a,b if (a&b) can be coded as if ((a.word1&b.word1)|(a.word2&b.word2)) which can save a branch compared to if (((a.word1&b.word1)||(a.word2&b.word2)) Note the binary compared to the logical or. Compilers I checked used the second method internally, when using 64 bit types. >In general the above construction makes no sense. Optimizing it with a >pointer is always safer! No. Regards, Dieter "Premature optimization is the root of all evil in programming." C.A.R. Hoare
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.