Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: another bug

Author: Robert Hyatt

Date: 20:04:39 09/16/01

Go up one level in this thread


On September 16, 2001 at 16:30:51, Vincent Diepeveen wrote:

>On September 16, 2001 at 16:20:20, Vincent Diepeveen wrote:
>
>>On September 16, 2001 at 09:28:49, Robert Hyatt wrote:
>>
>>>On September 15, 2001 at 22:33:18, Vincent Diepeveen wrote:
>>>
>>>>On September 15, 2001 at 20:38:36, Robert Hyatt wrote:
>>>>
>>>>>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.
>>>>>>
>>>>>>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:
>>>>>>
>>>>>>if( a & b )
>>>>>>  then do this and that;
>>>>>>
>>>>>>to produce some crap assembly:
>>>>>>  CMP EAX,0
>>>>>>  JNZ LOOP
>>>>>>  CMP EDX,0
>>>>>>  JNZ LOOP1
>>>>>>
>>>>>>Now already people will complain: "you don't need special CMP for
>>>>>>2 different statements". Well they're right.
>>>>>>
>>>>>>In fact you don't need 2 compares even. All you need is something
>>>>>>primitive like:
>>>>>>
>>>>>>  ADD EAX,EDX
>>>>>>  CMP EAX,0
>>>>>>  JNZ LOOP1
>>>>>>
>>>>>
>>>>>
>>>>>That would be terribly dangerous, and if a is 1 and b is -1 you will screw
>>>>>up badly.  The compiler can't possibly know that it can do that unless a and
>>>>>b are unsigned.  And it would be dangerous there as there are two non-zero
>>>>>constants you can add and get zero in an unsigned integer.
>>>>>
>>>>>The compiler would need special information to be able to do the above
>>>>>safely, otherwise the world would be debugging some of the strangest bugs
>>>>>anyone ever saw...
>>>>
>>>>Yeah sorry, there were a few bugs in my example code.
>>>>
>>>>It should read:
>>>>  if ( a && b )
>>>>
>>>>versus
>>>>
>>>>  if( a | b )
>>>>
>>>
>>>that doesn't fix a thing.  If a=1, and b=-1, then you _still_ get a zero
>>>result which is wrong in the context of a && b.
>>
>> 0b11111111111111 | 0b000000001 =  something
>>
>>So you can't go wrong.

You didn't use an OR in the example you gave.  At least I didn't see one.
I saw an _add_ which is not the same thing.


>
>Another bug, shows why i would prefer the compiler doing it!
>
> if( !a && !b )
>
>that might be the same like:
>  if (a | b)


>
>And as we know any term we can evaluate with ! somehow.
>
>  if( a == 3 && b == 5 )
>
>that's the same like:
>
>  if( (a-3) == 0 && (b-5) == 0 )
>
>So that's the same like:
>
>  if( !(a-3) && !(b-5) )
>
>So that deduces to something like:
>
>  if( (a-3)|(b-5) )
>
>That directly shows why i would prefer the compiler do it,
>because source code that shows something like:
>  if( (a-3)|(b-5) )
>
>that kind of source code is hard to read what you planned to do there,
>not very good for maintainability!
>
>Whereas i can reread easily:
>  if( a == 3 && b == 5 )
>
>Now of course a major problem is that nearly all operations are
>array operations.
>
> if( board[sq_something] == bishop && board[sq_else] == anything )
>
>Now compiler builders will for optimizing assume that perhaps
>  board[sq_else] == anything
>will give an exception so they won't optimize this with CMOV* a look
>like instructions. Nor won't they optimize it to a single branch for the
>same reason.
>
>This where usually the source code writer KNOWS that in this pattern it's
>impossible to get an exception. Regrettably there is no way in telling in
>C to the compiler somehow that it can optimize assume that not a single
>illegal array element will be touched by these conditions for this particular
>'if then else'.
>
>I'm really missing this, because i think this is the main speedadvantage
>which one has in assembly over C code nowadays. It's at least a factor of 2
>in DIEP.
>

There are two real advantages we have over a compiler:

1. we know some things about the program that can't be deduced from the
semantics of the program or the language.  IE if I just calculated a+b, and
I know that both a&b are positive integers, I can use that calculation to
test a | b.  The compiler can't.

2. we might be able to access some parts of the CPU that the compiler is
(currently) unaware of.  IE MMX.  3d-now, etc...




>Vincent
>
>>>
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>However i would need to learn assembly for this or i must rewrite
>>>>>>my C code. The compiler isn't smart Bruce. The compiler is very stupid
>>>>>>when talking about source connections. So i have to write:
>>>>>>  if( a+b )
>>>>>>    then do this and that;
>>>>>>
>>>>>>>Using pointers will usually help the compiler out, because it can just indirect
>>>>>>>through a value, rather than having to deal with scaling the value and adding it
>>>>>>>to a constant.  But in some circumstances, scaling it and adding it to a
>>>>>>>constant is free.
>>>>>>
>>>>>>In general the above construction makes no sense. Optimizing it with a
>>>>>>pointer is always safer!
>>>>>>
>>>>>>>bruce



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.