Author: Komputer Korner
Date: 12:35:54 05/29/98
Go up one level in this thread
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. Of course you need a table as large as one move's worth of thinking will store, but when that is not possible based on the thinking time and the speed of your computer, then the search will slow down by the same factor as the hash table enabled it to speed up. The search will not grind to a halt nor will the slowdown be that much but in the endgame it can be more than a factor of 2. Tests are needed for every program playing every other program in matches at different hash table sizes ( one match where the hash table never fills and one match without hash tables). Until these tests are completed and I wonder if they will ever be given the fact that different programs are optimized for different arhitectures ( Intel vs AMD) , this argument will remain just speculation, given the amount of rancor and difficulty of conducting regular matches in the first place.
This page took 0.01 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.