Hi,
I think I am making a bit too many threads on here recently. But this has been running around in my mind lately.
Do we all agree that the longer the time controls and the stronger the hardware, the more hash we generally need? And that we can have too little or too much hash set up for the engine depending on the circumstances. Stronger hardware, more hash required at a given time control, and this scales for a very, very long time.
For example, following Komodo 8's hash equation, with my 4670k @ 4.5ghz I will need jusssst about 4gb per engine for a 15 minute-entire-game time control without increments.
4670k @ 4.5 = 4gb per side, 8.1gb total, 16gb ram required
Octocore HaswellE = 8gb per side, 16.2gb total, 32gb ram required.
16Core Haswell E (if it existed) = 16, 32.4, 64gb
Of course, ram isn't sold in small chunks, you can't run "10gb of ram". The next step up is 16gb. So there: To run 4gb a side I need four times that.
Goes on and on. That would mean that for "infinite" analysis, using all of your ram as closely as possible would be best.
In case you're not familiar with K8's hash formula: Take time control, x3, run starting position with that many minutes but in seconds, see hash fill percentage; 30% is about right.
There is a huge problem with all this, and that's that more hash requirement means more ram needed. There's an opportunity cost here. If a $1000 Haswell-E octocore CPU requires $500 in ram to get some boost in performance, is that say, extra $250 worth it or is it better put into a stronger CPU? Or, is the penalty for insufficient hash so severe, it will cripple the gain from more cores? In addition, you can't just plug and play ram to your fancy, ideally the ram sticks are identical, coming from the same exact kit, and running in dual or in the case of x99 platform, quad channel. What happens if we start running octo-channel?
If I were to get the Haswell-E octocore, should I get 32 or 16gb of ram?
I think this is a very important question when it comes to deciding what to put inside my rig for chess. And hell, some people want to do longer analysis as the general rule unlike me, so they will want more ram? Then if they choose wrongly they could be wasting even more cash.
Hash Sizes... Again.
Moderator: Ras
-
- Posts: 79
- Joined: Mon Jun 30, 2014 3:48 pm
- Full name: Erica Lin
-
- Posts: 411
- Joined: Thu Dec 30, 2010 4:48 am
Re: Hash Sizes... Again.
It's generally not as big a deal as you make it out to be. There's generally two 'modes' to efficient hash table sizes
1) small enough that it's likely you're not to suffer many cache misses. This primarily is about making the search faster in NPS terms. This would depend primarily on the amount of cache available in your processor, not your RAM which you'll have more than enough of. This is only a terribly relevant consideration for blitz or faster type think times.
2) enough that useful entries are not likely to be pushed out. Too much is not an especially big concern here as it's likely to be big enough that a cache miss is entirely likely unless the node in question was used recently anyways. For very long searches this even would come down to 'as much as possible, more is always better'.
1) small enough that it's likely you're not to suffer many cache misses. This primarily is about making the search faster in NPS terms. This would depend primarily on the amount of cache available in your processor, not your RAM which you'll have more than enough of. This is only a terribly relevant consideration for blitz or faster type think times.
2) enough that useful entries are not likely to be pushed out. Too much is not an especially big concern here as it's likely to be big enough that a cache miss is entirely likely unless the node in question was used recently anyways. For very long searches this even would come down to 'as much as possible, more is always better'.
-
- Posts: 1339
- Joined: Fri Nov 02, 2012 9:43 am
- Location: New Delhi, India
Re: Hash Sizes... Again.
Hidark_wizzie wrote:Hi,
I think I am making a bit too many threads on here recently. But this has been running around in my mind lately.
Do we all agree that the longer the time controls and the stronger the hardware, the more hash we generally need? And that we can have too little or too much hash set up for the engine depending on the circumstances. Stronger hardware, more hash required at a given time control, and this scales for a very, very long time.
For example, following Komodo 8's hash equation, with my 4670k @ 4.5ghz I will need jusssst about 4gb per engine for a 15 minute-entire-game time control without increments.
4670k @ 4.5 = 4gb per side, 8.1gb total, 16gb ram required
Octocore HaswellE = 8gb per side, 16.2gb total, 32gb ram required.
16Core Haswell E (if it existed) = 16, 32.4, 64gb
Of course, ram isn't sold in small chunks, you can't run "10gb of ram". The next step up is 16gb. So there: To run 4gb a side I need four times that.
Goes on and on. That would mean that for "infinite" analysis, using all of your ram as closely as possible would be best.
In case you're not familiar with K8's hash formula: Take time control, x3, run starting position with that many minutes but in seconds, see hash fill percentage; 30% is about right.
There is a huge problem with all this, and that's that more hash requirement means more ram needed. There's an opportunity cost here. If a $1000 Haswell-E octocore CPU requires $500 in ram to get some boost in performance, is that say, extra $250 worth it or is it better put into a stronger CPU? Or, is the penalty for insufficient hash so severe, it will cripple the gain from more cores? In addition, you can't just plug and play ram to your fancy, ideally the ram sticks are identical, coming from the same exact kit, and running in dual or in the case of x99 platform, quad channel. What happens if we start running octo-channel?
If I were to get the Haswell-E octocore, should I get 32 or 16gb of ram?
I think this is a very important question when it comes to deciding what to put inside my rig for chess. And hell, some people want to do longer analysis as the general rule unlike me, so they will want more ram? Then if they choose wrongly they could be wasting even more cash.
Look at my signature. I have 64GB RAM for my i7 5960X.
Unfortunately, I cannot allot more then 16GB hash for Komodo 8 as it doesn't support 32 GB hash.
At a future point, I will upgrade to 128 GB System RAM, but may not be any use with Komodo 8 !
I wonder if Stockfish will support 64 GB Hash ?
i7 5960X @ 4.1 Ghz, 64 GB G.Skill RipJaws RAM, Twin Asus ROG Strix OC 11 GB Geforce 2080 Tis
-
- Posts: 1339
- Joined: Fri Nov 02, 2012 9:43 am
- Location: New Delhi, India
Re: Hash Sizes... Again.
Hidark_wizzie wrote:Hi,
I think I am making a bit too many threads on here recently. But this has been running around in my mind lately.
Do we all agree that the longer the time controls and the stronger the hardware, the more hash we generally need? And that we can have too little or too much hash set up for the engine depending on the circumstances. Stronger hardware, more hash required at a given time control, and this scales for a very, very long time.
For example, following Komodo 8's hash equation, with my 4670k @ 4.5ghz I will need jusssst about 4gb per engine for a 15 minute-entire-game time control without increments.
4670k @ 4.5 = 4gb per side, 8.1gb total, 16gb ram required
Octocore HaswellE = 8gb per side, 16.2gb total, 32gb ram required.
16Core Haswell E (if it existed) = 16, 32.4, 64gb
Of course, ram isn't sold in small chunks, you can't run "10gb of ram". The next step up is 16gb. So there: To run 4gb a side I need four times that.
Goes on and on. That would mean that for "infinite" analysis, using all of your ram as closely as possible would be best.
In case you're not familiar with K8's hash formula: Take time control, x3, run starting position with that many minutes but in seconds, see hash fill percentage; 30% is about right.
There is a huge problem with all this, and that's that more hash requirement means more ram needed. There's an opportunity cost here. If a $1000 Haswell-E octocore CPU requires $500 in ram to get some boost in performance, is that say, extra $250 worth it or is it better put into a stronger CPU? Or, is the penalty for insufficient hash so severe, it will cripple the gain from more cores? In addition, you can't just plug and play ram to your fancy, ideally the ram sticks are identical, coming from the same exact kit, and running in dual or in the case of x99 platform, quad channel. What happens if we start running octo-channel?
If I were to get the Haswell-E octocore, should I get 32 or 16gb of ram?
I think this is a very important question when it comes to deciding what to put inside my rig for chess. And hell, some people want to do longer analysis as the general rule unlike me, so they will want more ram? Then if they choose wrongly they could be wasting even more cash.
Look at my signature. I have 64GB RAM for my i7 5960X.
Unfortunately, I cannot allot more then 16GB hash for Komodo 8 as it doesn't support 32 GB hash.
At a future point, I will upgrade to 128 GB System RAM, but may not be any use with Komodo 8 !
I wonder if Stockfish will support 64 GB Hash ?
i7 5960X @ 4.1 Ghz, 64 GB G.Skill RipJaws RAM, Twin Asus ROG Strix OC 11 GB Geforce 2080 Tis
-
- Posts: 10872
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: Hash Sizes... Again.
shrapnel wrote:Hidark_wizzie wrote:Hi,
I think I am making a bit too many threads on here recently. But this has been running around in my mind lately.
Do we all agree that the longer the time controls and the stronger the hardware, the more hash we generally need? And that we can have too little or too much hash set up for the engine depending on the circumstances. Stronger hardware, more hash required at a given time control, and this scales for a very, very long time.
For example, following Komodo 8's hash equation, with my 4670k @ 4.5ghz I will need jusssst about 4gb per engine for a 15 minute-entire-game time control without increments.
4670k @ 4.5 = 4gb per side, 8.1gb total, 16gb ram required
Octocore HaswellE = 8gb per side, 16.2gb total, 32gb ram required.
16Core Haswell E (if it existed) = 16, 32.4, 64gb
Of course, ram isn't sold in small chunks, you can't run "10gb of ram". The next step up is 16gb. So there: To run 4gb a side I need four times that.
Goes on and on. That would mean that for "infinite" analysis, using all of your ram as closely as possible would be best.
In case you're not familiar with K8's hash formula: Take time control, x3, run starting position with that many minutes but in seconds, see hash fill percentage; 30% is about right.
There is a huge problem with all this, and that's that more hash requirement means more ram needed. There's an opportunity cost here. If a $1000 Haswell-E octocore CPU requires $500 in ram to get some boost in performance, is that say, extra $250 worth it or is it better put into a stronger CPU? Or, is the penalty for insufficient hash so severe, it will cripple the gain from more cores? In addition, you can't just plug and play ram to your fancy, ideally the ram sticks are identical, coming from the same exact kit, and running in dual or in the case of x99 platform, quad channel. What happens if we start running octo-channel?
If I were to get the Haswell-E octocore, should I get 32 or 16gb of ram?
I think this is a very important question when it comes to deciding what to put inside my rig for chess. And hell, some people want to do longer analysis as the general rule unlike me, so they will want more ram? Then if they choose wrongly they could be wasting even more cash.
Look at my signature. I have 64GB RAM for my i7 5960X.
Unfortunately, I cannot allot more then 16GB hash for Komodo 8 as it doesn't support 32 GB hash.
At a future point, I will upgrade to 128 GB System RAM, but may not be any use with Komodo 8 !
I wonder if Stockfish will support 64 GB Hash ?
More hash is better is an an unproved opinion.
I do not know of a rating list that tested Komodo8 or Stockfish
with 16 GB and with 1 GB to show that the 16 GB version has a better rating at some time control.
-
- Posts: 28378
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Hash Sizes... Again.
I agree. When you enter the parameter region where the tree no longer fits in hash in its entirety, a good hash implementation loses only about 8 Elo per hash-memory halving.
But there are other issues than just the amount of RAM. With too large a table size you will get more misses in the TLB cache, and even in higher levels of the TLB cache, slowing the engine down. It is not difficult at all to lose the tiny 8 Elo advantage by a RAM doubling to a slowdown of the engine.
But there are other issues than just the amount of RAM. With too large a table size you will get more misses in the TLB cache, and even in higher levels of the TLB cache, slowing the engine down. It is not difficult at all to lose the tiny 8 Elo advantage by a RAM doubling to a slowdown of the engine.
-
- Posts: 1339
- Joined: Fri Nov 02, 2012 9:43 am
- Location: New Delhi, India
Re: Hash Sizes... Again.
Exactly !Uri Blass wrote:More hash is better is an an unproved opinion.
I do not know of a rating list that tested Komodo8 or Stockfish
with 16 GB and with 1 GB to show that the 16 GB version has a better rating at some time control.
I had a Private Chat with Mr L. Kaufmann regarding certain findings of mine with regard to ELO change with different Hash sizes with different Engines.
He asked me not to make it public just yet and naturally I will honor his request.
Suffice to say that every Tom, Dick and Harry nowadays knows ELO rises with increasing Core Count, but variation of strength of various Engines with different Hash Values is still a relatively Grey area !
Regards
i7 5960X @ 4.1 Ghz, 64 GB G.Skill RipJaws RAM, Twin Asus ROG Strix OC 11 GB Geforce 2080 Tis
-
- Posts: 1339
- Joined: Fri Nov 02, 2012 9:43 am
- Location: New Delhi, India
Re: Hash Sizes... Again.
You are quite correct.hgm wrote: It is not difficult at all to lose the tiny 8 Elo advantage by a RAM doubling to a slowdown of the engine.
But there are two aspects to this that you have not considered :-
1. What if a very fast Haswell-E or Dual-Xeon with loads of RAM is being used ?
2. There is a possibility that at a certain Hash level, the rise in strength/ELO of the Engine rises so rapidly so as to negate the slight loss of ELO due to slowdown of the Engine !
Remarkably, this may also be seen with not so fast CPUs !
More than this I will not say.
You can believe it or not, doesn't make much difference to me.
And like Larry Kaufmann told me, there is nothing stopping anyone else from discovering what I have discovered !
Regards !
i7 5960X @ 4.1 Ghz, 64 GB G.Skill RipJaws RAM, Twin Asus ROG Strix OC 11 GB Geforce 2080 Tis
-
- Posts: 10872
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: Hash Sizes... Again.
The only tests that I know that people did to test different hash is from the stockfish framework
Here are the relevant results
http://tests.stockfishchess.org/tests/v ... 0b12db5ac4
32 mbytes is probably the best hash for 15+0.05(15 seconds per game+0.05 seconds per move) it could beat 128 mbytes by the following result
ELO: 2.59 +-2.0 (95%) LOS: 99.5%
Total: 40000 W: 6800 L: 6502 D: 26698
16 mbytes seems to be the same strength as 128 mbytes
http://tests.stockfishchess.org/tests/v ... 18089440c3
ELO: 0.44 +-2.0 (95%) LOS: 67.1%
Total: 40000 W: 6662 L: 6611 D: 26727
8 mbytes seems to be only slightly weaker
http://tests.stockfishchess.org/tests/v ... 1df44848cb
ELO: -2.19 +-2.0 (95%) LOS: 1.4%
Total: 40000 W: 6558 L: 6810 D: 26632
only with 4 mbytes stockfish found a big reduction in playing strength
http://tests.stockfishchess.org/tests/v ... 531a6b3404
ELO: -13.91 +-2.0 (95%) LOS: 0.0%
Total: 40000 W: 5833 L: 7434 D: 26733
Here are the relevant results
http://tests.stockfishchess.org/tests/v ... 0b12db5ac4
32 mbytes is probably the best hash for 15+0.05(15 seconds per game+0.05 seconds per move) it could beat 128 mbytes by the following result
ELO: 2.59 +-2.0 (95%) LOS: 99.5%
Total: 40000 W: 6800 L: 6502 D: 26698
16 mbytes seems to be the same strength as 128 mbytes
http://tests.stockfishchess.org/tests/v ... 18089440c3
ELO: 0.44 +-2.0 (95%) LOS: 67.1%
Total: 40000 W: 6662 L: 6611 D: 26727
8 mbytes seems to be only slightly weaker
http://tests.stockfishchess.org/tests/v ... 1df44848cb
ELO: -2.19 +-2.0 (95%) LOS: 1.4%
Total: 40000 W: 6558 L: 6810 D: 26632
only with 4 mbytes stockfish found a big reduction in playing strength
http://tests.stockfishchess.org/tests/v ... 531a6b3404
ELO: -13.91 +-2.0 (95%) LOS: 0.0%
Total: 40000 W: 5833 L: 7434 D: 26733
-
- Posts: 28378
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Hash Sizes... Again.
Well, I systematically investigated how the size of the search tree varied with hash size, in order to evaluate various replacement schemes. As this is almost exclusively a speed effect, it doesn't make much sense to test it in games. Just recording nodes to depth for some 1000 positions would be good enough.