New Methods On Old Hardware?

[Uri Blass]

Very fast time controls does not quite relate to old hardware. Hardware speeds have been pretty static for several years now. In 1994, running on a sun sparc that was far faster than any PC being made, Crafty was hitting around 5K nodes per second. Back then I found that even null-move R=2 was too dangerous (you can find comments in main.c about some of this.) As speeds improved, and along with that, depth, some things started working better.

1)I suspect that null move was too dangerous because of other factors(not having checks in the qsearch)

I would like to know if you can find time control that you practically do not use when null move is counter productive today.

2)5 knodes per second seems to be slow relative to 1994 because I remember that commercial programs got more than it.

If I remember correctly Fritz3 got 100 knodes per second at the time that it beat Deep blue prototype in the championship of 1994 and when I believe that Fritz searched faster than Crafty
I do not believe that Crafty was more than 20 times slower than Fritz3

Uri

[bob]

Very fast time controls does not quite relate to old hardware. Hardware speeds have been pretty static for several years now. In 1994, running on a sun sparc that was far faster than any PC being made, Crafty was hitting around 5K nodes per second. Back then I found that even null-move R=2 was too dangerous (you can find comments in main.c about some of this.) As speeds improved, and along with that, depth, some things started working better.

1)I suspect that null move was too dangerous because of other factors(not having checks in the qsearch)

Not for me. If you look at the comments in main.c, we had a couple of layers of checks in the q-search, an idea taken from Cray Blitz.

I would like to know if you can find time control that you practically do not use when null move is counter productive today.

I don't test at microseconds/move because the timing is so jittery it introduces a ton of variance that is painful to deal with. Given a particular NPS target, I could probably rig up something to slow Crafty down to that speed, I suppose.

2)5 knodes per second seems to be slow relative to 1994 because I remember that commercial programs got more than it.

This is pre-pentium pro. By the time we had the pentium/133 Crafty hit around 35K nodes per second, Pentium/133 was a 1995 release if I recall correctly.

If I remember correctly Fritz3 got 100 knodes per second at the time that it beat Deep blue prototype in the championship of 1994 and when I believe that Fritz searched faster than Crafty
I do not believe that Crafty was more than 20 times slower than Fritz3

Uri

I won't say Frans was not going that fast, since fritz was asm at the time, but that was certainly prior to the P5/133 which was 35K for Crafty. Crafty hit roughly 70K when the P6/200 (pentium-pro, first OOE processor from Intel).

[Uri Blass]

Very fast time controls does not quite relate to old hardware. Hardware speeds have been pretty static for several years now. In 1994, running on a sun sparc that was far faster than any PC being made, Crafty was hitting around 5K nodes per second. Back then I found that even null-move R=2 was too dangerous (you can find comments in main.c about some of this.) As speeds improved, and along with that, depth, some things started working better.

1)I suspect that null move was too dangerous because of other factors(not having checks in the qsearch)

Not for me. If you look at the comments in main.c, we had a couple of layers of checks in the q-search, an idea taken from Cray Blitz.

I would like to know if you can find time control that you practically do not use when null move is counter productive today.

I don't test at microseconds/move because the timing is so jittery it introduces a ton of variance that is painful to deal with. Given a particular NPS target, I could probably rig up something to slow Crafty down to that speed, I suppose.

2)5 knodes per second seems to be slow relative to 1994 because I remember that commercial programs got more than it.

This is pre-pentium pro. By the time we had the pentium/133 Crafty hit around 35K nodes per second, Pentium/133 was a 1995 release if I recall correctly.

If I remember correctly Fritz3 got 100 knodes per second at the time that it beat Deep blue prototype in the championship of 1994 and when I believe that Fritz searched faster than Crafty
I do not believe that Crafty was more than 20 times slower than Fritz3

Uri

