Using Komodo 9.1 with Maximum Hash, 64GB machine

[RJN]

Komodo 9.1 uses 25% less actual memory than the hash setting (for example, 32GB uses only about 24GB of physical RAM). So, 64GB hash setting should use about 48GB of actual RAM, I would expect. Plenty left over on a 64GB machine. Yet when I try to use 64GB, Komodo reports an error that my system does not have enough RAM, and reverts to 32GB (actual 24GB physical).

Is there a workaround for this? Or possibly this is an obsolete error condition.

[shrapnel]

Hi Rob
I too have a 64 GB machine.
Though theory says that you can use upto half the System Memory as hash, I have found that for practical purposes (like gaming) it is better not to use more than one-fourth of the System Memory as Hash.
In your case, 16 GB hash would be ideal, for all purposes ;anything else would only slow down your machine.

[lkaufman]

Komodo 9.1 uses 25% less actual memory than the hash setting (for example, 32GB uses only about 24GB of physical RAM). So, 64GB hash setting should use about 48GB of actual RAM, I would expect. Plenty left over on a 64GB machine. Yet when I try to use 64GB, Komodo reports an error that my system does not have enough RAM, and reverts to 32GB (actual 24GB physical).

Is there a workaround for this? Or possibly this is an obsolete error condition.

Mark would know better, but it is my understanding that you should set hash to 48GB in your situation, assuming you are using it for long analysis where this might help. Komodo is supposed to use 25% less than the setting IF YOU SET to a power of 2. But if you set to 3x a power of two, such as 48GB, it should use all of it. I don't have a 64Gb machine to test this on though.

[mjlef]

Komodo 9.1 uses 25% less actual memory than the hash setting (for example, 32GB uses only about 24GB of physical RAM). So, 64GB hash setting should use about 48GB of actual RAM, I would expect. Plenty left over on a 64GB machine. Yet when I try to use 64GB, Komodo reports an error that my system does not have enough RAM, and reverts to 32GB (actual 24GB physical).

Is there a workaround for this? Or possibly this is an obsolete error condition.

