Author: Don Dailey
Date: 01:11:33 05/31/98
Go up one level in this thread
On May 31, 1998 at 01:46:32, Komputer Korner wrote: > >On May 30, 1998 at 18:36:51, Christophe Theron wrote: > >>On May 29, 1998 at 15:35:54, Komputer Korner wrote: >> >>>On May 29, 1998 at 15:10:43, Mark Young wrote: >>> >>>>On May 29, 1998 at 14:52:42, Christophe Theron wrote: >>>> >>>>>On May 29, 1998 at 06:04:42, Enrique Irazoqui wrote: >>>>> >>>>>>On May 29, 1998 at 01:23:32, Christophe Theron wrote: >>>>>> >>>>>>>On May 28, 1998 at 20:01:08, Enrique Irazoqui wrote: >>>>>>> >>>>>>>> >>>>>>>>On a PII/300 >>>>>>>> 100MB 50MB 25MB >>>>>>>>BS2830-14 208'' 224'' 301'' >>>>>>>>BT2630-09 404'' 406'' 435'' >>>>>>>> >>>>>>>> >>>>>>>>On a P200MMX >>>>>>>> 100MB 40MB 22MB >>>>>>>>BT2630-09 524'' 560'' >>>>>>>>Fritzmark 174 156 154 >>>>>>>> >>>>>>>>Chessbase claim that by increasing hashtables from 40 MB to 100 MB on a >>>>>>>>P200MMX, Fritz 5 is 50 Elo points stronger. It doesn't make sense to me >>>>>>>>that doubling RAM has the same effect as doubling the processor speed. >>>>>>>>After the times above, maybe going from 25 to 100 MB hash Friz 5 can >>>>>>>>become some 20 points stronger. >>>>>>>> >>>>>>>>Enrique >>>>>>> >>>>>>>Thanks for the concrete data, Enrique. >>>>>>> >>>>>>>So we can see on these positions that Fritz gains 31% in speed on >>>>>>>BS2830-14, and 7% on BT2630-09 when we give it 4x times more hash >>>>>>>tables. >>>>>>> >>>>>>>Could you please post the positions in EPD format, so I will be able to >>>>>>>give the results for Tiger as promised? >>>>>>> >>>>>>> >>>>>>> Christophe >>>>>> >>>>>>BS2830-14: >>>>>>r1bqr1k1/pp1n1ppp/5b2/4N1B1/3p3P/8/PPPQ1PP1/2K1RB1R w - - 0 0 bm Nxf7 >>>>>> >>>>>>BT2630-09: >>>>>>r5k1/pp2p1bp/6p1/n1p1P3/2qP1NP1/2PQB3/P5PP/R4K2 b - - 0 0 bm g5 >>>>>> >>>>>>It's true that many more positions are needed to make sure about the >>>>>>influence of hash size on Fritz 5, but I am too lazy to collect so much >>>>>>data. I picked 2 positions where F5 uses an amount of time typical of >>>>>>games at 40/2. >>>>>> >>>>>>Enrique >>>>> >>>>>Tiger does not find the first position in a reasonnable time (it >>>>>evaluates Nxf7 as being slighty inferior as the moves it would play). >>>>> >>>>>On the second position, the result is (computer is K5-100MHz): >>>>> >>>>>With 0.5Mb hash table: g5 found in 127.10s >>>>>With 1Mb : 114.52s (9.90% faster) >>>>>With 2Mb : 108.36s (5.38% faster) >>>>>With 4Mb : 101.06s (6.74% faster) >>>>>With 8Mb : 96.77s (4.25% faster) >>>>>With 16Mb : 91.50s (5.45% faster) >>>>>With 32Mb : 88.37s (3.42% faster) >>>>> >>>>> >>>>>It is obvious that the table gets quickly filled when I give Tiger only >>>>>0.5Mb hash. I think it is getting full only at the end of the search >>>>>with 32Mb hash tables. >>>>> >>>>>But it is hard to say by looking at the numbers that the search suddenly >>>>>slows down because of a full table. >>>>> >>>>>The only thing that is obvious is that more hash brings less and less >>>>>speedup. There is always something to gain from more hash tables, but >>>>>not much when you already have, say, 16Mb. >>>>> >>>>>This is true for Tiger, and one could object that Fritz behaves >>>>>differently, which still has to be shown. >>>>> >>>>>If Fritz gets the same percentage speedup when you double its hash >>>>>tables than other programs, and that's what I believe, then it is not >>>>>clear to me why Fritz is considered as an exception regarding hash table >>>>>management and needs... >>>>> >>>>I found the same results with fritz 5. See Fritz5 (fritzmark profile). >>>>Fritz is not an exception. Like your program more hash does help some. >>>>But less and less as you add more hash. So I don't see a big ratings >>>>gain going from 50 mb to 100 mb for Fritz 5 as some people may think. >>>> >>>> >>>> >>>>>How is it that we hear so much about Fritz5 and nothing about, say, >>>>>Virtual Chess, which is an underestimated great program? Should I >>>>>remember you which is the current world champion amongst the >>>>>professional microcomputer programs? >>>>> >>>>> >>>>> Christophe >>> >>>Because hash tables store previously calculated positions and because >>>they fill up with limited time and because the replacement strategy is >>>slightly different depending on the program/position and because each >>>program has a different implementation of the hashing function (vis a >>>vis 2 tables vs 1 table ; pawn hash tables...etc) and because each >>>program has different move ordering algorithms, and because every >>>program has different search strategies, you cannot say a priori that >>>all programs are equally affected by larger hash tables. There are a lot of differences you are mentioning here, but in the end, most of the good programs are pretty similar and they all seem to experience about a 7% per doubling. In most cases, a lot of implementation details end up bringing you to the same point. Most of these things are pretty optimal (as least as far as we know so far) in all the good chess programs so I think the generalization is roughly correct that all programs (all good programs) are equally affected by larger hash tables. I'm sure there are minor variations though. - Don
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.