Author: Bruce Moreland
Date: 10:23:17 01/02/03
Go up one level in this thread
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*. 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. >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
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.