Are you running more than one engine? That second program may be taking up a lot of space. And the whole operating system, and whatever GUI you are using also takes memory. So maybe there is not enough memory left over to get the full 48 GB.`

We include a sequence of steps you can use to decide how much memory to use, based on the time control. It is included in the zip file. My guess is 24 GB is probably enough for your needs.

What kind of processor do you have? Is it a multi-NUMA node machine? Access to memory across NUMA nodes is pretty slow, and is something we look at in terms of slowdown versus elo gain from larger hash tables.I am looking at ways of better managing the Hash on NUMA machines, but the "pipe" between NUMA nodes is pretty slow on the machines I have used.

Mark

[zullil]

What kind of processor do you have? Is it a multi-NUMA node machine?

Mark

See the signature line in his original post.

[egiovannotti]

Komodo 9.1 uses 25% less actual memory than the hash setting (for example, 32GB uses only about 24GB of physical RAM). So, 64GB hash setting should use about 48GB of actual RAM, I would expect. Plenty left over on a 64GB machine. Yet when I try to use 64GB, Komodo reports an error that my system does not have enough RAM, and reverts to 32GB (actual 24GB physical).

Is there a workaround for this? Or possibly this is an obsolete error condition.

It is likely to have an integrated video card, and the BIOS takes part of system memory for video.

[RJN]

Komodo 9.1 uses 25% less actual memory than the hash setting (for example, 32GB uses only about 24GB of physical RAM). So, 64GB hash setting should use about 48GB of actual RAM, I would expect. Plenty left over on a 64GB machine. Yet when I try to use 64GB, Komodo reports an error that my system does not have enough RAM, and reverts to 32GB (actual 24GB physical).

Is there a workaround for this? Or possibly this is an obsolete error condition.

Mark would know better, but it is my understanding that you should set hash to 48GB in your situation, assuming you are using it for long analysis where this might help. Komodo is supposed to use 25% less than the setting IF YOU SET to a power of 2. But if you set to 3x a power of two, such as 48GB, it should use all of it. I don't have a 64Gb machine to test this on though.

Thanks, that worked. Funny thing is now that I have rebooted, setting hash at 64GB uses the same as 48GB, so it now uses the expected amount of physical RAM. BTW, as a reply to others, originally I had checked that most RAM was free, no other engines running, I have a discrete MSI video card, all that.

Here is the message that keeps coming up when hash is set to 65536, note that it does not sound like free memory, just a (inaccurate?) total:

Warning: Too Many RAM Set (Your PC only has 65437MB)!

[mjlef]

Komodo 9.1 uses 25% less actual memory than the hash setting (for example, 32GB uses only about 24GB of physical RAM). So, 64GB hash setting should use about 48GB of actual RAM, I would expect. Plenty left over on a 64GB machine. Yet when I try to use 64GB, Komodo reports an error that my system does not have enough RAM, and reverts to 32GB (actual 24GB physical).

Is there a workaround for this? Or possibly this is an obsolete error condition.

Mark would know better, but it is my understanding that you should set hash to 48GB in your situation, assuming you are using it for long analysis where this might help. Komodo is supposed to use 25% less than the setting IF YOU SET to a power of 2. But if you set to 3x a power of two, such as 48GB, it should use all of it. I don't have a 64Gb machine to test this on though.

Thanks, that worked. Funny thing is now that I have rebooted, setting hash at 64GB uses the same as 48GB, so it now uses the expected amount of physical RAM. BTW, as a reply to others, originally I had checked that most RAM was free, no other engines running, I have a discrete MSI video card, all that.

Here is the message that keeps coming up when hash is set to 65536, note that it does not sound like free memory, just a (inaccurate?) total:

Warning: Too Many RAM Set (Your PC only has 65437MB)!

Memory allocation for Hash tables requires contiguous memory. As you use your computer and run various programs, sections of memory get allocated and freed (well, they are supposed to get freed). So you are more likely to be able to use a larger hash size right after you reboot your computer than later on when various programs and processes have split memory up into smaller available chunks. Since programs have to coexist in the operating system, it is probably best not to allocate too much. I try to limit it to half of the total memory, and much less for faster time controls. Naturally, if you are going to run two programs against each other in a match, you would want to half that again. Otherwise the operating system will be forced to use virtual memory which will swap out memory between the real physical memory and the hard drive. And that will be a huge slowdown for the engines.

We include a document "sethash.txt" with Komodo that advises what size hash to use. A copy is below. This system adjusts for the speed of memory and machine based on the time control. Of course an infinite time control would have infinite memory available, so eventually you reach practical limits on a specific machine:

How should I set the hash table size?
=====================================

In general the default hash table size setting in Komodo will work well for you. However, if you want optimal performance you may wish to tweak this value. We are providing some guidelines here.

The optimal hash table size setting for Komodo is when the program utilizes half, or less, of the hash table. When the percentage exceeds 50% you will see a decline in performance. In modern chess programs the hash tables can fill very quickly, so it may not be possible to provide the optimal hash table size, especially when doing deep searches or using the program for deep analysis or where the amount of memory on a given machine is limited. So the rule of thumb in these cases is to set the hash table size as large as reasonably possible without sacrificing too much system performance.

Keep in mind that very heavy memory usage can impact the speed of the program and the underlying operating system. If you find your machine is less responsive, try a small hash table size.

We have devised a general rule of thumb for determining how large to set the hash table based on the time control you wish to play. Machine vary in speed, but these rule will help you set a p[roper hash table size. We consider sudden death or Fischer time controls but these guidelines can be extrapolated to other time controls. There are system considerations too so this is not a hard rule but really just a general guideline and does not take into consideration the memory caching performance of your machine. Nevertheless, most modern PC's will do well with these settings:

1. Take the main time in minutes and add the increment in seconds (for sudden death the increment is zero.) Example a 5 minute plus 1 sec increment game would be 5 + 1 = 6.

2. Multiply the value obtained in step 1 by 3. In the above example, 5x3 = 15.

3. From the opening position, do a fixed time search of exactly this amount of time in seconds. (15 seconds in this example)

4. Note the hash table utilization as reported by the GUI.

5. If the hash table utilization is much above 40%, double the hash table size and repeat this test.

6. If the hash table utilization is too small, for example well below 20%, you are probably setting your table higher than it needs to be.

For technical reasons, setting a hash table that is much larger than it needs to be will have a negative impact on the performance of your chess program (and the rest of the system) as it place more demands on the memory sub-system and cache. However the impact is generally pretty minor up to about half of the total RAM on your system. Going beyond that is risky. In general, all other things being equal, you should err on the side of being too large rather than being too small, as long as you don't exceed half of total memory. We generally suggest choosing the smallest hash table size that gives no more than about 40% utilization using this test.

[RJN]

Hi Mark, I am only attempting to set hash this high for infinite analysis. I was aware of the document on setting hash for specific time controls, but this is the first I knew that hash requires contiguous memory. I thought only large pages needed that (??)

[bob]

Komodo 9.1 uses 25% less actual memory than the hash setting (for example, 32GB uses only about 24GB of physical RAM). So, 64GB hash setting should use about 48GB of actual RAM, I would expect. Plenty left over on a 64GB machine. Yet when I try to use 64GB, Komodo reports an error that my system does not have enough RAM, and reverts to 32GB (actual 24GB physical).

Is there a workaround for this? Or possibly this is an obsolete error condition.

Mark would know better, but it is my understanding that you should set hash to 48GB in your situation, assuming you are using it for long analysis where this might help. Komodo is supposed to use 25% less than the setting IF YOU SET to a power of 2. But if you set to 3x a power of two, such as 48GB, it should use all of it. I don't have a 64Gb machine to test this on though.

Thanks, that worked. Funny thing is now that I have rebooted, setting hash at 64GB uses the same as 48GB, so it now uses the expected amount of physical RAM. BTW, as a reply to others, originally I had checked that most RAM was free, no other engines running, I have a discrete MSI video card, all that.

Here is the message that keeps coming up when hash is set to 65536, note that it does not sound like free memory, just a (inaccurate?) total:

Warning: Too Many RAM Set (Your PC only has 65437MB)!

Memory allocation for Hash tables requires contiguous memory. As you use your computer and run various programs, sections of memory get allocated and freed (well, they are supposed to get freed). So you are more likely to be able to use a larger hash size right after you reboot your computer than later on when various programs and processes have split memory up into smaller available chunks. Since programs have to coexist in the operating system, it is probably best not to allocate too much. I try to limit it to half of the total memory, and much less for faster time controls. Naturally, if you are going to run two programs against each other in a match, you would want to half that again. Otherwise the operating system will be forced to use virtual memory which will swap out memory between the real physical memory and the hard drive. And that will be a huge slowdown for the engines.

Sorry to jump in, but that makes zero sense to me. All machines today use virtual memory, which means any two physical pages of memory can be made contiguous through the memory map, which every process uses. The only exception is if you try to use really big pages (i.e. 2mb pages is automatic under linux, I don't know how it is done under windows but many complain about fragmentation issues. In linux, data gets moved around and re-mapped to create 2mb physically contiguous chunks of memory that can be mapped as a single 2mb page.

I've not seen this "contiguous memory problem" either on windows nor on linux. It should not exist on any architecture since the 80286 came along with the MMU hardware.

We include a document "sethash.txt" with Komodo that advises what size hash to use. A copy is below. This system adjusts for the speed of memory and machine based on the time control. Of course an infinite time control would have infinite memory available, so eventually you reach practical limits on a specific machine:

How should I set the hash table size?
=====================================

In general the default hash table size setting in Komodo will work well for you. However, if you want optimal performance you may wish to tweak this value. We are providing some guidelines here.

The optimal hash table size setting for Komodo is when the program utilizes half, or less, of the hash table. When the percentage exceeds 50% you will see a decline in performance. In modern chess programs the hash tables can fill very quickly, so it may not be possible to provide the optimal hash table size, especially when doing deep searches or using the program for deep analysis or where the amount of memory on a given machine is limited. So the rule of thumb in these cases is to set the hash table size as large as reasonably possible without sacrificing too much system performance.

Keep in mind that very heavy memory usage can impact the speed of the program and the underlying operating system. If you find your machine is less responsive, try a small hash table size.

We have devised a general rule of thumb for determining how large to set the hash table based on the time control you wish to play. Machine vary in speed, but these rule will help you set a p[roper hash table size. We consider sudden death or Fischer time controls but these guidelines can be extrapolated to other time controls. There are system considerations too so this is not a hard rule but really just a general guideline and does not take into consideration the memory caching performance of your machine. Nevertheless, most modern PC's will do well with these settings:

1. Take the main time in minutes and add the increment in seconds (for sudden death the increment is zero.) Example a 5 minute plus 1 sec increment game would be 5 + 1 = 6.

2. Multiply the value obtained in step 1 by 3. In the above example, 5x3 = 15.

3. From the opening position, do a fixed time search of exactly this amount of time in seconds. (15 seconds in this example)

4. Note the hash table utilization as reported by the GUI.

5. If the hash table utilization is much above 40%, double the hash table size and repeat this test.

6. If the hash table utilization is too small, for example well below 20%, you are probably setting your table higher than it needs to be.

For technical reasons, setting a hash table that is much larger than it needs to be will have a negative impact on the performance of your chess program (and the rest of the system) as it place more demands on the memory sub-system and cache. However the impact is generally pretty minor up to about half of the total RAM on your system. Going beyond that is risky. In general, all other things being equal, you should err on the side of being too large rather than being too small, as long as you don't exceed half of total memory. We generally suggest choosing the smallest hash table size that gives no more than about 40% utilization using this test.