Ideal hash size for short time controls

[Charles]

I think 128Mb is the ideal hash size for short /blitz time controls. e.g. 5/0,1/0,1+1.

I ran a +3s 60 Game match betw houdini and rybka 4 and houdini beat rybka 4 by 7 games ... Earlier using the same suite rybka had beaten houdini by about 3 so i chalked it up to variance. But when i tried another match i noticed that houdini was just beating rybka 4 too easily ....i had made a mistake! Rybka 4 had 256hash and houdini only 128hash. Because of the smaller hash houdini ran much faster and beat rybka more easily. I had been messing around with the hash settings earlier and screwed something up.
A while back I had noticed that very large hash sizes slow down the engine for example set engine A with 128 hash engine b (same as A) but with 1gb hash - the smaller hash size will always win -- for ponder=off blitz controls.


Has anyone noticed this ? Why do some people test with 1gb hash but with 1/0 time controls? makes no sense ..

[Matthias Gemuh]

I think 128Mb is the ideal hash size for short /blitz time controls. e.g. 5/0,1/0,1+1.

Not true for some engines.

Has anyone noticed this ? Why do some people test with 1gb hash but with 1/0 time controls? makes no sense ..

Makes a lot of sense for some engines (example: my BigLion).

Matthias.

[BB+]

I think 128Mb is the ideal hash size for short /blitz time controls. e.g. 5/0,1/0,1+1.

Fruit, and now the latest IvanHoe, has a hashfull indicator, and the CHANGE_LOG file with IvanHoe claims that it should fill up about 10-15 Mb/sec/cpu (my guess is that they mean a 64-bit 2-3Ghz desktop machine, not a 32-bit laptop). There also needs to be some consideration about how long a entry in hash table is "useful" (on average, it might even be less than 1 search). IvanHoe has 128-bit entries, while Rybka has only 64-bit, so the memory should fill up about only half as fast for the latter. Engines which don't use hash in qsearch probably also don't increase hashfull so much. I have definitely noticed a problem of slowdown with "too large" of a hash with some programmes, though I don't know if "large pages" would solve this.

[Mincho Georgiev]

I think 128Mb is the ideal hash size for short /blitz time controls. e.g. 5/0,1/0,1+1.

Fruit, and now the latest IvanHoe, has a hashfull indicator, and the CHANGE_LOG file with IvanHoe claims that it should fill up about 10-15 Mb/sec/cpu (my guess is that they mean a 64-bit 2-3Ghz desktop machine, not a 32-bit laptop). There also needs to be some consideration about how long a entry in hash table is "useful" (on average, it might even be less than 1 search). IvanHoe has 128-bit entries, while Rybka has only 64-bit, so the memory should fill up about only half as fast for the latter. Engines which don't use hash in qsearch probably also don't increase hashfull so much. I have definitely noticed a problem of slowdown with "too large" of a hash with some programmes, though I don't know if "large pages" would solve this.

I don't store the hash in qsearch as well as don't do it after a null search. True, the hash table fills slower, but I see it somehow differently. IMO, the hash table size benefit is independent of the time control, due to the significant amount of games that will take place. That of course is irrelevant when we are talking about
programs that will clear the hash when it gets filled or using the uci option ClearHash, which instructs the GUI to clear the hash before every new game.
Excluding these two possibilities, as well as some others (like unaligned table and wrong indexing), I don't see how the smaller hash table will bring a benefit over the bigger one on a fast time controls.

[Charles]

I want to run a long 1 on 1 match on Arena (about 600 games) -- the option to "restart engines" after every game is on -- so I am sure the hash is cleared after every game - right?
My time control is 0/4 (4second per move) - since I'm using a suite arena auto increments for every move already made so its approx 20s+4s
Its ponder=off, the engines are Houdini and Rybka 4 -- i have a 32 bit 4 cpu Q6600 2.4Ghz. I have 3gb memory

Should I use 128Mb hash each, or 256 or more ?



The plan is to have a guantlet of Houdini1.01 vs R4 and Houdini 1.02 vs R4 ... 300 games each. using 150 positions from the klo suite.


btw - Rybka 4 and Houdini will be at defaults -- I don't see any option to "clear hash" when filled.

I think 128Mb hash should be ok,, will having more be of any benefit?

[kingliveson]

I want to run a long 1 on 1 match on Arena (about 600 games) -- the option to "restart engines" after every game is on -- so I am sure the hash is cleared after every game - right?
My time control is 0/4 (4second per move) - since I'm using a suite arena auto increments for every move already made so its approx 20s+4s
Its ponder=off, the engines are Houdini and Rybka 4 -- i have a 32 bit 4 cpu Q6600 2.4Ghz. I have 3gb memory

