Author: Robert Hyatt
Date: 11:31:50 03/11/04
Go up one level in this thread
On March 11, 2004 at 13:05:35, Eugene Nalimov wrote: >On March 11, 2004 at 12:56:01, Robert Hyatt wrote: > >>On March 11, 2004 at 05:56:40, Uri Blass wrote: >> >>>On March 11, 2004 at 05:21:03, Fabien Letouzey wrote: >>> >>>> >>>>On March 10, 2004 at 22:39:48, Djordje Vidanovic wrote: >>>> >>>>>Fruit is a very nice new program that can be freely downloaded from Dann >>>>>Corbit's ftp site. It is a UCI engine and can run either under Arena or the CB >>>>>GUI. I tried it in a very short match (played at quick blitz controls) against >>>>>one of the older Crafties (18.12) and it did not have much of a real chance to >>>>>score. It does seem to be very promising though as it had a couple of playable >>>>>and perhaps winnable positions, but due to the apparent lack of knowledge it >>>>>lost even these games. I think that game 4 could be very telling for the >>>>>programmer who said that he was a little disappointed with CCC. Ahem, he should >>>>>know that all things that matter in life usually take time, and CCC is just like >>>>>that especially at the beginning. He will surely be overwhelmed eventually with >>>>>the amount of feedback by CCC members. >>>> >>>>Fruit is of course not in the same league as Crafty. >>>> >>>>The lack of knowledge is real, not apparent :))) >>> >>>The lack of knowledge in crafty is also real. >>>Crafty does not know things like ETC. >> >>ETC is _not_ "knowledge". It is a modification to move ordering only. If you >>look at comments in main.c, I tried ETC more than once. I reported here >>that it was worse for Crafty, as it is a speed slow-down, and the goal >>is for the speed cost to be offset by less work due to a quicker hash >>cutoff. It was _slower_ for me, so the fact it is not in is not an >>oversight, it is a design choice. >> >>It might work fine for you, but it was worse for me and I got rid of it... > >You can try it only if depth remaining is large enough. This way you will not >see significant slowdown, but probably will get better move ordering near the >root. I tried that. And it didn't help. The speed loss dropped, but so did the effectiveness of the idea. Several reported good results in checkers. I've not seen anyone really "glow" about ETC in chess, however... > >Of course to see real benefits you'll need larger hash. Something like 64Gb... >(and no, I had not run new Crafty version to verify that the problem in hash >allocation was fixed). > >Thanks, >Eugene I think bigger hash reduces the effectiveness of this. IE what is the probability that at ply=n I get a hash miss, while at ply+1 I get a hit that causes a cutoff? This would be more likely with smaller table sizes, where ply=n gets overwritten bit N+1 doesn't. Bigger hash tables mean fewer overwrites, so the ply=n probe should hit if ply=n+1 will also hit... It might also do worse for me since I don't store q-search, and as a result, I won't overwrite things as badly as someone that does... > >>> >>>>I am well aware of it, and no I don't intend to leave it that way forever. >>>> >>>>About CCC sure, time will tell. I am a bit stressed because of the imminent >>>>release so I was not too happy not to find mcuh help when I needed it. Next >>>>week after version 1.0 is out, things will be more quiet. >>>> >>>>>Anyway, I used the CB GUI as the "arena" (pun intended) (wishing to find out if >>>>>Fruit would run there; it did, splendidly so). Both programs used Powerbook >>>>>2003 as the opening database; hash was set at 64MB, the machine an AMD Athlon >>>>>2800+ (Tbred, 2250Mhz). Krafty is still a very tough nut to crack (too much >>>>>speed and too much knowledge in Krafty; Crafty was hitting about 1.2-1.4 >>>>>million nps in the middle game while Fruit reached ca. 750-800,000nps. The >>>>>higher nps you can see in the game scores for Fruit are due to tablebase access >>>>>slowdown for Crafty; Fruit still has no tablebase access). The first four games >>>>>should be enough to get an idea about the strengths and weaknesses of the >>>>>newcomer, the match was a bit longer, but I won't bother you with all the >>>>>details. >>>> >>>>Yes Fruit is not only stupid, but slow as well. It takes a lot of time to >>>>compute very little. With the eval features as they are, it should be twice as >>>>fast. I don't optimise that because I intend to change the eval a lot anyway >>>>(but not for version 1.0). >>> >>>I do not think that it is slow and it is simply crafty that is fast. >>>There are a lot of programs that search significantly less nodes per second. >>> >>>> >>>>Also Fruit is designed for longer time controls; maybe it gets crushed a little >>>>less in say 20 0? >>>> >>>>Fabien. >>> >>>People often claim that small evaluation should be a problem at slower time >>>control so if it has little evaluation it cannot do better at longer time >>>control. >>> >>>What is your opinion about it? >>>Is it a wrong opinion and chess is simply a search based game when almost every >>>hole in the evaluation can be covered by searching few plies deeper? >>> >>>I knew from the results of olithink that programs can do well even with small >>>evaluation but the results of your program suggest that olithink was not close >>>to the best that it is possible to do with small evaluation and I suspect that >>>it is even possible to be better than Crafty with your little evaluation(after >>>all I guess that you do not use all the good techniques that were mentioned and >>>for example you do not use history based pruning when the idea is to prune moves >>>that almost always failed low based on the history tables by searching them to >>>reduced depth,not to mention that you do not use pruning based on evaluation or >>>extensions except check extensions). >>> >>>Uri
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.