Author: Matt Taylor
Date: 14:27:34 01/02/03
Go up one level in this thread
On January 02, 2003 at 13:23:17, Bruce Moreland wrote: >On January 02, 2003 at 04:33:34, Graham Laight wrote: > >>On January 01, 2003 at 19:12:16, Bruce Moreland wrote: >> >>>I assume that the compiler is going to get it right. If I need to check up on >>>the compiler later, I do. But the point of a high level language is that you >>>can write for clarity, and this should be what you do by default. >>> >>>bruce >> >>In nearly all programming situations, speed is not a serious issue - and every >>effort should be made to make the code clear and readable (this will be far more >>useful and productive than fast code in the long run). >> >>However - in programs like chess, a special situation arises. >> >>* you have loops (or recursions) that repeat a large number of times >> >>* the more of these loops you can do in the time available, the better your >>chances of winning the game >> >>Code outside of these loops is usually trivial in the time it consumes - but >>code within the loops must run as quickly as possible. > >Yes, this is correct. Chess is a freakish case. If someone has a J O B doing >programming, then almost all of the time you are doing meatball stuff where >speed doesn't matter. What matters in meatball stuff is that some other poor >fool comes along later and doesn't screw it up because you were trying to be >tricky, and tricked *him*. Heh heh, agreed :-) >Chess programs are a series of functions that matter intensely, but it's >interesting what doesn't matter. If I could generate "regular" moves within the >tree in zero time, my program would go 3% faster. > >In my program, I have reached the point where twiddling doesn't do very much >anymore, but I can still gain strength by changing algorithms. > >The irony here is that if I have optimized something heavily, it is harder to >change the algorithms. > >So speed optimizing is like pouring concrete on something. It's very sturdy but >you can't change it very well. > >Assembly code is an even more special case of this. In 1995 I had assembly code >in my program. It was a serious impedement to doing anything serious. >Eventually I ripped it out, and by being able to do more experiments in C I was >able to make the program significantly faster in a few days. > >I haven't had any assembly in my program since then, and I don't miss it at all. That is not always true. Algorithms can often be optimized without making unnecessary assumptions. A good example of an optimization that does not "pour concrete" on a program is a recent thread here that involved unpacking bitboards. You basically plug in the assembly routine in place of the C routine. Since they are interchangable, you can go back to the C routine and ditch the assembly any time you like. The real usefulness of assembly in C code comes mostly in capabilities of the machine that C cannot express. In the case above, the machine has an instruction that will find the index of the first set bit in a word (32-bits). C has no way to express this in a manner that a compiler can recognize. Much of the machine's capability is not expressable in C. >>Therefore, I would suggest that code within loops be written very much with >>speed in mind. However - the clarity can be achieved by commenting this >>particular code very heavily. Comments will have no effect on the compiled code. > >Yes, this is the right way to do it. > >However, even then you can sell your soul. If you make assumptions in order to >increase speed, you have to *remember* and *preserve* those assumptions in code >where speed doesn't matter. > >bruce That's what assertions are for. I would tend to agree, though. My biggest coding problem is that I make some assumptions, forget, and proceed to violate them right and left. :-) It's too bad that the compiler can't enforce such things at compile-time. It would make assumptions a little safer. -Matt
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.