Author: Vincent Diepeveen
Date: 01:19:20 09/17/01
Go up one level in this thread
On September 16, 2001 at 23:04:39, Robert Hyatt wrote: >On September 16, 2001 at 16:30:51, Vincent Diepeveen wrote: >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. Oh well OR or AND are basically the same as you can rewrite any expression with them. Most likely someone teaching logica can write here some smart statements about it down, but you can also look it up in a book! > >> >>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. Good point >2. we might be able to access some parts of the CPU that the compiler is >(currently) unaware of. IE MMX. 3d-now, etc... that's of course true when you design for certain processor, but i was more out for next case where you can also in general write assembly that is both fast on P3,K7,P4 whereas the same speed win is impossible in C, because branches are dead slow on them and the C compiler laughs at you and simply reduces the number of instructions used instead of the smart human who uses just ONE instruction more and has a better fall through prediction there on average. In future huge penalties for branch misprediction will remain. The concept of the IA64 is of course a major joke as it lets the compilers handle the prediction and the thing is only clocked like a pathetic 800Mhz or so for the time being, apart from its huge price. In short nearly no one is using the IA64, for sure not the average fan from DIEP is going to use IA64, and the real fast K7,P4 and P3 processors and their future designs will most likely suffer even bigger penalties for misprediction if they allow more instructions a clock. It is this later case where you write code, this also can be done in C, where you avoid branch mispredictions by fall through, where a lot of speed can be gained! However the problem is that the compiler rewrites those branches! What i would need is a single option in the compiler to not rewrite the fallthrough principle of a branch. So use an extra instruction like unconditional jumps to garantuee the branch. I'm not a compiler expert of course to know this, but even better for and perhaps doable would be a special statement inside the code letting the compiler know that this branch must follow fallthrough principle and shouldn't get rewritten. That's even better! I already shipped this suggestion to the gcc team years ago and i have been repeating this. Of course i not even got back answer to the suggestion, because they probably receive huge loads of freak demands and no one is going to implement it in gcc anyway, as those are only parttime discussiongroup members, perhaps 1 or 2 of them really code sometimes something. A good example is next: the chance that a queen is 2 steps away from opponent king, that's a very unlikely place for it in general. These patterns only get evaluated anyway when it is middlegame, so the chance is real small the queen is there. Now i get for those patterns the full penalty! I feel a small addition in C can speed the C language up bigtime here. I have learned to rewrite things such that more PII instructions can get used, but i really miss the ability to let me predict the branches for the program, whereas in the meantime i must of course use -O2 at least otherwise speed of the program is a disaster! > > > >>Vincent
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.