NEW ENGINE IN PROGRESS WILL BLOW CRAFTY AWAY
The Macks
Now, as I finish the Legal Move Generator, and begin to revamp other
functions, of course I want to be able to predict how fast my program can
search before I make the rest of the parts.
To compare with two well-known engines: (numbers are for an average
middlegame)
-Chessmaster 5500 analyzes 25,000 positions per second on a P-II 266
MHz w/96 MB RAM (The same computer on which I'm making my program)
-Crafty analyzes 150,000 positions per second on an AMD-K6-II 400
MHz with a lot of RAM
You might be interested in how fast my Legal Move Generator runs: in an
average middlegame, it takes 175 Hz to generate the move list. That means it
runs at a speed of about 1,520,000 times per second (As far as I'm concerned
the number is completely off the map for a desktop PC)
I made a mathematical model to predict various analysis speeds, and the
number I came up with is even more staggering: 2,300,000 to 2,500,000
POSITIONS PER SECOND!
When I first brought this up nobody believed me.... they said "even a fast
550 P-3 couldn't handle anything close to that!"
However, I'm just spreading the word, even if no one believes me. My program
isn't finished, but I'm hoping people will be prepared when it crashes
through all the other engines.... It's just waiting to be unleashed....
Arshad Syed
Arshad
The Macks wrote in message <7ok9vh$s6b$1...@autumn.news.rcn.net>...
li...@ork.net
> However, I'm just spreading the word, even if no one believes me. My program
> isn't finished, but I'm hoping people will be prepared when it crashes
> through all the other engines.... It's just waiting to be unleashed....
I'll be prepared when it crashes....
PMG
Pete
The Macks wrote:
> Two years ago I set out to make a working chess program for fun.....
>
> Now, as I finish the Legal Move Generator, and begin to revamp other
> functions, of course I want to be able to predict how fast my program can
> search before I make the rest of the parts.
>
> To compare with two well-known engines: (numbers are for an average
> middlegame)
> -Chessmaster 5500 analyzes 25,000 positions per second on a P-II 266
> MHz w/96 MB RAM (The same computer on which I'm making my program)
> -Crafty analyzes 150,000 positions per second on an AMD-K6-II 400
> MHz with a lot of RAM
>
> You might be interested in how fast my Legal Move Generator runs: in an
> average middlegame, it takes 175 Hz to generate the move list. That means it
> runs at a speed of about 1,520,000 times per second (As far as I'm concerned
> the number is completely off the map for a desktop PC)
>
> I made a mathematical model to predict various analysis speeds, and the
> number I came up with is even more staggering: 2,300,000 to 2,500,000
> POSITIONS PER SECOND!
>
> When I first brought this up nobody believed me.... they said "even a fast
> 550 P-3 couldn't handle anything close to that!"
>
bruce moreland
wrote:
You can't compare part of a program to a whole program. Of course
part of a program is faster, it's only doing part of the job.
Those moves need to be made and unmade on the board, the resulting
positions need to be evaluated, a large percentage of the moves
generated never even get executed on the board, and a large percentage
of moves that could be generated are not even generated, because they
are pruned out by the quiescent move generator.
Every program starts out where your program is now. It's not that
hard to get past that point and make something that plays chess, and I
hope you do it.
However, it is a mistake to get caught up in move generator macho
hubris. We've seen this before, by the way, every once in a while
someone makes what they think is a fast move generator, and over time
the thing goes slower and slower, until it's in line with every other
new program.
Good luck making good on your claims.
bruce
Tom King
<mm...@erols.com> writes
>Two years ago I set out to make a working chess program for fun.....
>
>Now, as I finish the Legal Move Generator, and begin to revamp other
>functions, of course I want to be able to predict how fast my program can
>search before I make the rest of the parts.
>
>To compare with two well-known engines: (numbers are for an average
>middlegame)
> -Chessmaster 5500 analyzes 25,000 positions per second on a P-II 266
>MHz w/96 MB RAM (The same computer on which I'm making my program)
> -Crafty analyzes 150,000 positions per second on an AMD-K6-II 400
>MHz with a lot of RAM
>
>You might be interested in how fast my Legal Move Generator runs: in an
>average middlegame, it takes 175 Hz to generate the move list. That means it
>runs at a speed of about 1,520,000 times per second (As far as I'm concerned
>the number is completely off the map for a desktop PC)
>
>I made a mathematical model to predict various analysis speeds, and the
>number I came up with is even more staggering: 2,300,000 to 2,500,000
>POSITIONS PER SECOND!
>
>When I first brought this up nobody believed me.... they said "even a fast
>550 P-3 couldn't handle anything close to that!"
>
>However, I'm just spreading the word, even if no one believes me. My program
>isn't finished, but I'm hoping people will be prepared when it crashes
>through all the other engines.... It's just waiting to be unleashed....
>
>
I don't doubt what you say.. but I look forward to the proof of what you
say. When you finish this thing, how about a 20 game match against, say
Chessmaster 5500? Or better, make your engine Winboard compliant, and
you can fight against a *load* of other programs (including mine).
Good luck getting your program up and running.
P.S A decent chess program needs more than just a fast move generator
;-)
Rgds,
Tom
--
Tom King
t...@hatbulb.demon.co.uk
John DeMastri
generate a move tree and the amount of time needed to analyze those nodes.
Good luck to you, but I'd frankly be astonished if you beat Crafty's NPS
with any eval function that allows your engine to play reasonable chess.
It's a non-trivial task. Obviously, you want the move generator to be
absolutely as fast as possible, but after you have your entire system
running, and profile it, you may find that your time's better spent
optimizing the performance of other subsystems.
Keep us posted here, all new ideas are useful!
John DeMastri
The Macks <mm...@erols.com> wrote in message
news:7ok9vh$s6b$1...@autumn.news.rcn.net...
Anders Thulin
The Macks <mm...@erols.com> wrote:
>You might be interested in how fast my Legal Move Generator runs: in an
>average middlegame, it takes 175 Hz to generate the move list.
175 Hz? .... tilt ... Sorry, don't understand.
>That means it
>runs at a speed of about 1,520,000 times per second
To me, 175 Hz is 175 times / second.
And as there's no obvious connection between 175 and 1520000 (175 Hz
means each period is 5.7 ms), your information seems rather to
contradict itself.
--
Anders Thulin Anders....@telia.se 013-23 55 32
Telia ProSoft AB, Teknikringen 6, S-583 30 Linkoping, Sweden
hy...@crafty.cis.uab.edu
: Remember, there's a HUGE difference between the amount of time needed to
: generate a move tree and the amount of time needed to analyze those nodes.
: Good luck to you, but I'd frankly be astonished if you beat Crafty's NPS
: with any eval function that allows your engine to play reasonable chess.
: It's a non-trivial task. Obviously, you want the move generator to be
: absolutely as fast as possible, but after you have your entire system
: running, and profile it, you may find that your time's better spent
: optimizing the performance of other subsystems.
: Keep us posted here, all new ideas are useful!
: John DeMastri
Considering that 50% of Crafty's search time is spent in the Evaluate()
procedure (and its components) the move generator sort of disappears in the
noise. In profile runs, it is not even 10% of the total, in most reasonable
positions...
--
Robert Hyatt Computer and Information Sciences
hy...@cis.uab.edu University of Alabama at Birmingham
(205) 934-2213 115A Campbell Hall, UAB Station
(205) 934-5473 FAX Birmingham, AL 35294-1170
hy...@crafty.cis.uab.edu
: In article <7ok9vh$s6b$1...@autumn.news.rcn.net>,
: The Macks <mm...@erols.com> wrote:
:>You might be interested in how fast my Legal Move Generator runs: in an
:>average middlegame, it takes 175 Hz to generate the move list.
: 175 Hz? .... tilt ... Sorry, don't understand.
:>That means it
:>runs at a speed of about 1,520,000 times per second
: To me, 175 Hz is 175 times / second.
: And as there's no obvious connection between 175 and 1520000 (175 Hz
: means each period is 5.7 ms), your information seems rather to
: contradict itself.
He just used a poor term. I read that as "175 cycles to generate moves".
If your cpu runs at 175K cycles per second (.175mhz) then it can supposedly
generate all moves 1000 times per second...
Unfortunately, that isn't all it has to do. :)
The Macks
hy...@crafty.cis.uab.edu wrote in message
<7ommn7$4sp$3...@juniper.cis.uab.edu>...
>John DeMastri <jpdem...@ameritech.net> wrote:
>: Remember, there's a HUGE difference between the amount of time needed to
>: generate a move tree and the amount of time needed to analyze those
nodes.
>: Good luck to you, but I'd frankly be astonished if you beat Crafty's NPS
>: with any eval function that allows your engine to play reasonable chess.
>: It's a non-trivial task. Obviously, you want the move generator to be
>: absolutely as fast as possible, but after you have your entire system
>: running, and profile it, you may find that your time's better spent
>: optimizing the performance of other subsystems.
>
>: Keep us posted here, all new ideas are useful!
>
>: John DeMastri
>
>Considering that 50% of Crafty's search time is spent in the Evaluate()
>procedure (and its components) the move generator sort of disappears in the
>noise. In profile runs, it is not even 10% of the total, in most
reasonable
>positions...
>
>
>
>Robert Hyatt Computer and Information Sciences
>hy...@cis.uab.edu University of Alabama at Birmingham
>(205) 934-2213 115A Campbell Hall, UAB Station
>(205) 934-5473 FAX Birmingham, AL 35294-1170
Well that information is quite useful. It just makes the mathematical model
I used to estimate analysis speeds a lot more vague. I am a bit surprised at
that 50% figure, but I guess you can put as much or as little in the
Evaluate() functions as you want.
I guess what my model is telling me is that, with a streamlined Eval (which
is what I intended to do) I can run at VERY high speeds.
However, it is theoretically known that the strength of a program is related
to the product of knowledge and speed, so there's always the option of
slowing it down to make it smarter.
My intention was to follow the principle of Deep Blue's eval: reduce the
evaluation parameters to what really affects the position. Deep Blue I think
had only Material, Position, King Safety, and pawn structure, which are all
(relatively) simplified.
A lot of times, when trying to come up with factors that make a position
good or bad, that people tend to overcomplicate things. Usually many complex
ideas can be simplified into fewer, simpler ideas.
Another optimization I thought of with this is approximation. Some very
tedious calculations can be quickly approximated, which is actually a very
human-like trait.
Anyway, I'm curious... how fast is Crafty's Move Generator for an average
middlegame?
You might find it interesting that my Generator' speed depends on the number
of pieces on the board, but not the number of pawns or the number of
available moves! It takes exactly the same amount of time to make the list
for two positions with the same number of each piece, regardless!
Some performance data so far for GetLegal(): (Approximate)
Overhead: 79 Hz (Includes King and Pawn move calculation)
(Higher when castling or en passant is legal and slightly higher when the
king is in check)
Per Knight: 7-8 Hz
Per Bishop: 13 Hz
Per Rook: 23-24 Hz
Per Queen: 36-37 Hz
I think there is an alignment problem with the rook moves (and the "rook"
part of the queen moves) because it should be faster than the bishops.
The Macks
Anders Thulin wrote in message <7om0r4$97v$1...@jupiter.linkoping.trab.se>...
>
> 175 Hz? .... tilt ... Sorry, don't understand.
>
>>That means it
>>runs at a speed of about 1,520,000 times per second
>
> To me, 175 Hz is 175 times / second.
>
> And as there's no obvious connection between 175 and 1520000 (175 Hz
>means each period is 5.7 ms), your information seems rather to
>contradict itself.
I apologize if I've been a bit unclear. My processor runs at 266 MHz, or 266
million cycles per second. To generate the move list for an average
position, it takes 175 Hz, or 175 cycles. By dividing 266,000,000 by 175, I
determine the function can run 1,520,000 times per second. Far from 5.7 ms,
it only takes 658 nanoseconds to run.
rls...@msn.com
hehehe, lets see what the finished product brings. I've learned the
hard way not to shoot my mouth off until I'm finished doing something.
Richard
In article <7ok9vh$s6b$1...@autumn.news.rcn.net>,
"The Macks" <mm...@erols.com> wrote:
> Two years ago I set out to make a working chess program for fun.....
>
> Now, as I finish the Legal Move Generator, and begin to revamp other
> functions, of course I want to be able to predict how fast my program
can
> search before I make the rest of the parts.
>
> To compare with two well-known engines: (numbers are for an average
> middlegame)
> -Chessmaster 5500 analyzes 25,000 positions per second on a P-
II 266
> MHz w/96 MB RAM (The same computer on which I'm making my program)
> -Crafty analyzes 150,000 positions per second on an AMD-K6-II
400
> MHz with a lot of RAM
>
> You might be interested in how fast my Legal Move Generator runs: in
an
> average middlegame, it takes 175 Hz to generate the move list. That
means it
> runs at a speed of about 1,520,000 times per second (As far as I'm
concerned
> the number is completely off the map for a desktop PC)
>
> I made a mathematical model to predict various analysis speeds, and
the
> number I came up with is even more staggering: 2,300,000 to 2,500,000
> POSITIONS PER SECOND!
>
> When I first brought this up nobody believed me.... they said "even a
fast
> 550 P-3 couldn't handle anything close to that!"
>
> However, I'm just spreading the word, even if no one believes me. My
program
> isn't finished, but I'm hoping people will be prepared when it crashes
> through all the other engines.... It's just waiting to be
unleashed....
>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Tord Kallqvist Romstad
>Anyway, I'm curious... how fast is Crafty's Move Generator for an average
>middlegame?
You can find out this yourself by entering the "perf" command in
Crafty. Anyway, as others have pointed out, the move generator is rarely
a critical part of the code. Writing a fast move generator is relatively
easy, writing a fast and good eval is very difficult. My move generator
is probably much slower than yours (I am not sure how many moves I generate
per second), but I do not spend much time optimising it. Less than 5% of
the CPU time is spent in the move generator anyway.
Tord
hy...@crafty.cis.uab.edu
: Anders Thulin wrote in message <7om0r4$97v$1...@jupiter.linkoping.trab.se>...
:>
:> 175 Hz? .... tilt ... Sorry, don't understand.
:>
:>>That means it
:>>runs at a speed of about 1,520,000 times per second
:>
:> To me, 175 Hz is 175 times / second.
:>
:> And as there's no obvious connection between 175 and 1520000 (175 Hz
:>means each period is 5.7 ms), your information seems rather to
:>contradict itself.
: I apologize if I've been a bit unclear. My processor runs at 266 MHz, or 266
: million cycles per second. To generate the move list for an average
: position, it takes 175 Hz, or 175 cycles. By dividing 266,000,000 by 175, I
: determine the function can run 1,520,000 times per second. Far from 5.7 ms,
: it only takes 658 nanoseconds to run.
This is where you lose me, because a single read from memory takes over
20 of those cycles to get one word. A single L2 cache miss takes 14 or
so cycles depending on the processor. 175 cycles gives you time to read only
9 words from memory, and then you have no time left to do anything else. Or
are you 'simulating' this by looking at the number of instructions emitted by
the compiler without regard for how fast the instructions actually execute?
hy...@crafty.cis.uab.edu
: hy...@crafty.cis.uab.edu wrote in message
: <7ommn7$4sp$3...@juniper.cis.uab.edu>...
:>John DeMastri <jpdem...@ameritech.net> wrote:
:>: Remember, there's a HUGE difference between the amount of time needed to
:>: generate a move tree and the amount of time needed to analyze those
: nodes.
:>: Good luck to you, but I'd frankly be astonished if you beat Crafty's NPS
:>: with any eval function that allows your engine to play reasonable chess.
:>: It's a non-trivial task. Obviously, you want the move generator to be
:>: absolutely as fast as possible, but after you have your entire system
:>: running, and profile it, you may find that your time's better spent
:>: optimizing the performance of other subsystems.
:>
:>: Keep us posted here, all new ideas are useful!
:>
:>: John DeMastri
:>
:>Considering that 50% of Crafty's search time is spent in the Evaluate()
:>procedure (and its components) the move generator sort of disappears in the
:>noise. In profile runs, it is not even 10% of the total, in most
: reasonable
:>positions...
:>
:>
:>
:>--
:>Robert Hyatt Computer and Information Sciences
:>hy...@cis.uab.edu University of Alabama at Birmingham
:>(205) 934-2213 115A Campbell Hall, UAB Station
:>(205) 934-5473 FAX Birmingham, AL 35294-1170
: Well that information is quite useful. It just makes the mathematical model
: I used to estimate analysis speeds a lot more vague. I am a bit surprised at
: that 50% figure, but I guess you can put as much or as little in the
: Evaluate() functions as you want.
You can only get so far on search speed. You can be tactically devastating,
but if there are no tactics, you _still_ have to play a move. And without a
decent eval, such a move can easily become a loser..
: I guess what my model is telling me is that, with a streamlined Eval (which
: is what I intended to do) I can run at VERY high speeds.
There have been several 'speed-only' programs over the years. They
generally have not fared very well in games, although they might be
murderous in test suites...
: However, it is theoretically known that the strength of a program is related
: to the product of knowledge and speed, so there's always the option of
: slowing it down to make it smarter.
: My intention was to follow the principle of Deep Blue's eval: reduce the
: evaluation parameters to what really affects the position. Deep Blue I think
: had only Material, Position, King Safety, and pawn structure, which are all
: (relatively) simplified.
This is _not_ what Deep Blue did. Instead, they designed special-purpose
hardware to make their eval faster, without having to exclude anything they
thought was necessary. In fact, they added significantly to their evaluation
over the years, but kept doing so by incorporating that into the hardware so
that the time-cost was zero.
: A lot of times, when trying to come up with factors that make a position
: good or bad, that people tend to overcomplicate things. Usually many complex
: ideas can be simplified into fewer, simpler ideas.
Time will tell. I think you will find that you spend more time handling
'exceptions' than you do handling 'normal cases' in chess. It is that sort
of game...
: Another optimization I thought of with this is approximation. Some very
: tedious calculations can be quickly approximated, which is actually a very
: human-like trait.
: Anyway, I'm curious... how fast is Crafty's Move Generator for an average
: middlegame?
On a PII/300, It can generate about 3.5M moves per second. However, this is
not a real good comparison, because in the chess tree, most of the moves you
need are captures, and there my move generator is very efficient because with
bitmaps, I don't have to loop over empty squares as pieces slide down diagonals
or files or ranks. I can generate captures _very_ efficiently, which is
critical in the q-search.
: You might find it interesting that my Generator' speed depends on the number
: of pieces on the board, but not the number of pawns or the number of
: available moves! It takes exactly the same amount of time to make the list
: for two positions with the same number of each piece, regardless!
Are you sure you are running this on a PC? It sounds like your performance
test is broken and you are measuring processor-to-L2 cache speeds, while in
the real program you are going to have to store the moves in _memory_. ANd
there the PC is a bummer as it has very limited memory bandwidth.
: Some performance data so far for GetLegal(): (Approximate)
: Overhead: 79 Hz (Includes King and Pawn move calculation)
: (Higher when castling or en passant is legal and slightly higher when the
: king is in check)
: Per Knight: 7-8 Hz
: Per Bishop: 13 Hz
How do you detect how far the bishop can slide, since 13 is the number of
moves a bishop can make on an open board in the center? This leaves no time
for testing for empty squares, edge of the board, etc...
: Per Rook: 23-24 Hz
: Per Queen: 36-37 Hz
: I think there is an alignment problem with the rook moves (and the "rook"
: part of the queen moves) because it should be faster than the bishops.
--
The Macks
hy...@crafty.cis.uab.edu wrote in message
<7omuj1$7gu$2...@juniper.cis.uab.edu>...
>This is where you lose me, because a single read from memory takes over
>20 of those cycles to get one word. A single L2 cache miss takes 14 or
>so cycles depending on the processor. 175 cycles gives you time to read
only
>9 words from memory, and then you have no time left to do anything else.
Or
>are you 'simulating' this by looking at the number of instructions emitted
by
>the compiler without regard for how fast the instructions actually execute?
>
Well, I ran performance tests on the finished functions by running the code
in a way that is was cached in the L1 cache before testing began. I did this
because the code for all parts of the search can fit in the 16K L1 Code
cache, so no code fecthes from L2 or memory are necessary.
However, with the data, you bring up an important point. The code is reused,
but some of the lookups are not. However, the penalty for this is relatively
small. For example, the bitboard lookups for the sliding pieces aren't in
the cache the first time they're fetched. But, each bitboard will be reused
several times during subsequent runs because most sliding piece lines will
be unchanged. The penalty is there, but not as big as it seems.
The Macks
hy...@crafty.cis.uab.edu wrote in message
<7omuek$7gu$1...@juniper.cis.uab.edu>...
[snip]
>You can only get so far on search speed. You can be tactically
devastating,
>but if there are no tactics, you _still_ have to play a move. And without
a
>decent eval, such a move can easily become a loser..
Yes, it becomes more difficult to play quiet positions with more speed and
less knowledge, but I'm hoping to find a high-speed balance by simplifying
positional concepts into concrete, quick lookups.
>
>: I guess what my model is telling me is that, with a streamlined Eval
(which
>: is what I intended to do) I can run at VERY high speeds.
>
>There have been several 'speed-only' programs over the years. They
>generally have not fared very well in games, although they might be
>murderous in test suites...
Generally, you're right that speed-only is too far off-balance.
One possible idea for a speed-only program though is to narrow opening
selection to sharper and less positional openings. Offbeat openings may
cause problems for such a program though.
>
>: However, it is theoretically known that the strength of a program is
related
>: to the product of knowledge and speed, so there's always the option of
>: slowing it down to make it smarter.
>
>: My intention was to follow the principle of Deep Blue's eval: reduce the
>: evaluation parameters to what really affects the position. Deep Blue I
think
>: had only Material, Position, King Safety, and pawn structure, which are
all
>: (relatively) simplified.
>
>This is _not_ what Deep Blue did. Instead, they designed special-purpose
>hardware to make their eval faster, without having to exclude anything they
>thought was necessary. In fact, they added significantly to their
evaluation
>over the years, but kept doing so by incorporating that into the hardware
so
>that the time-cost was zero.
>
>: A lot of times, when trying to come up with factors that make a position
>: good or bad, that people tend to overcomplicate things. Usually many
complex
>: ideas can be simplified into fewer, simpler ideas.
>
>Time will tell. I think you will find that you spend more time handling
>'exceptions' than you do handling 'normal cases' in chess. It is that sort
>of game...
Yes that is a significant problem with Chess. However, I think anyone will
find that, if all necessary concepts are correctly prioritized, that very
few exceptions remain.
>
>
>: Another optimization I thought of with this is approximation. Some very
>: tedious calculations can be quickly approximated, which is actually a
very
>: human-like trait.
>
>: Anyway, I'm curious... how fast is Crafty's Move Generator for an average
>: middlegame?
>
>On a PII/300, It can generate about 3.5M moves per second. However, this
is
>not a real good comparison, because in the chess tree, most of the moves
you
>need are captures, and there my move generator is very efficient because
with
>bitmaps, I don't have to loop over empty squares as pieces slide down
diagonals
>or files or ranks. I can generate captures _very_ efficiently, which is
>critical in the q-search.
Yes, in assembly language this is very fast too. Bit-scans on a bitboard can
easily scan up or down a diagonal, etc. (On a P-II a forward or reverse
bitscan takes only two micro-ops, which ends being about one clock cycle,
depending on the situation)
>
>Are you sure you are running this on a PC? It sounds like your performance
>test is broken and you are measuring processor-to-L2 cache speeds, while in
>the real program you are going to have to store the moves in _memory_. ANd
>there the PC is a bummer as it has very limited memory bandwidth.
Well, let me explain how my list works. The move list is actually not really
a list. First, there is a bitboard showing all valid moves for the king
whose source square is known elsewhere. Then there are bitboards for
different types of pawn moves, four in all. For minor and major pieces, the
source square is saved to a short list. In a second list, a bitboard of
destination squares is stored.
None of this has to be stored in memory, since all of it (maximum 184 bytes
but usually closer to 112) stays in the L1 cache because it is used
repeatedly.
During the search, the bitboards are scanned for the destination square, and
the move is made. For pawn moves, the source square is always a constant
offset of the destination square on the bitboard.
>
>: Some performance data so far for GetLegal(): (Approximate)
>
>: Overhead: 79 Hz (Includes King and Pawn move
calculation)
>: (Higher when castling or en passant is legal and slightly higher when the
>: king is in check)
>
>: Per Knight: 7-8 Hz
>: Per Bishop: 13 Hz
>
>How do you detect how far the bishop can slide, since 13 is the number of
>moves a bishop can make on an open board in the center? This leaves no
time
>for testing for empty squares, edge of the board, etc...
Just a few cached lookups to memory is all it takes.
Urban Koistinen
! In article <7ok9vh$s6b$1...@autumn.news.rcn.net>,
! The Macks <mm...@erols.com> wrote:
! >You might be interested in how fast my Legal Move Generator runs: in an
! >average middlegame, it takes 175 Hz to generate the move list.
! 175 Hz? .... tilt ... Sorry, don't understand.
! >That means it
! >runs at a speed of about 1,520,000 times per second
! To me, 175 Hz is 175 times / second.
! And as there's no obvious connection between 175 and 1520000 (175 Hz
! means each period is 5.7 ms), your information seems rather to
! contradict itself.
Having been into the fast move generator game myself,
I think I understand him.
He means 175 clock cycles to generate the legal moves of a position.
On a 266 MHz machine this makes the move generator run at 1.52 MHz
I did it on a 25 MHz 486 and got 10-15 kHz (I think) in the end.
(Inclusive of making one and updating attack tables etc)
Presently, I am into endgames and is getting amazing moves/second.
(sometimes more than 1 move/executed instruction)!
Anyway, moves/second is pretty meaningless unless you have context.
Urban Koistinen - m10...@abc.se
mainland china is worse
hy...@crafty.cis.uab.edu
: hy...@crafty.cis.uab.edu wrote in message
: <7omuek$7gu$1...@juniper.cis.uab.edu>...
: [snip]
:>You can only get so far on search speed. You can be tactically
: devastating,
:>but if there are no tactics, you _still_ have to play a move. And without
: a
:>decent eval, such a move can easily become a loser..
: Yes, it becomes more difficult to play quiet positions with more speed and
: less knowledge, but I'm hoping to find a high-speed balance by simplifying
: positional concepts into concrete, quick lookups.
:>
:>: I guess what my model is telling me is that, with a streamlined Eval
: (which
:>: is what I intended to do) I can run at VERY high speeds.
:>
:>There have been several 'speed-only' programs over the years. They
:>generally have not fared very well in games, although they might be
:>murderous in test suites...
: Generally, you're right that speed-only is too far off-balance.
: One possible idea for a speed-only program though is to narrow opening
: selection to sharper and less positional openings. Offbeat openings may
: cause problems for such a program though.
Yes.. and then there are endgames, because no matter how fast you are,
you aren't going to smash everyone in the middlegame. And if you don't
know a _lot_ about pawn structure and passed pawns, you will find every
endgame is lost by the time you get there...
:>
:>: However, it is theoretically known that the strength of a program is
: related
:>: to the product of knowledge and speed, so there's always the option of
:>: slowing it down to make it smarter.
:>
:>: My intention was to follow the principle of Deep Blue's eval: reduce the
:>: evaluation parameters to what really affects the position. Deep Blue I
: think
:>: had only Material, Position, King Safety, and pawn structure, which are
: all
:>: (relatively) simplified.
:>
:>This is _not_ what Deep Blue did. Instead, they designed special-purpose
:>hardware to make their eval faster, without having to exclude anything they
:>thought was necessary. In fact, they added significantly to their
: evaluation
:>over the years, but kept doing so by incorporating that into the hardware
: so
:>that the time-cost was zero.
:>
:>: A lot of times, when trying to come up with factors that make a position
:>: good or bad, that people tend to overcomplicate things. Usually many
: complex
:>: ideas can be simplified into fewer, simpler ideas.
:>
:>Time will tell. I think you will find that you spend more time handling
:>'exceptions' than you do handling 'normal cases' in chess. It is that sort
:>of game...
: Yes that is a significant problem with Chess. However, I think anyone will
: find that, if all necessary concepts are correctly prioritized, that very
: few exceptions remain.
Let me guess... you haven't played a whole lot of chess? :)
Just take one simple ending of any choice you want, and look at just
how many exceptions there are... IE Bishop _ Rook Pawn of the wrong
color. Always drawn? Nope. Ditto for knight vs bishop. Which is
better? Depends on the number of pawns, the color of the squares the
pawns are on, how frozen the pawns are, whether there are pawns on both
sides of the board, etc...
IE exception after exception to the 'general rule'. Even the "general
rules" include exceptions like en passant, castling, repetition, 50 moves,
insufficient material, etc...
:>
:>
:>: Another optimization I thought of with this is approximation. Some very
:>: tedious calculations can be quickly approximated, which is actually a
: very
:>: human-like trait.
:>
:>: Anyway, I'm curious... how fast is Crafty's Move Generator for an average
:>: middlegame?
:>
:>On a PII/300, It can generate about 3.5M moves per second. However, this
: is
:>not a real good comparison, because in the chess tree, most of the moves
: you
:>need are captures, and there my move generator is very efficient because
: with
:>bitmaps, I don't have to loop over empty squares as pieces slide down
: diagonals
:>or files or ranks. I can generate captures _very_ efficiently, which is
:>critical in the q-search.
: Yes, in assembly language this is very fast too. Bit-scans on a bitboard can
: easily scan up or down a diagonal, etc. (On a P-II a forward or reverse
: bitscan takes only two micro-ops, which ends being about one clock cycle,
: depending on the situation)
Actually it is a bit slower than that, but much better on the PII/PIII than
on older P5 processors which made this instruction unusable on them.
:>
:>Are you sure you are running this on a PC? It sounds like your performance
:>test is broken and you are measuring processor-to-L2 cache speeds, while in
:>the real program you are going to have to store the moves in _memory_. ANd
:>there the PC is a bummer as it has very limited memory bandwidth.
: Well, let me explain how my list works. The move list is actually not really
: a list. First, there is a bitboard showing all valid moves for the king
: whose source square is known elsewhere. Then there are bitboards for
: different types of pawn moves, four in all. For minor and major pieces, the
: source square is saved to a short list. In a second list, a bitboard of
: destination squares is stored.
: None of this has to be stored in memory, since all of it (maximum 184 bytes
: but usually closer to 112) stays in the L1 cache because it is used
: repeatedly.
: During the search, the bitboards are scanned for the destination square, and
: the move is made. For pawn moves, the source square is always a constant
: offset of the destination square on the bitboard.
What about moving down diagonals? Etc. Or do you compute the correct
attacks up front so that your move generator just does a 'run and dump'
type operation? If so, then you have to factor in the update time when
you actually make a move...
:>
:>: Some performance data so far for GetLegal(): (Approximate)
:>
:>: Overhead: 79 Hz (Includes King and Pawn move
: calculation)
:>: (Higher when castling or en passant is legal and slightly higher when the
:>: king is in check)
:>
:>: Per Knight: 7-8 Hz
:>: Per Bishop: 13 Hz
:>
:>How do you detect how far the bishop can slide, since 13 is the number of
:>moves a bishop can make on an open board in the center? This leaves no
: time
:>for testing for empty squares, edge of the board, etc...
: Just a few cached lookups to memory is all it takes.
I am using bitmaps, but find that 'just a few' are scattered around in
memory enough to have no chance of surviving in L1 when the search and
evaluation and make/unmake and so forth also get accessed once per node.
16kb (or 32kb on a PII) isn't big, and if you are using some sort of bitmap
driven code (which it sounds like) the things required to update those to
keep them current are also non-trivial.
But good luck. Be interesting to see where you end up speed-wise when the
thing actually plays a complete game of chess from front-to-back...
The Macks
hy...@crafty.cis.uab.edu wrote in message
<7onden$df9$1...@juniper.cis.uab.edu>...
>
>Yes.. and then there are endgames, because no matter how fast you are,
>you aren't going to smash everyone in the middlegame. And if you don't
>know a _lot_ about pawn structure and passed pawns, you will find every
>endgame is lost by the time you get there...
Yes, that is a concern. Fortunately, due to the existence of pawn
structure hash tables, lots of information about pawn structure can be saved
and retrieved from memory. Unfortunately, this information can't be cached
consistently, although pawn structure tends to stay consistent enough to
remain in the cache some of the time.
[snip]
>
>: Yes that is a significant problem with Chess. However, I think anyone
will
>: find that, if all necessary concepts are correctly prioritized, that very
>: few exceptions remain.
>
>Let me guess... you haven't played a whole lot of chess? :)
Actually, I've played quite a lot, and I've found that most "exceptions" are
really misunderstood.
>
>Just take one simple ending of any choice you want, and look at just
>how many exceptions there are... IE Bishop _ Rook Pawn of the wrong
>color. Always drawn? Nope. Ditto for knight vs bishop. Which is
>better? Depends on the number of pawns, the color of the squares the
>pawns are on, how frozen the pawns are, whether there are pawns on both
>sides of the board, etc...
Well, yes, in endings it is more difficult to distinguish between a superior
piece and an inferior one. Thankfully, some of those categories can fall
under pawn structure, but let me try to make some concrete ideas out of the
classic B vs. N:
-The most important factor is knight placement. Unless somehow the
bishop is imprisoned or stuck, then it can take up a post anywhere. If the
knight has a good support point and attacks a pawn or two, it is strong. If
not, it is usually weaker.
-Passed pawns tend to favor the bishop unless easily blockaded. Pawns
far apart from each other, and enemy pawns on the same color of the bishop
favor the B.
Not that these general rules, among others, are simple to implement at high
speed, but lookup tables will cover most of them.
>
>IE exception after exception to the 'general rule'. Even the "general
>rules" include exceptions like en passant, castling, repetition, 50 moves,
>insufficient material, etc...
Unfortunately, the rules to chess are not computer-friendly (compare it to
checkers)
I'm not exactly sure what you mean. I have precompiled bitboard attacks
that are ORed together. For a bishop, for example, the list saves the
location of it as the source, and the attack bitboard as the destination.
Bitscans of this board are used to locate destination squares just as
quickly along diagonals as on ranks and files.
>
>: Just a few cached lookups to memory is all it takes.
>
>I am using bitmaps, but find that 'just a few' are scattered around in
>memory enough to have no chance of surviving in L1 when the search and
>evaluation and make/unmake and so forth also get accessed once per node.
>16kb (or 32kb on a PII) isn't big, and if you are using some sort of bitmap
>driven code (which it sounds like) the things required to update those to
>keep them current are also non-trivial.
(Actually, on a P-II, the L1 has one 16K code cache and one 16K data cache)
Yes, I am using bitmap-driven code.
Yes, it is impossible to predict whether each data item will still be in the
L1 (or L2) but statistically only a small part of any position is affected
after each move, so some of the lookups are affected (and no new lookup is
going to be in the L1) but a good percentage of the lookups are identical.
>
>But good luck. Be interesting to see where you end up speed-wise when the
>thing actually plays a complete game of chess from front-to-back...
Yes, I hope so... unfortunately, I won't have a lot of free time during the
school year, so things will progress very slowly.
Ryan Mack
Dale Eckert
knows DOC Hyatt is the SELF PROCLAIMED be all and know all of computer
chess. Don't let him get you down though....go for it!
The Macks <mm...@erols.com> wrote in message
news:7onlfp$rqo$1...@autumn.news.rcn.net...
John DeMastri
I've been following this thread pretty closely, and I thought Dr Hyatt's
comments were on point and very supportive, to Ryan and others struggling
with these type of trade-off questions.
What's the matter? Did you lose to Crafty today on one of the servers?
John
Dale Eckert <dwe...@ibm.net> wrote in message
news:37af...@news1.us.ibm.net...
The Macks
matter how fast it is! Granted, the other parts of the program have to be
fast too, but if the move generator is slow, it becomes a huge performance
bottleneck.
Writing a good and fast eval is almost a paradox, but yes, it is also
difficult. It does take forever to hand-tune the values to the strongest
ones, but by no means is the eval the only link in the chain....
Tord Kallqvist Romstad wrote in message ...
>In article <7omprj$hj4$1...@autumn.news.rcn.net>, The Macks wrote:
>
>>Anyway, I'm curious... how fast is Crafty's Move Generator for an average
>>middlegame?
>
>You can find out this yourself by entering the "perf" command in
>Crafty. Anyway, as others have pointed out, the move generator is rarely
>a critical part of the code. Writing a fast move generator is relatively
>easy, writing a fast and good eval is very difficult. My move generator
>is probably much slower than yours (I am not sure how many moves I generate
>per second), but I do not spend much time optimising it. Less than 5% of
>the CPU time is spent in the move generator anyway.
>
>Tord
The Macks
I looked at my mathematical model again, and increased the Eval time until
the nodes per second estimate matched Crafty's. (I also set the Pawn
Structure Hash Table Hit Rate to zero)
What I found was that I could beef up my Eval to 2,500 Hz (about 9.4
microseconds) and run at the same NPS as Crafty.
If I add in the Pawn Structure Hash Table and set the hit rate at 95% (is
this an accurate figure? Seems to me it might be even higher)
Some data pairs that will run at the same NPS as Crafty:
Hash Hit Hz Hash Miss Hz
50 50,000
100 47,500
200 46,000
400 42,500
800 34,500
1,600 19,500
2,400 4,000
2,500 2,500
et cetera. The point is that I have a lot of breathing room to add to my
Eval and I'll still be way faster then Crafty...
hy...@crafty.cis.uab.edu
: Well, actually, writing a fast move generator is *not* easy, and it does
: matter how fast it is! Granted, the other parts of the program have to be
: fast too, but if the move generator is slow, it becomes a huge performance
: bottleneck.
Remember the good old 90-10 rule. If you spend 90% of your time in a piece
of code, that is the place to spend time optimizing. In my program, movgen
is under 10%, which means that even if it produced moves in zero time, the
code would be less than 10% faster, overall.
wearing out optimizing on a piece of code that represents under 10% of the
total search effort isn't going to pay for itself...
: Writing a good and fast eval is almost a paradox, but yes, it is also
: difficult. It does take forever to hand-tune the values to the strongest
: ones, but by no means is the eval the only link in the chain....
No, but it is the _biggest_.
Optimizing the biggest time-user is where the payoff is... That is why
I use bitmaps. They are _not_ the fastest way to generate moves. But they
do offer a lot in evaluation pattern-matching that offsets the slower move
generation speed.
hy...@crafty.cis.uab.edu
: I have an interesting update with regards to my program:
: I looked at my mathematical model again, and increased the Eval time until
: the nodes per second estimate matched Crafty's. (I also set the Pawn
: Structure Hash Table Hit Rate to zero)
Are you factoring in hashing which will result in one or more cache
misses every time you try? The move ordering ideas like history have a
large data structure that won't stick in cache either...
: What I found was that I could beef up my Eval to 2,500 Hz (about 9.4
: microseconds) and run at the same NPS as Crafty.
2500 instructions is a very tiny evaluation by anybody's standards. Table
lookup's won't cut it, because you need 'interaction' between eval terms.
: If I add in the Pawn Structure Hash Table and set the hit rate at 95% (is
: this an accurate figure? Seems to me it might be even higher)
: Some data pairs that will run at the same NPS as Crafty:
: Hash Hit Hz Hash Miss Hz
: 50 50,000
: 100 47,500
: 200 46,000
: 400 42,500
: 800 34,500
: 1,600 19,500
: 2,400 4,000
: 2,500 2,500
: et cetera. The point is that I have a lot of breathing room to add to my
: Eval and I'll still be way faster then Crafty...
We're all waiting. :)
The Macks
hy...@crafty.cis.uab.edu wrote in message
<7ophou$6k9$1...@juniper.cis.uab.edu>...
>The Macks <mm...@erols.com> wrote:
>: Well, actually, writing a fast move generator is *not* easy, and it does
>: matter how fast it is! Granted, the other parts of the program have to be
>: fast too, but if the move generator is slow, it becomes a huge
performance
>: bottleneck.
>
>Remember the good old 90-10 rule. If you spend 90% of your time in a piece
>of code, that is the place to spend time optimizing. In my program, movgen
>is under 10%, which means that even if it produced moves in zero time, the
>code would be less than 10% faster, overall.
>
>wearing out optimizing on a piece of code that represents under 10% of the
>total search effort isn't going to pay for itself...
Yes you make a good point. One of the more practical reasons I'm spending so
much time optimizing the move generator is that I'm using assembly language
for the program core. The optimization doesn't have to be final, but the way
the function cooperates with the rest of the parts does. If I suddenly
decide to revamp the move generator later into a different format, I have to
revamp most of the other parts too. In assembly, I find it better to
optimize it as much as possible before even starting the next part.
>
>
>: Writing a good and fast eval is almost a paradox, but yes, it is also
>: difficult. It does take forever to hand-tune the values to the strongest
>: ones, but by no means is the eval the only link in the chain....
>
>No, but it is the _biggest_.
>
>Optimizing the biggest time-user is where the payoff is... That is why
>I use bitmaps. They are _not_ the fastest way to generate moves. But they
>do offer a lot in evaluation pattern-matching that offsets the slower move
>generation speed.
You are correct that optimizing the slowest link in the chain provides the
biggest overall percentage gain in speed, but again, I'm trying to finalize
the movgen algorithms so they won't have to be revamped often. Optimizing
any part of a chess program increases the speed, while also making the
subsequent optimization of other parts even more attractive.
The Macks
hy...@crafty.cis.uab.edu wrote in message
<7ophu5$6k9$2...@juniper.cis.uab.edu>...
>The Macks <mm...@erols.com> wrote:
>: I have an interesting update with regards to my program:
>
>: I looked at my mathematical model again, and increased the Eval time
until
>: the nodes per second estimate matched Crafty's. (I also set the Pawn
>: Structure Hash Table Hit Rate to zero)
>
>Are you factoring in hashing which will result in one or more cache
>misses every time you try? The move ordering ideas like history have a
>large data structure that won't stick in cache either...
Well, I'm not really looking at specific parts of the Eval, just the amount
of clock cycles that it takes to run on average.
>
>: What I found was that I could beef up my Eval to 2,500 Hz (about 9.4
>: microseconds) and run at the same NPS as Crafty.
>
>2500 instructions is a very tiny evaluation by anybody's standards. Table
>lookup's won't cut it, because you need 'interaction' between eval terms.
Actually it's 2,500 clock cycles, which can accomodate 3000-3500+
instructions if well-optimized. In assembly, 3000 instructions is a LOT.
Many terms can be combined into single lookups if they're prioritized
properly.
>
>: If I add in the Pawn Structure Hash Table and set the hit rate at 95% (is
>: this an accurate figure? Seems to me it might be even higher)
>
>: Some data pairs that will run at the same NPS as Crafty:
>
>: Hash Hit Hz Hash Miss Hz
>
>: 50 50,000
>: 100 47,500
>: 200 46,000
>: 400 42,500
>: 800 34,500
>: 1,600 19,500
>: 2,400 4,000
>: 2,500 2,500
>
>: et cetera. The point is that I have a lot of breathing room to add to my
>: Eval and I'll still be way faster then Crafty...
>
>
>We're all waiting. :)
>
hy...@crafty.cis.uab.edu
: hy...@crafty.cis.uab.edu wrote in message
: <7ophou$6k9$1...@juniper.cis.uab.edu>...
:>The Macks <mm...@erols.com> wrote:
:>: Well, actually, writing a fast move generator is *not* easy, and it does
:>: matter how fast it is! Granted, the other parts of the program have to be
:>: fast too, but if the move generator is slow, it becomes a huge
: performance
:>: bottleneck.
:>
:>Remember the good old 90-10 rule. If you spend 90% of your time in a piece
:>of code, that is the place to spend time optimizing. In my program, movgen
:>is under 10%, which means that even if it produced moves in zero time, the
:>code would be less than 10% faster, overall.
:>
:>wearing out optimizing on a piece of code that represents under 10% of the
:>total search effort isn't going to pay for itself...
: Yes you make a good point. One of the more practical reasons I'm spending so
: much time optimizing the move generator is that I'm using assembly language
: for the program core. The optimization doesn't have to be final, but the way
: the function cooperates with the rest of the parts does. If I suddenly
: decide to revamp the move generator later into a different format, I have to
: revamp most of the other parts too. In assembly, I find it better to
: optimize it as much as possible before even starting the next part.
Here is the danger you face: As you develop more of the program, you
are going to discover more 'things' that you would like MakeMove() and
perhaps your move generator to know about. Which means when you start
there, you get to rewrite over and over as you find out things you need
that are more efficient to compute incrementally as you step thru the
tree.
IE you are doing exactly what I did in Crafty. I started at the bottom
(move generation), and then rewrote that stuff several times as I added
and deleted things. I did this because I wanted a good idea of whether
the bitmap approach was even worthwhile, and the first thing you need to
test this is move generation.
But if you read the comments in crafty, you'll see that this evolved over
a long period of time...
I was simply pointing out that you are starting on a piece that (a) is not
critical to how you play chess; (b) is a small fraction of the total
program; and (c) will likely change more than once as you add other pieces
and find missing information you need to compute where you are now...
:>
:>
:>: Writing a good and fast eval is almost a paradox, but yes, it is also
:>: difficult. It does take forever to hand-tune the values to the strongest
:>: ones, but by no means is the eval the only link in the chain....
:>
:>No, but it is the _biggest_.
:>
:>Optimizing the biggest time-user is where the payoff is... That is why
:>I use bitmaps. They are _not_ the fastest way to generate moves. But they
:>do offer a lot in evaluation pattern-matching that offsets the slower move
:>generation speed.
: You are correct that optimizing the slowest link in the chain provides the
: biggest overall percentage gain in speed, but again, I'm trying to finalize
: the movgen algorithms so they won't have to be revamped often. Optimizing
: any part of a chess program increases the speed, while also making the
: subsequent optimization of other parts even more attractive.
Suppose you discover that the 'order' you produce moves in can be improved,
after you get the search up and going? IE it is likely that you will change
your move generator many times _after_ you get it 'completed'... I would not
spend a lot of time on something that might be very volatile...
john quill taylor
>The Macks <mm...@erols.com> wrote:
>: ...
>: et cetera. The point is that I have a lot of breathing room
>: to add to my Eval and I'll still be way faster then Crafty...
>We're all waiting. :)
This is a great discussion.
Under the guise of "my engine is better than your engine" two
programmers debate intricacies of the chess playing algorithm!
It doesn't get any better than this.
- jqt -
The Macks
hy...@crafty.cis.uab.edu wrote in message
<7opud1$be4$1...@juniper.cis.uab.edu>...
Yes, I will be surprised if I don't add or remove something from the move
generator as my program progresses, but I am positive the algorithms and the
data structs the moves are saved in are final, simply because the
performance gain of the current move format I have achieved is tremendous.
As long as I can comprehend my code a few months down the road, I won't have
to rewrite everything. I can simply add or remove what needs to be changed.
>
>IE you are doing exactly what I did in Crafty. I started at the bottom
>(move generation), and then rewrote that stuff several times as I added
>and deleted things. I did this because I wanted a good idea of whether
>the bitmap approach was even worthwhile, and the first thing you need to
>test this is move generation.
>
>But if you read the comments in crafty, you'll see that this evolved over
>a long period of time...
>
>I was simply pointing out that you are starting on a piece that (a) is not
>critical to how you play chess; (b) is a small fraction of the total
>program; and (c) will likely change more than once as you add other pieces
>and find missing information you need to compute where you are now...
Well you are correct, but it is critical in assembly that I finalize the
data structures (and optimize how they are used) before I start building the
proverbial pyramid of dependent parts on top of the move generator. If I
ever have to change the data structures, almost everything in the whole
program has to be rewritten.
>
>: You are correct that optimizing the slowest link in the chain provides
the
>: biggest overall percentage gain in speed, but again, I'm trying to
finalize
>: the movgen algorithms so they won't have to be revamped often. Optimizing
>: any part of a chess program increases the speed, while also making the
>: subsequent optimization of other parts even more attractive.
>
>Suppose you discover that the 'order' you produce moves in can be improved,
>after you get the search up and going? IE it is likely that you will
change
>your move generator many times _after_ you get it 'completed'... I would
not
>spend a lot of time on something that might be very volatile...
That is a consideration, and I have allowed for that completely. My move
list is set up so that I can save the moves in any order I want without
disturbing the other parts of the program. I only have to edit the move
generator code itself. Again, I only have to make sure the move format and
the subsequent dependencies won't change in the future.
Ryan Mack
Dan Schmidt
| I apologize if I've been a bit unclear. My processor runs at 266
| MHz, or 266 million cycles per second. To generate the move list for
| an average position, it takes 175 Hz, or 175 cycles.
You don't mean 175 Hz. 175 Hz means 175 times per second.
--
Dan Schmidt -> df...@harmonixmusic.com, df...@alum.mit.edu
Honest Bob & the http://www2.thecia.net/users/dfan/
Factory-to-Dealer Incentives -> http://www2.thecia.net/users/dfan/hbob/
Gamelan Galak Tika -> http://web.mit.edu/galak-tika/www/
russ garratt
The Macks wrote in message <7ok9vh$s6b$1...@autumn.news.rcn.net>...
[snipped]
when I decided to cache movegen results in The Swindler, and got about 50%
cache hits during most iterative middlegame search, I was much encouraged.
But before claiming this as a major breakthrough I compared my results
against other programs (such as Crafty which I use as a benchmark reality
test).
I reworte my movelists back to cache after sorting them, so each iteration
the move ordering got better. The cache (when it hit) saved so much work ...
But the overall program performance was not so dramatically improved as I
expected because the memory used for the cache turned out to be better
employed as a transo#position cache.
Back to square E1 ;-)
Goodwill from Russ64 and The Swindler (which still doesn't get a positive
score against crafty on the same cpu)
John Grabowski
so much?
John
--
No one ever got to be a corporate manager by having a big heart.
-Anonymous
Tim Mann
just "cycles". So if your routine takes 100 machine cycles to run, it
is both wrong and confusing to say that it takes "100 Hz".
--Tim
The Macks
machine cycles as a quick abbreviation, and I'v been using that out of
habit.
Tim Mann wrote in message <7p1s8b$dle$1...@milwaukee.pa.dec.com>...
Urban Koistinen
The Macks skrev i meddelandet <7p278s$iun$1...@autumn.news.rcn.net>...
Would 100 Hzs be right and confusing?
What is the best word to use?
Cycles?
Urban Koistinen
mainland china is worse
The Macks
it's a lot to write out
rmod...@my-deja.com
better, I'd say that you're just some punk kid
trying to waste a lot of people's time. I bet you
just read about computer chess programming and are
acting like you are making a program to amuse
yourself and laugh when you waste important
people's time like that crafty guy. Let him make
his program rather then annoy him with trivial hz
and nps problems! For Shame. You should play his
computer. I'm sure it could beat you. I've never
played a computer before, but i hear they are
good. Like theres this one compter called deep
blue, its awesome! I think it runs on a fast
computer like a pentium 750 or something (I'm sure
they can afford it) It beat the best person in the
world! I mean jesus, it must be good! Therefore, i
conclude that the crafty guy is a God and you are
nothing but the dirt he walks in! Why must you
waste people's time by making up stories about
"magical" imaginary chess computers that can beat
anybody in the world! I mean, what were you
thinking!?!?
-RM
ps. cya at school ryan. Did you hear that school
doesn't start until thursday! thats awesome! It
was supposed to be tuesday but it rained so they
had to postpone school. See you in math. Sit in
your usual seat and gs and i can sit in back of
you and throw stuff at you and make fun of you and
i can cheat off you and gs during tests like
usual. Too bad you didnt get into your other
classes that you wanted to. Chem and Phyc and
compsci just won't be the same!
In article <37B35939...@earthlink.net>,
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.