Should I use 128Mb hash each, or 256 or more ?



The plan is to have a guantlet of Houdini1.01 vs R4 and Houdini 1.02 vs R4 ... 300 games each. using 150 positions from the klo suite.


btw - Rybka 4 and Houdini will be at defaults -- I don't see any option to "clear hash" when filled.

I think 128Mb hash should be ok,, will having more be of any benefit?

With that hardware and time control, 32 MB should be fine. Anything over 64 MB is overkill.

[hyatt]

Some misinformation above, so to clarify.

1. Bigger hash is definitely bad, because the larger your program, the more physical pages of RAM you use, and the more TLB entries you need to avoid "walking the tables" to convert virtual to physical addresses. If you blow the TLB, you can (on 64 bit hardware) add 4 extra memory accesses to each primary memory address because of the virtual-to-physical mapping that must be done. So more RAM = more TLB entries needed, and when you run out, memory access time goes _way_ up.

2. Bigger hash makes the search more efficient, until you reach the point where you can store the entire tree you are searching. Going beyond that only stresses the TLB and slows things down. The idea is that you want a hash size that is about the size of the tree you want to store in the table. If you search 1M nodes per second, and you are playing 1 second per move, you need a hash size of 1M. A little bigger might help marginally, but you can quickly lose this marginal gain due to TLB thrashing. If the engine does not hash q-search nodes (Crafty is an example) then you need about 10% of the total nodes searched as a hash size. In the above, for Crafty, 100K entries would be fine. 1M would not hurt as that is not big enough to hurt so much.

A good processor might have 1024 TLB entries. That means for 1024 virtual pages, you can get instant virtual-to-real translations. At 4K byte page size, that means going beyond 4M total will start to stress the TLB. Modern processors can also use "large pages" which can be either 2M or 4M depending on architecture. That lets you address 1000x as much memory using the same TLB.

[Charles]

This is all very interesting --very much appreciate the responses.

So it looks like 128Mb hash is more than enough and even 64 Mb hash is adequate for most engines at blitz controls.

I was wondering what benefit if any could there be of running blitz 10/0 matches with 1Gb hash .... it seems that more hash is probably good for analysis mode and not for engine matches ...
CCRL uses 128mb hash for their testing too.

[Mincho Georgiev]

Some misinformation above, so to clarify.

1. Bigger hash is definitely bad, because the larger your program, the more physical pages of RAM you use, and the more TLB entries you need to avoid "walking the tables" to convert virtual to physical addresses. If you blow the TLB, you can (on 64 bit hardware) add 4 extra memory accesses to each primary memory address because of the virtual-to-physical mapping that must be done. So more RAM = more TLB entries needed, and when you run out, memory access time goes _way_ up.

2. Bigger hash makes the search more efficient, until you reach the point where you can store the entire tree you are searching. Going beyond that only stresses the TLB and slows things down. The idea is that you want a hash size that is about the size of the tree you want to store in the table. If you search 1M nodes per second, and you are playing 1 second per move, you need a hash size of 1M. A little bigger might help marginally, but you can quickly lose this marginal gain due to TLB thrashing. If the engine does not hash q-search nodes (Crafty is an example) then you need about 10% of the total nodes searched as a hash size. In the above, for Crafty, 100K entries would be fine. 1M would not hurt as that is not big enough to hurt so much.

A good processor might have 1024 TLB entries. That means for 1024 virtual pages, you can get instant virtual-to-real translations. At 4K byte page size, that means going beyond 4M total will start to stress the TLB. Modern processors can also use "large pages" which can be either 2M or 4M depending on architecture. That lets you address 1000x as much memory using the same TLB.

I'll say again. I don't see how smaller hash table will bring the benefit over the bigger one. I didn't say that bigger is better. Maybe I'm missing something, so help me if I am, but we are not talking about playing vs engine. The topic was about engine match, right ? So the conditions (hashsize) for the two engines will be equal? So the lookaside buffer issues will be valid for both engines. Probably this will have some impact on randomness, but I don't see what else ?

[Sentinel]

Maybe I'm missing something, so help me if I am, but we are not talking about playing vs engine. The topic was about engine match, right ? So the conditions (hashsize) for the two engines will be equal? So the lookaside buffer issues will be valid for both engines. Probably this will have some impact on randomness, but I don't see what else ?

In you carefully read Charles post that started this thread you'll see that the hash size was not the same for both engines and the thing that Charles noticed is that engine with smaller hash was playing stronger for the given TC.
Bob just explained why.
When hash is equal the strength difference between engines will stay more less the same despite the hash size, but in absolute figures both engines will play stronger with smaller hash for the given blitz time control.