Crafty 22.0 SMP - tbs problem

[Werner]

Hi all,
as this new problem is not easy to find between the long thread I will repeat it here:
Charles found out:

I tried running a match against Bright 0.2c 2CPU under Arena 1.1 and Arena 1.99beta5. Everything is okay until Crafty starts using egtbs. Then Bright uses only 50% CPU power and slows down to a crawl. One game Bright even forfeited on time which has never happened before.

I have the same problem against other dual engines. To show what happens I made a picture:
http://www.husvankempen.de/nunn/crafty_22_0.JPG

Naum is normally here running more than 2000 kns - now only 74!!
This happens in every GUI so on a dual you cannot play eng-eng matches against another dual engine.

[Tony]

Hi all,
as this new problem is not easy to find between the long thread I will repeat it here:
Charles found out:

I tried running a match against Bright 0.2c 2CPU under Arena 1.1 and Arena 1.99beta5. Everything is okay until Crafty starts using egtbs. Then Bright uses only 50% CPU power and slows down to a crawl. One game Bright even forfeited on time which has never happened before.

I have the same problem against other dual engines. To show what happens I made a picture:
http://www.husvankempen.de/nunn/crafty_22_0.JPG

Naum is normally here running more than 2000 kns - now only 74!!
This happens in every GUI so on a dual you cannot play eng-eng matches against another dual engine.

It's not a new problem.

You can make engines share processing time in a fair way, but cannot do that with cache. If one engine trashes the cache, the other engine will slow down.
Accessing tablebases is another word for trashing cache.

Solution: Ponder off.

Tony

[Werner]

It's not a new problem.

You can make engines share processing time in a fair way, but cannot do that with cache. If one engine trashes the cache, the other engine will slow down.
Accessing tablebases is another word for trashing cache.

Solution: Ponder off.

Tony

Hi Tony,
thanks for the reply. We only want to make eng-eng matches with ponder off. So do you think this happens only with Crafty smp as the engine does starting to ponder when tb-aceess occure??

[Denis P. Mendoza]

Since EGTB is just an add-on on engine matches, you could just use 3-4 men (or 5-men) at the minimum or no EGTB access at all, or whatever is tolerable to avoid such conditions you mentioned. It's just a wise suggestion.

[bob]

Hi all,
as this new problem is not easy to find between the long thread I will repeat it here:
Charles found out:

I tried running a match against Bright 0.2c 2CPU under Arena 1.1 and Arena 1.99beta5. Everything is okay until Crafty starts using egtbs. Then Bright uses only 50% CPU power and slows down to a crawl. One game Bright even forfeited on time which has never happened before.

I have the same problem against other dual engines. To show what happens I made a picture:
http://www.husvankempen.de/nunn/crafty_22_0.JPG

Naum is normally here running more than 2000 kns - now only 74!!
This happens in every GUI so on a dual you cannot play eng-eng matches against another dual engine.

I do not understand what you are explaining.

In Crafty, using mt=2 (current version) and ponder=off, crafty will use 100% of both processors while it is thinking, and it will not use any processor time while it is waiting on the opponent. Endgame tables do not affect this in any way. So I don't follow that.

If the opponent uses endgame tables, it is very possible that the opponent will slow _way_ down in endgames (as will Crafty) when endgame table probes are being done, because I/O is far slower than processor execution cycle time...

So somehow, I don't understand the problem you are trying to report... because Crafty simply does not do anything while it is waiting on the opponent.

I suppose if you make the egtb cache big enough, while crafty is running it might cause the other process to be swapped out of memory, so that when that process starts to run, it takes some time to get it back in, but that isn't a crafty bug, it is an excessive hash/hashp/egtbcache overall size problem that is user-controlled...

[bob]

It's not a new problem.

You can make engines share processing time in a fair way, but cannot do that with cache. If one engine trashes the cache, the other engine will slow down.
Accessing tablebases is another word for trashing cache.