I won't say Frans was not going that fast, since fritz was asm at the time, but that was certainly prior to the P5/133 which was 35K for Crafty. Crafty hit roughly 70K when the P6/200 (pentium-pro, first OOE processor from Intel).

yes 1994 was prior to P5/133 and Fritz used P90 based on my memory.
My point still holds and Crafty could search more than 5 knodes per second pn P90(P133 is less than 7 times faster than P90)

It means that something in the following words by you is not correct:

"In 1994, running on a sun sparc that was far faster than any PC being made, Crafty was hitting around 5K nodes per second."

Note that even at 5K nodes per second you may practically get million nodes per move in computer world championship(considering the fact that you have some minutes per move including pondering) so if null move pruning is productive today at one million nodes per move then it certainly could be productive at the time that you searched 5K nodes in tournaments.

[bob]

Very fast time controls does not quite relate to old hardware. Hardware speeds have been pretty static for several years now. In 1994, running on a sun sparc that was far faster than any PC being made, Crafty was hitting around 5K nodes per second. Back then I found that even null-move R=2 was too dangerous (you can find comments in main.c about some of this.) As speeds improved, and along with that, depth, some things started working better.

1)I suspect that null move was too dangerous because of other factors(not having checks in the qsearch)

Not for me. If you look at the comments in main.c, we had a couple of layers of checks in the q-search, an idea taken from Cray Blitz.

I would like to know if you can find time control that you practically do not use when null move is counter productive today.

I don't test at microseconds/move because the timing is so jittery it introduces a ton of variance that is painful to deal with. Given a particular NPS target, I could probably rig up something to slow Crafty down to that speed, I suppose.

2)5 knodes per second seems to be slow relative to 1994 because I remember that commercial programs got more than it.

This is pre-pentium pro. By the time we had the pentium/133 Crafty hit around 35K nodes per second, Pentium/133 was a 1995 release if I recall correctly.

If I remember correctly Fritz3 got 100 knodes per second at the time that it beat Deep blue prototype in the championship of 1994 and when I believe that Fritz searched faster than Crafty
I do not believe that Crafty was more than 20 times slower than Fritz3

Uri

I won't say Frans was not going that fast, since fritz was asm at the time, but that was certainly prior to the P5/133 which was 35K for Crafty. Crafty hit roughly 70K when the P6/200 (pentium-pro, first OOE processor from Intel).

yes 1994 was prior to P5/133 and Fritz used P90 based on my memory.
My point still holds and Crafty could search more than 5 knodes per second pn P90(P133 is less than 7 times faster than P90)

I can only tell you that on a P5/133 we eventually reached 35K. I didn't run on a P5/90. Note that I said 5K on a _SPARC_ which was faster than whatever Intel had at that moment.

It means that something in the following words by you is not correct:

"In 1994, running on a sun sparc that was far faster than any PC being made, Crafty was hitting around 5K nodes per second."

Note that even at 5K nodes per second you may practically get million nodes per move in computer world championship(considering the fact that you have some minutes per move including pondering) so if null move pruning is productive today at one million nodes per move then it certainly could be productive at the time that you searched 5K nodes in tournaments.[/quote]

My basis for discontinuing R=2 in 1994 was playing lots of games on ICC. And looking at the GM games we were losing. Many were classic null-move failures that missed a mate threat that was obvious. Lopping off 2 plies rather than one back then was a problem when we were hitting 6-7-8 plies max.

I no longer have those very old versions so I can't determine when version 5.x was current and R=2 was failing, but it was very early. By version 7 and the P6/200, R=2 was ok but only when done adaptively and reduced to 1 near the tips. Today I use R=2 everywhere. In 1994 branching factor for Crafty was at least 10, similar to other programs. Going 10x longer gave 1 ply more, so the difference was not as great. Today's branching factor is well below 2 most of the time and the depths are enormous, which changes things a lot.

