Author: Ed Schröder
Date: 11:45:54 12/05/01
Go up one level in this thread
On December 05, 2001 at 14:11:34, Dieter Buerssner wrote: >On December 05, 2001 at 13:55:19, Ed Schröder wrote: > >>Well, I never leave it up to the compiler to decide things for me but that's >>easy becausese my background is assembler and my way of programming in C++ >>still is as close to assembler as possible. In your case I would program it >>as follows: >> >>static char direction [65*65]; // create an area big enough, using char > >For zero based squares, this data structure is too big. 64* >64 is enough. Also, becuase 64^2 is a power of two, it may give better >alignment for following data. See my other posting about the why taking somewhat overhead space. It is harmless for the speed of a program, allignment has nothing to do with it, I just waste some memory space to avoid bugs. >>To access the table: >> >>int x,y, char result; >> >>result = direction [x<<6][y]; > >This is an syntax error. You probably mean direction[x<<6+y]. You are right, a bug :) >>That is all. Any good compiler will produce fast code, something like: >> >>mov EAX,x >>mov EBX,y >>shl EAX,6 >>add EAX,EBX >>mov CL,direction[EAX] >>mov result,CL >> >>Note that in your case "char" is enough, it saves an extra SHL 2 (shift-left). > >Actually, it will probably not save a shift. The lea instruction can do in one >cycle a shift and an add. Also the adressing can be done by [EAX*2]. It may well >be possible, that the 2 dimensional array will produce better code, and >certainly is more readable and less prone to coding errors. I think, the "low >level" approach on coding may have given some benifits in "the old days". Modern >compiler produce often very good code by a normal approach. Low level tricks may >even be hurting. For example, the x86 architecture has (as you probably know >very well) efficient adressing modes for indexed adresses. Often the "old" trick >and suggestion of using pointer methods instead of indices for stepping through >arrays, will yield in slower code. On architectures, where it is faster (RISC >with not such sophisticated adressing modes), compilers can figure out these >tricks themselves. Doing it manually can make the best scheduling of >instructions worse, because the compilers then do not see the patterns anymore. >And in the case of index calculation, it may forget about the tricks, that can >be done by lea, and really use shift and add, when one lea is enough. > >I had written quite some assembler code. Often nowadays C is faster then my code >from 386 days, because of all those scheduling/pipelining issues, that I don't >know about anymore. Of course, this is not allways the case. But my suggestion >would be, to limit all those low level tricks to really very few cases. I can not share your opinion although your point about the lea instruction is true and my above listed assembler code surely can be improved. The net gain to move C to ASM is still 30% if not more. I have checked MSVC 6 and the ASM code it generates is to cry about. Ed >Regards, >Dieter
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.