Author: Ed Schröder
Date: 10:51:30 02/25/01
Go up one level in this thread
On February 25, 2001 at 12:33:45, Christophe Theron wrote: >On February 24, 2001 at 18:58:07, Mogens Larsen wrote: > >>On February 24, 2001 at 17:20:10, Fernando Villegas wrote: >> >>>The point is the sheer size of the jump from one kind of hardware to another. Of >>>course I know, as everydoby else, about improvements due to equipment, but this >>>one is so large that, looking things from a reverse point of view, It could be >>>said that the negative jump from a very fast hardware to a more average one is >>>too great. And if the negative jump is too great, then I have certain ground to >>>consider that when the product was commercially released they did not put >>>enough concern in how the thing was going to run in an average kind of machine >>>proper of the average consummer, even in CCC. Or to say again in another way: >>>delivery was premature at the cost of the purchaser. My idea is that even in >>>chess programming, as in fact practically does almost every company of >>>programmer, you ensure that the release will be enough good for the average >>>machine proper of time. That's the reason that we, with machines from 90 to 800 >>>Mhz, all can say this or that product is very good, etc, although recognizing >>>that with the fastest one is better. The point is they give us something good >>>even when running in no so fast equipment. So we not complain about Tiber or >>>Rebel on the ground that they only run OK when loaded in a 1,2 Giga monster. >>>I hope my point is clear, Mogens >> >>Yes, I do understand what you're saying. The point just isn't a valid concern in >>my opinion. To my knowledge all top chess programs performs at a high level on >>less than impressive hardware. There may be problems with certain processors >>or/and very low clock speeds, but nothing that spoils the experience of a good >>chess program AFAIK. >> >>The ones that don't, comparatively speaking, do so because of the way they're >>constructed by the author. A prime example would probably be CS Tal, even though >>I've never tried the program. It would be a shame if that project had been >>compromised or cancelled due to speculations about processor speed. >> >>Requirement of certain conditions that needs to be fulfilled imposes a >>limitation on ideas IMO. That isn't a sound development for the consumer or the >>program authors. >> >>So I honestly don't see a problem lurking in the horizon. > > > >Here is the way I see this matter: there are some programs that SUCK if they are >not run on the fastest computers available. > >Saying that they need faster hardware to exploit their full possibilities is >just an excuse to hide the very poor performances on more standard hardware. > >I'm not saying here that it is the case of Gandalf or Chess System Tal. I don't >own these programs, and I have not seen enough games to give an opinion. > >Look: in a chess game, when it is your turn to move, you have the choice >between, say, a dozen moves that do not lose immediately. > >The more you think on the position, the more moves you are going to discard >because you can see with more time that they lead to bad positions. > >After a good while you are left with 2 or 3 playable moves. Choosing between >them is a matter of taste, or a matter of "playing style", and thinking more >about it is just going to be a waste of time. > >If a program is not able to see deep enough, and evaluate correctly, then if it >is not given enough time it will from time to time play a bad move and lose. >Then it is no surprise that, given enough time or enough processor power, even >poor programs are able to reach the point where they have successfully discarded >the bad moves and are left with the very few moves that are playable. > >And so it is no surprise that these inferior programs are able to compete with >much better ones only when you use very slow time controls or very very fast >computers. The best program is able to reach very quickly the point where only >playable moves are identified, and all the extra time is not going to help it >(it's like flipping a coin to decide which move amongst the 2 or 3 left you are >going to play). The other program is going to need much more time, but it does >not matter as anyway it has been given enough time or processor resources. > >If the number of possible moves in chess was higher, this effect would be less >obvious. > >That's an attempt to explain the so called "dimishing returns" in computer >chess. > >You can go even further and imagine what could happen if programs are given an >"almost" infinite time. They do not need high chess knowledge anymore. They just >need to know the basic rules and to be able to identify a checkmate when it >happens, because given enough time you can see all the forced lines from the >beginning to the end of the game. Then would you say that a program with almost >no chess knowledge is as good as one with a lot of knowledge just because, given >enough time, they are almost equal? > >Certainly not. > >Now you understand why I always find extremely doubtful the claims that a given >program needs longer time controls or more processor power in order to achieve >its full strength. It is either not true (people claiming this have not played >enough games to demonstrate their point), or it is true and in this case it >simply shows that the program in question SUCKS. > > > > Christophe Thanks for a great contribution Christophe. I like to mention something typical for chess programmers, I know it is true for me and it might give a another direction on this ever returning topic. I never gave much attention to blitz games, it simply has not my interest. Having such a programmer mentality you will find it back in the engine of the programmer. Even in the latest Rebel I spoil a full second on the book search, the log-file and other stuff (that can be optimized for speed). Add up the use of EOC or CAT which is recommended to have it active and it will take even longer than one second. Rebel also doesn't minimize the hash table size playing blitz. As you see my typical programmer behavior results in a speed-loss of 25-30% (or more) playing blitz games because I don't care much about blitz but focus more on longer time controls. More: I think this group of chess programmers (it is true for me) when programming they keep in mind the current state of art of nowadays hardware. Some typical considerations are: 1) Add an extension 2) Add new chess knowledge As we know both subjects are extremely important for the ply-depth of the program. In case of an extension I notice the performance and its drawback (the loss in ply-depth) and I may decide to leave the extension for the simple reason that with nowadays fast hardware the extension is an overall improvement on longer time controls. It is about the same for adding new chess knowledge. You write a new piece of code which does well so you leave it in the program. On the other hand you realize that the code when rewritten from scratch could perform much faster. At that point you have 2 kind of chess programmers, the lazy ones and the perfectionists. The lazy one thinks, "who cares next year my program runs twice as fast due to hardware speed doubling why spend 2-3 days making my program 1-2% faster overall". All of this (especialy point 1) can be reasons why some programs are better at longer time controls than at blitz, or do better on fast machines because the hardware was in their mind when writing the program. One bottom line: a programmer should not complain about the hardware nor the time control as it was his deliberately choice to program the program as it was released. Ed
This page took 0.01 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.