| |
Main
Date: 24 Nov 2005 03:16:25
From: Major Cat
Subject: CPU Speed and Program Time Controls
|
I have a question for those participants
who are familiar with the technical side
of hardware/software used by a machine to
_play_ OTB chess.
Can one simulate the evaluative strength
of a chess program as it would play on a
hypothetical PC having a "slower" CPU by
setting the _machine_ time control more
restrictively in another machine having
a "faster" CPU that runs the very _same_
program under _identical_ settings (other
than the machine time control, of course)?
Are there any other hardware-related issues
that one should keep in mind which would
practically kick in because PC technology
continually evolves (e.g., memory chips,
hardware caches, multiple processors, program
compilation efficiencies and so on)?
Major Cat
|
|
| |
Date:
From: Martin Brown
Subject: Re: CPU Speed and Program Time Controls
|
|
| | |
Date: 28 Nov 2005 08:17:56
From: Major Cat
Subject: Re: CPU Speed and Program Time Controls
|
Thank you for your input. I will start
a new thread on the nature, mechanics
and importance of a machine "thinking"
while a human opponent is contemplating
his next move. "Permanent brain" and
"deep thinking" are two of the terms
that I have come across in the past.
Martin Brown wrote:
>
> Major Cat wrote:
>
> > I have a question for those participants
> > who are familiar with the technical side
> > of hardware/software used by a machine to
> > _play_ OTB chess.
> >
> > Can one simulate the evaluative strength
> > of a chess program as it would play on a
> > hypothetical PC having a "slower" CPU by
> > setting the _machine_ time control more
> > restrictively in another machine having
> > a "faster" CPU that runs the very _same_
> > program under _identical_ settings (other
> > than the machine time control, of course)?
>
> Yes in a rough and ready fashion. But you may not be able to set short
> enough time controls to simulate running on a really old PC.
>
> You would probably be better off hobbling the CPU with one of the
> programs designed to allow retro shoot em up video games to run on
> modern kit. Try at your own risk:
>
> Google "+CPU +slow +down"
>
> If you hobble the resources so that it searches at the same number of
> nodes per second as an antique machine that should be pretty close.
> >
> > Are there any other hardware-related issues
> > that one should keep in mind which would
> > practically kick in because PC technology
> > continually evolves (e.g., memory chips,
> > hardware caches, multiple processors, program
> > compilation efficiencies and so on)?
>
> Modern PC's tend to come with immense amounts of ram and secondary
> caches that are about the same size as the maximum external ram on the
> oldest PCs!
>
> Again some of these can be neutered by suitable device drivers and/or
> stress testing tools.
>
> Regards,
> Martin Brown
Regards,
Major Cat
|
| | | |
Date: 29 Nov 2005 11:26:20
From: Guy Macon
Subject: Re: CPU Speed and Program Time Controls
|
Major Cat wrote:
>I will start
>a new thread on the nature, mechanics
>and importance of a machine "thinking"
>while a human opponent is contemplating
>his next move. "Permanent brain" and
>"deep thinking" are two of the terms
>that I have come across in the past.
I just wanted to mention that I appreciate you starting
a new thread. It makes it the newsgroup a lot easier to
use.
|
| | | | |
Date: 29 Nov 2005 08:23:13
From: Major Cat
Subject: Re: CPU Speed and Program Time Controls
|
Guy Macon wrote:
>
> Major Cat wrote:
>
> >I will start
> >a new thread on the nature, mechanics
> >and importance of a machine "thinking"
> >while a human opponent is contemplating
> >his next move. "Permanent brain" and
> >"deep thinking" are two of the terms
> >that I have come across in the past.
>
> I just wanted to mention that I appreciate you starting
> a new thread. It makes it the newsgroup a lot easier to
> use.
Anytime, even at running the risk of
being perceived as somewhat...pedantic! 8 >)
Regards,
Major Cat
|
| |
Date: 25 Nov 2005 01:21:41
From: Simon Waters
Subject: Re: CPU Speed and Program Time Controls
|
On Thu, 24 Nov 2005 03:16:25 -0800, Major Cat wrote:
> Can one simulate the evaluative strength of a chess program as it would
> play on a hypothetical PC having a "slower" CPU....
I suspect it is possible to "noble" a CPU to behave like a slower CPU, but
it would be quite difficult (non-trivial) in most cases. It is certainly
possible to model it, to work out the impact of specific processor
changes, but that would be much slower, as all modern processors are
carefully modelled in this way before they are built.
> Are there any other hardware-related issues that one should keep in mind
> which would practically kick in because PC technology continually evolves
> (e.g., memory chips, hardware caches, multiple processors, program
> compilation efficiencies and so on)?
The obvious one is processor cache size. This grows with each generation
of processor, and is essential to keeping the faster processors busy.
Access to memory in the processor cache is much faster than normal memory
accesses, and this difference is known to strongly influence the
performance of Chess programs.
Given most processors measure CPU cache in 100's of KB still, for example
the box I'm typing on says 512KB, this is much smaller
than the memory needs of most modern chess playing programs, some of the
RISC chipsets came with 2MB of layer 1 cache on the CPU a fair number of
years ago (this usually came with a hefty price tag). But clearly the
same program, running on a machine with more CPU cache, needs do less slow
memory accesses, and is thus effectively faster than the same "speed" CPU
with less cache.
|
| | |
Date: 25 Nov 2005 03:14:32
From: Major Cat
Subject: Re: CPU Speed and Program Time Controls
|
Thank you for kindly responding to my
post. For a little while, it looked as
if this newsgroup had died from ripe,
old age as discussions involving chess
and computers were taking place in
sister newsgroups instead...
Simon Waters wrote:
>
> On Thu, 24 Nov 2005 03:16:25 -0800, Major Cat wrote:
>
> > Can one simulate the evaluative strength of a chess program as it would
> > play on a hypothetical PC having a "slower" CPU....
>
> I suspect it is possible to "noble" a CPU to behave like a slower CPU, but
> it would be quite difficult (non-trivial) in most cases. It is certainly
> possible to model it, to work out the impact of specific processor
> changes, but that would be much slower, as all modern processors are
> carefully modelled in this way before they are built.
I have a follow on question then. Historically,
have chess programmers been writing their code
to take advantage of the CPU architecture of a
particular CPU generation or did they focus on
the operating system(s) that their software would
be running under instead, under the hypothesis,
perhaps, that an operating system is designed
to take advantage of particular classes or types
of hardware anyway?
>
> > Are there any other hardware-related issues that one should keep in mind
> > which would practically kick in because PC technology continually evolves
> > (e.g., memory chips, hardware caches, multiple processors, program
> > compilation efficiencies and so on)?
>
> The obvious one is processor cache size. This grows with each generation
> of processor, and is essential to keeping the faster processors busy.
> Access to memory in the processor cache is much faster than normal memory
> accesses, and this difference is known to strongly influence the
> performance of Chess programs.
>
> Given most processors measure CPU cache in 100's of KB still, for example
> the box I'm typing on says 512KB, this is much smaller
> than the memory needs of most modern chess playing programs, some of the
> RISC chipsets came with 2MB of layer 1 cache on the CPU a fair number of
> years ago (this usually came with a hefty price tag). But clearly the
> same program, running on a machine with more CPU cache, needs do less slow
> memory accesses, and is thus effectively faster than the same "speed" CPU
> with less cache.
On a conceptually related topic, what
about "hashtables"? I understand that
modern chess programs rely heavily on
them as enhancers of evaluative function
speed. Given that memory chips provide
the hardware underpinnings for this
chess program feature, does the memory
chip architecture/speed matter? Also,
does CPU architecture/speed affect the
efficiency of the "hashtable" feature?
Major Cat
|
| | | |
Date: 26 Nov 2005 22:13:01
From: Simon Waters
Subject: Re: CPU Speed and Program Time Controls
|
On Fri, 25 Nov 2005 03:14:32 -0800, Major Cat wrote:
> On a conceptually related topic, what about "hashtables"? I understand
> that modern chess programs rely heavily on them as enhancers of evaluative
> function speed. Given that memory chips provide the hardware underpinnings
> for this
> chess program feature, does the memory chip architecture/speed matter?
> Also, does CPU architecture/speed affect the efficiency of the "hashtable"
> feature?
Yes, and hugely so. The detail can have a huge impact on the performance,
you'll find Hyatt discussing issues relating to the size of chunks of
memory retrieved to cache affecting performance in the archives, for
someone who clearly understands this.
Certainly GNU Chess searches far faster if you disable hash
tables or shrink them to a size that fits (or nearly fits) into CPU cache,
since you lose the "check hash", and "store hash" calls with their slow
memory accesses.
The real gain with hash tables is not searching from the same position if
it arises by transposition. It is only when the search is large enough
that savings through transpositions exceed the extra cost on store and
retrieve for each position.
Alas for humans this occurs in the order of a second or so on modern PC
processors. On older processors it was 5 to 10 seconds for GNU Chess, so
at very fast time controls it was better to switch off hash tables (except
in positions where transpositions were very common - typically endgames).
Although as implied elsewhere in the thread, one can obsess about
performance of code, and miss the fact that better algorithmns are usually
a far bigger factor.
Of course the real interest these days is how to co-ordinate
multiprocessors in searching efficiently, and good solutions to that
problem will no doubt pay off in other areas of computer science.
|
| | | | |
Date: 26 Nov 2005 21:25:44
From: Major Cat
Subject: Re: CPU Speed and Program Time Controls
|
First off, thank you for taking the time
to contribute to my technical education.
I very much appreciate it. 8 >)
Simon Waters wrote:
>
> On Fri, 25 Nov 2005 03:14:32 -0800, Major Cat wrote:
>
> > On a conceptually related topic, what about "hashtables"? I understand
> > that modern chess programs rely heavily on them as enhancers of evaluative
> > function speed. Given that memory chips provide the hardware underpinnings
> > for this
> > chess program feature, does the memory chip architecture/speed matter?
> > Also, does CPU architecture/speed affect the efficiency of the "hashtable"
> > feature?
>
> Yes, and hugely so. The detail can have a huge impact on the performance,
> you'll find Hyatt discussing issues relating to the size of chunks of
> memory retrieved to cache affecting performance in the archives, for
> someone who clearly understands this.
>
> Certainly GNU Chess searches far faster if you disable hash
> tables or shrink them to a size that fits (or nearly fits) into CPU cache,
> since you lose the "check hash", and "store hash" calls with their slow
> memory accesses.
I had not realized that the "hashtable
cache" and the CPU cache could operate
at cross purposes...
>
> The real gain with hash tables is not searching from the same position if
> it arises by transposition. It is only when the search is large enough
> that savings through transpositions exceed the extra cost on store and
> retrieve for each position.
Is the evaluation of tactically complex
middle game positions the primary benefi-
ciary of "hashtables", then?
>
> Alas for humans this occurs in the order of a second or so on modern PC
> processors. On older processors it was 5 to 10 seconds for GNU Chess, so
> at very fast time controls it was better to switch off hash tables (except
> in positions where transpositions were very common - typically endgames).
On the subject of fast time controls,
if one were to set the machine's time
control at, say, Game in 30 mins and
maintain the human time controls at
classical specs (e.g., 40/2 hrs, 20/1hr,
G/.5hr) would the degradation of computer
play be significant with all this time
that the computer will have to "think"
while waiting for the human to...leisurely
make his moves?
>
> Although as implied elsewhere in the thread, one can obsess about
> performance of code, and miss the fact that better algorithmns are usually
> a far bigger factor.
Is it mainly the structure of the
position evaluative function that
you have in mind?
>
> Of course the real interest these days is how to co-ordinate
> multiprocessors in searching efficiently, and good solutions to that
> problem will no doubt pay off in other areas of computer science.
Yes, from "co-operative multi-tasking"
to "co-ordinated task-slicing"! 8 >)
Major Cat
|
| | | |
Date: 25 Nov 2005 12:13:32
From: Johnny T
Subject: Re: CPU Speed and Program Time Controls
|
Major Cat wrote:
>
>
> I have a follow on question then. Historically,
> have chess programmers been writing their code
> to take advantage of the CPU architecture of a
> particular CPU generation or did they focus on
> the operating system(s) that their software would
> be running under instead, under the hypothesis,
> perhaps, that an operating system is designed
> to take advantage of particular classes or types
> of hardware anyway?
Very historically. Then it was found that compilers actually did good
enough optimization that focusing on chess algorithms and letting the
compilers do what they do resulted in the most ELO/programmer hours.
There have been two notable exceptions, deep blue and hydra that threw
specialized hardware at the problem, yet so far both camps have kept
that hardware fairly secret.
Opterons and Transmeta chips provide some interesting opportunities for
creating CPU specific operations. Some Opterons appear to have enough
registers and onboard cache that you could conceivably do large amounts
of chess work ON-CHIP without having to go out to main memory.
Transmeta chips could conceivably be used to run chess specific
operations rather than strictly x86 code. Finally, it is quite
possible that newer graphic processing cards could be used as either
super fast move generators, or super fast position evaluators.
(re-thinking the math so that it is expressed in shader programs and
pixel space).
But, due largely to Hydra, I suspect it will be a few years before there
is any real motivation to be innovative in chess computer space. The
match in Bilbao has shown that even just on a laptop that the current
programs are tough enough.
The community is going to have to take some time to adjust. I think
there are some possibilities. Stock programs. (Programs that have to
compete on a given piece of hardware, you may discover new algorithms).
Unlimited Class (programs that can run on any given piece of
hardware). Class programs (hardware costs at specific levels. This may
result in clever development of software to certain pieces of hardware.
Start at say 50 bucks and go up. Though the xbox may own the 299
classs).
But for now, the race is over. Time to come up with a new race.
|
| | | | |
Date: 25 Nov 2005 18:15:38
From: Major Cat
Subject: Re: CPU Speed and Program Time Controls
|
Thank you very much for the technical
enlightenment! 8 >)
Major Cat
Johnny T wrote:
>
> Major Cat wrote:
> >
> >
> > I have a follow on question then. Historically,
> > have chess programmers been writing their code
> > to take advantage of the CPU architecture of a
> > particular CPU generation or did they focus on
> > the operating system(s) that their software would
> > be running under instead, under the hypothesis,
> > perhaps, that an operating system is designed
> > to take advantage of particular classes or types
> > of hardware anyway?
>
> Very historically. Then it was found that compilers actually did good
> enough optimization that focusing on chess algorithms and letting the
> compilers do what they do resulted in the most ELO/programmer hours.
>
> There have been two notable exceptions, deep blue and hydra that threw
> specialized hardware at the problem, yet so far both camps have kept
> that hardware fairly secret.
>
> Opterons and Transmeta chips provide some interesting opportunities for
> creating CPU specific operations. Some Opterons appear to have enough
> registers and onboard cache that you could conceivably do large amounts
> of chess work ON-CHIP without having to go out to main memory.
> Transmeta chips could conceivably be used to run chess specific
> operations rather than strictly x86 code. Finally, it is quite
> possible that newer graphic processing cards could be used as either
> super fast move generators, or super fast position evaluators.
> (re-thinking the math so that it is expressed in shader programs and
> pixel space).
>
> But, due largely to Hydra, I suspect it will be a few years before there
> is any real motivation to be innovative in chess computer space. The
> match in Bilbao has shown that even just on a laptop that the current
> programs are tough enough.
>
> The community is going to have to take some time to adjust. I think
> there are some possibilities. Stock programs. (Programs that have to
> compete on a given piece of hardware, you may discover new algorithms).
> Unlimited Class (programs that can run on any given piece of
> hardware). Class programs (hardware costs at specific levels. This may
> result in clever development of software to certain pieces of hardware.
> Start at say 50 bucks and go up. Though the xbox may own the 299
> classs).
>
> But for now, the race is over. Time to come up with a new race.
|
|
