Author: Uri Blass
Date: 02:52:24 08/04/04
Go up one level in this thread
On August 04, 2004 at 04:39:57, Russell Reagan wrote: >On August 02, 2004 at 15:05:41, Uri Blass wrote: > >>>Why do you think it would be slower? > >>I know that programmers of programs like Greko had very slow code because they >>used C++ and not C. > > >The reason Greko is slow has nothing to do with C++. Greko uses the STL quite a >bit. That is not a bad thing. The STL allows you to do a lot of things easily, >quickly, and without creating a lot of bugs, but it is also slower. It is just a >tradeoff. The author of Greko preferred the benefits of the STL over having the >fastest program. > >You can write C++ code that uses classes very heavily and is still equally as >fast as a program written in C. Just think of classes as structs that let you >have C-functions attached to them. Using a class will not be any slower than >using a function. In addition, you will get several benefits: > >1. It will be easier to read your code >2. You will have fewer bugs (because of 1 and 3) >3. Bugs will be easier to find >4. You will be able to make changes much easier >5. You will be able to optimize better (because of 4) > >This is what Dann Corbit said about how to write fast code. > >1. Write clear code. >2. Choose good algorithms. >3. Write abstract code that hides the implementatiion details when possible. >4. When everything works well, profile it. >5. Speed up the stuff that will benefit from it > >Classes can help you accomplish numbers 1, 3, 4, and 5 in his list. > >The bottom line is, don't worry about classes making your program run >significantly slower. In the end they will probably help you optimize your >program more effectively. > > >>>Gerd's point was actually that you can *gain* speed by using classes! :-) >>> >>>Code that accesses global variables will have to carry the address of the >>>variable in the instructions. That makes the code larger, and potentially >>>slower. > >>I cannot avoid accesing them and I use hply in many files of the search so I do >>not see an easy solution to get rid of it. >> >>The varaible hply appears in more than 200 places in my code. >> >>I prefer first only to convert time related varaibles to part of the class and >>not global varaibles that are used often. > > >This is a good example of why classes can be very helpful. You can "hide" things >in classes so that you don't have something scattered 200 places in your code. >If you wrap something up in a class, you only deal with it in one or two places >instead of 200 places, and then you can make changes much easier. I guess that you suggest instead of using hply directly to have functions that know about hply and use them when they do not get hply as a parameter. I may do it later but as first step I want to correct my time management. I guess that I may later divide it to more than one class when all the tasks when hply is relevant(like calculating the target time) are going to be in another class. The problem for me now is not algorithm of time management but writing it. I will describe the algorithm that I plan(Note that it is not the final algorithm and it is only a simple version because I was convinced that stopping at the end of the iteration is not the best idea and it is better to use slightly more time to check if there is no fail low and I also think that it may be a good idea to try to finish searching a root move in case that you did not search for a long time like Hyatt suggested). In case of not pondering: 1)Calculate a function to find the target time(already have function for it). 2)Calculate maximal time to use(already have function for it) Note that maximal time to use can be updated in case of fail low. 3)If you had no fail low for the first move and used more than 1/4 of the target time decide that this iteration is the last iteration. 4)At the end of every iteration calculate expected time for the next iteration. 5)If you expect more than twice of the target time decide to play immediatly. 6)If you did not stop because of reasons 3 or 5 you may stop because of reason 2. I have something like this with movei with ponder off but with ponder on it has bugs and I decided that putting the information in a class will make things clearer. In case of pondering I think that the target time can be higher because of pondering the correct move so I basically want to multiply the target time by 3/2 and do the same except deciding to finish the iteration in case of fail low or fail high. The problem in case of pondering is that I want to have different target time in case that I predict the correct move. The reason is that common sense tells me that the target time should be proportional to the maximal time that I am allowed to search and the maximal time that I am allowed to search is not constant. If the opponent reply immediatly it is exactly the time that I have in the clock but if the opponent use 5 minutes then if I ponder correctly I am allowed to use more 5 minutes. The main problem is to decide which varaibles and functions to define in order to have clear code to solve the problem. Last note:It is not exactly correct that the target time should be proportional to the maximal time that I am allowed to search and it should be a function of the vector of times,moves that I am allowed to search. Imagine the following 2 time controls: 1 minutes/next move+1 minute/rest of the game. 2 minutes/next move+1 minute/rest of the game. The first time cotrol is practically the same as 2 minutes blitz(it is usually stupid to use more than 1/2 of your time for a single move) The second time control is practically the same as 3 minute blitz(it is usually stupid to use more than 2/3 of your time for a single move) You can see that inspite of the fact that the maximal time is 2 times bigger the target time should be only 3/2 times bigger. Uri
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.