Solution: Ponder off.

Tony

Hi Tony,
thanks for the reply. We only want to make eng-eng matches with ponder off. So do you think this happens only with Crafty smp as the engine does starting to ponder when tb-aceess occure??

Nope. If I were guessing, I would guess you have an excessively large endgame table cache size. If you have N megabytes of free memory after booting your system, you must make certain that this formula holds:

sizeof (crafty code + static data + pawn hash table + regular hash table + endgame cache) + sizeof (opponent code + static data + whatever hash tables it uses + endgame table cache) < M. If you violate that you are going to cause paging I/O that will kill performance for _both_ programs...

[Werner]

Hi Bob,
thanks for the answer, but I am sorry it doesn´t help.
As you see in the other thread, Charles reportet this problem when watching a game against Bright 0.2c 2CPU under Arena. All was ok till Crafty did tb hits - suddenly now Crafty uses again 1CPU when idle and slows opponent down (before all was ok!!). So I constructed such an endgame and watched Taskmanager too. I could see the same behaviour using Naum 3 2CPU.

TBs cache is very low:
cache=32M

System hat 4 GB RAM - in my tests the engines had only 256 MB hash!

And its not the normal slowdown of a program when using tbs. I tested Naum 3 in that position of course allone loaded - it made around 2600 kns.

As a result of this, I will test Crafty SMP only against single engines on a dual system and against dual engines on a Quad - the same I did with version 21.6

[Tony]

It's not a new problem.

You can make engines share processing time in a fair way, but cannot do that with cache. If one engine trashes the cache, the other engine will slow down.
Accessing tablebases is another word for trashing cache.

Solution: Ponder off.

Tony

Hi Tony,
thanks for the reply. We only want to make eng-eng matches with ponder off. So do you think this happens only with Crafty smp as the engine does starting to ponder when tb-aceess occure??

Nope. If I were guessing, I would guess you have an excessively large endgame table cache size. If you have N megabytes of free memory after booting your system, you must make certain that this formula holds:

sizeof (crafty code + static data + pawn hash table + regular hash table + endgame cache) + sizeof (opponent code + static data + whatever hash tables it uses + endgame table cache) < M. If you violate that you are going to cause paging I/O that will kill performance for _both_ programs...

I assumed (and actually, it still sounds like) Crafty was pondering.

Check the taskmanager to check if it uses cpu. If not then something strange is going on. ie
Even blowing out the cache (during thinking and then stop) should be solved in a few secs.

Tony

[bob]

Hi Bob,
thanks for the answer, but I am sorry it doesn´t help.
As you see in the other thread, Charles reportet this problem when watching a game against Bright 0.2c 2CPU under Arena. All was ok till Crafty did tb hits - suddenly now Crafty uses again 1CPU when idle and slows opponent down (before all was ok!!). So I constructed such an endgame and watched Taskmanager too. I could see the same behaviour using Naum 3 2CPU.

TBs cache is very low:
cache=32M

System hat 4 GB RAM - in my tests the engines had only 256 MB hash!

And its not the normal slowdown of a program when using tbs. I tested Naum 3 in that position of course allone loaded - it made around 2600 kns.

As a result of this, I will test Crafty SMP only against single engines on a dual system and against dual engines on a Quad - the same I did with version 21.6

All I can say is that I don't do anything inside Crafty that can cause that. Endgame table probes are still done inside the search. The search (smp or non-smp) behaves _exactly_ the same with or without endgame tables. If you have ponder=off, I don't see how crafty can be sitting idle waiting on the opponent and still use any CPU time.

I am running test games right now, but so far I can't reproduce any bad behavior at all, but I am trying... If you are saying that removing the egtb/tbpath stuff from the crafty.rc file makes things work correctly, that appears to be impossible from the code I am looking at. The only place egtb's are probed are inside the search, which is started/stopped the same way whether egtbs are used or not...