I'll try to see what the oldest version I have is. I think I have a single 9.x somewhere. I could add some dummy code to the old and current to drop the nps back to 10K or so and see how they play. Then play them at normal speed to see what the difference is. My suspicion is that both at 10K will be a much closer because the current version will be hurt more, while at 4-5M, the current version will blow 9.x out. I'll work on this and report back...

[mhull]

I guess my real question is: If someone wanted to build a custom chess playing machine (table or table-top) and wanted the strength to be no greater than master or senior master level, what would be the target hardware? It would be something cheap and off-the-shelf but effective for the purpose.

I'd probably go for an atom today. Low enough power requirements, still fast. Certainly the price is right.

In light of the "power to weight ratio" illustrated in your Cray/Vax comparison, do you think there is a MHz cutoff in x86 or Atom architecture that would similarly favor earlier versions of crafty at slower speeds?

[mhull]

I guess my real question is: If someone wanted to build a custom chess playing machine (table or table-top) and wanted the strength to be no greater than master or senior master level, what would be the target hardware? It would be something cheap and off-the-shelf but effective for the purpose.

I'd probably go for an atom today. Low enough power requirements, still fast. Certainly the price is right.

Upon reflection it's probably better to ask if there might be decreased NPS "threshold" where a more primitive version of crafty would produce better play at the same time control.

[bob]

I guess my real question is: If someone wanted to build a custom chess playing machine (table or table-top) and wanted the strength to be no greater than master or senior master level, what would be the target hardware? It would be something cheap and off-the-shelf but effective for the purpose.

I'd probably go for an atom today. Low enough power requirements, still fast. Certainly the price is right.

In light of the "power to weight ratio" illustrated in your Cray/Vax comparison, do you think there is a MHz cutoff in x86 or Atom architecture that would similarly favor earlier versions of crafty at slower speeds?

It depends on where you go. I worked on a Nintendo DS project a while back. That's a really puny processor by today's standards. I ended up removing a lot of normal stuff that was problematic. Memory is limited. bandwidth is limited. processor speed is limited. I think most current "real processors" (atom, and X86-compatibles) would be ok for today's version. If you go back to the 100-200mhz days, it would probably still play OK but could be tweaked quite a bit I would expect, to improve things.

[bob]

I guess my real question is: If someone wanted to build a custom chess playing machine (table or table-top) and wanted the strength to be no greater than master or senior master level, what would be the target hardware? It would be something cheap and off-the-shelf but effective for the purpose.

I'd probably go for an atom today. Low enough power requirements, still fast. Certainly the price is right.

Upon reflection it's probably better to ask if there might be decreased NPS "threshold" where a more primitive version of crafty would produce better play at the same time control.

Unfortunately this is not a test I have run, so I am not certain about any part of it. The old Cray Blitz issue was quite apparent. But I have not tried current code on a very old processor. I might have a 700mhz laptop laying around I could try, for fun...

[mhull]

I guess my real question is: If someone wanted to build a custom chess playing machine (table or table-top) and wanted the strength to be no greater than master or senior master level, what would be the target hardware? It would be something cheap and off-the-shelf but effective for the purpose.

I'd probably go for an atom today. Low enough power requirements, still fast. Certainly the price is right.

Upon reflection it's probably better to ask if there might be decreased NPS "threshold" where a more primitive version of crafty would produce better play at the same time control.

Unfortunately this is not a test I have run, so I am not certain about any part of it. The old Cray Blitz issue was quite apparent. But I have not tried current code on a very old processor. I might have a 700mhz laptop laying around I could try, for fun...

Since the end result is a reduction in NPS, perhaps low NPS could be artificially induced on two versions of crafty, one rather old and the other most recent. This would require modifying both versions at a similar point in code to do a whole lot of nothing based on a parameter passed at program load, resulting in the effect of running on old hardware. Then they could be cluster tested to get an accurate reading.

Of course, it might not be worth the bother unless one were serious about which version of crafty was best for a much slower target platform.