Author: Komputer Korner
Date: 23:34:20 05/31/98
Go up one level in this thread
On May 31, 1998 at 18:50:01, Christophe Theron wrote: >On May 31, 1998 at 10:17:51, Moritz Berger wrote: > >>On May 30, 1998 at 18:36:51, Christophe Theron wrote: >> >>>>>On May 29, 1998 at 14:52:42, Christophe Theron wrote: >> >>>>>>>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 >> >>>>>>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. >>>>>> >>>>>>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. >>>>>> >> >> >>>Okay. Every program is different. >>> >>>My point is only that Fritz hash tables behaviour is not very different >>>from other programs behaviour. I chose mine to give an example, but you >>>can find similar data with other programs too. >>> >>>Speculation would be to pretend that Fritz has such a different >>>behaviour. >>> >>>But Fritz manual seems to have created a kind of legend around this. It >>>is just time to calm down and to realize that there is nothing special >>>to talk about. >>> >> >>Chess Tiger gets a 12% speedup on the two positions mentioned above by >>going from 4MB hash tables to 32MB. >> >>Fritz gets 23% on the 35 positions in the LCT II testsuite from a >>roughly 4-fold hash table increase from 12MB to 98MB (on P233MMX >>hardware). I therefore feel that the hash table efficience issue for >>Fritz could well be somewhat different from e.g. your program or Crafty. >> >>Moritz > >It could be slightly different, yes, but not much. I don't have enough >time to let Tiger run the LCT2 test twice with 4Mb and 32Mb, so it's >hard for me to argue on this point. > >But you know that the LCT test includes some endgame positions, which >are more hash-sensitive than the 2 positions above. > >Anyway, a 23% speed increase from a 8x hash table size increase does not >give you many elo points. Assuming that doubling your speed gives you 70 >elo points (in fact it is less than that), a 23% speed increase could >give you no more than 20 elo points. > >I insist: if the SSDF had given Fritz 8x more memory than to the other >programs, the advantage for Fritz could be NO MORE THAN 20 elo points. > >And how much hash table has been given Fritz? Twice the amount of other >programs? So it could be a 5 elo points advantage??? What a big deal! >Does it justify the amount of posts on the subject??? > >So this should terminate right now any claim about such an unfair >advantage the SSDF has given to Fritz with their slightly bigger hash >tables. > > > Christophe I don't understand the hash argument anyway, because SSDF did not limit the other programs. The problems of the other programs are that they have a maximum hash size that is inherent in the program itself. Fritz 5 does not have this limit so why should it be limited? If the consumer wants to buy 256 Mb of RAM and his machine will take it and Fritz will use it then why not test with that? The SSDF is not about low end systems. It is about being the best that is commercially available.
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.