Author: Christophe Theron
Date: 09:02:05 06/15/02
Go up one level in this thread
On June 15, 2002 at 10:38:33, Robert Henry Durrett wrote:
>
>It is noteworthy that the Fritz programmers saw fit to produce a pocket version
>of their larger Fritz program [engine + GUI]. Whatever it was that motivated
>those programmers to do that perhaps ought to apply to the amateur chess
>programs and programmers too.
>
>Note the thread on Hiarcs8. That thread seems focussed mainly on the speed
>aspect, but it highlights the idea that the "size" of a computer may need to be
>considered when optimizing the design of any chess program.
>
>For the handheld computers, the processors may be different enough from
>processors on large computers that a different approach to programming might be
>required to obtain optimal [or reasonably near-optimal] performance on this
>CLASS of computer.
I don't think so.
The successful micro chess programs designed 15 to 20 years ago were similar in
philosophy to the current programs performing well on todays very fast
computers.
They were running on hardware comparable or even inferior to the one currently
used in handhelds.
>It is interesting [to me, at least] to speculate on the extent to which the
>chess programmers rely on computer size considerations when designing their
>programs.
>
>A trivial example is the issue of hash table size. A few versions back,
>[5.3.2?] the Fritz people published a formula for optimal hash table size. The
>optimal size depended on how the program was to be used [Ex: Bullet chess
>versus overnight analysis of a position] and the speed of the computer. This
>formula may or may not still be valid for Fritz. Whether or not it ever was
>correct for non-Fritz computers is an open question.
>
>Obviously, if the computer were too small to provide the optimal hash table
>size, then the program would perform less well when compared to performance with
>the correct hash table size.
The problem with this "optimal hash table size" is either due to a flaw in the
programs's design, or simply does not exist.
In general, for a hash table bigger is always better.
The only exception I know is when the program clears the hash table before the
search starts.
In this case, a too big hash table will kill the program at very fast time
controls. The extreme case is the case where the program will take so much time
to clear its hash table that it will lose on time before playing the first move
of the game. That could probably happen to a slow Palm equipped with several
Gigabytes of RAM.
Chess Tiger, before version 14, had this problem. It had to clear its hash table
before every search. Maybe Fritz 5 had the same problem, I don't know.
It was not a big problem on the PC, but I had to explain at that time, over and
over again, that too much hash table in bullet games was not good.
When I have ported Chess Tiger to the Palm, retaining exactly the same code as
the PC version, I have realized that it would hurt even more on the Palm.
So I have rewritten my hash table management to avoid the "clear before search"
operation.
From version 14 and on, the only advice about Chess Tiger's hash table size is:
the bigger the better.
There is no "optimal" hash table size. From a mathematical point of view, the
curve plotting the program's performance against hash table size is always going
in the up direction. There is no inflexion point, so there is no "optimal"
discrete value.
>It seems reasonable to assume that the manufacturers of the handhelds had to
>make many compromises, other than speed reduction, to come up with a workable
>"handheld" design [compromises in hardware and operating system, and perhaps in
>compatible compilers, too].
Compromises in the complexity of the chess engine, yes. But that does not mean
they had to take a different approach in programming.
>Each of these compromises could be examined, one at a time, to see it's impact
>on chess program performance. In cases where the impact is negative and
>significant, it would then be logical to look at the chess program itself to see
>if changes could be made in the program to minimize the adverse impacts.
There are not many cases where this will result in a dramatic change in the
program's design.
For example if you do not have much memory you remove the hash table management
code. The program will also be a little bit faster because of this.
I would not call this a "different approach in programming".
>For the sake of completeness, one might also wonder whether or not the small
>size had any software benefits relative to the desktops. It seems unlikely that
>there would be any such advantages. [Agree?]
I agree. There is no advantage.
>This topic should distinguish between engine issues and GUI issues. It is
>obvious that numerous GUI mods are required. But what about the engines
>themselves?
Chess Tiger for Palm and Chess Tiger for PC share the same engine code.
While I would not say that Chess Tiger for Palm is the best thing you can write
for a handheld, I think it is good enough to demonstrate that it is possible to
design a program so it runs rather well at any kind of speeds (in a reasonable
range of course, say 2MHz to 4GHz).
If memory size and processor constraints were even tougher, I think I would
simply drop parts of the engine (for example hash tables, some parts of the
evaluation), but I would never have to go for a different approach in
programming.
Christophe
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.