Shouldn't dual socket motherboard function the same as two systems linked together, the latter have to transfer move information back-and-forth, which cause some latency and has to be accounted for.
With dual xeon, each engine get allocated one xeon for whole match.
> With dual xeon, each engine get allocated one xeon for whole match.
That does not happen in practice. Non- NUMA aware engines can have resources across both CPUs and NUMA aware engines have to be manually allocated which CPU to use otherwise they take resources from CPU_0. That is OK if they are first to kick in but if they are second then If NUMA aware engines are left at default they can interfere with other engines and the worst I have seen was asmFish and Houdini 6 Pro running with default settings when asmFish kN/s was down around 10% and Houdini's was anywhere between 3500 and 10500 kN's. Therefore in ponder on tournaments NUMA aware engines should be used with NUMA awareness switched off. Unless the engine is running singularly and being given full resources when there is measurable benefit. Running a two engine match should not be an issue when each engine can be allocated one CPU for the duration of the match. However if you want to compare results then the same conditions should be used.
The assumption that a NUMA aware engine runs faster under any condition is not correct when I measured Houdini 6 with 6 cores running slighly slower with NUMA aware than with it disabled. However with all cores allocated it was approximately 4.8% faster with NUMA aware enabled.
I ran some two core ponder on and 4 core ponder off games on my old quad to try and identify if there were any noticeable issues but could not identify anything specific. I am already considering my next machine will be single CPU. Less fiddly!
Mark Lefler's theory is that TCEC shouldn't necessary be worse off with 22-core ponder on than 44-core ponder off, assuming ponder hit rate of 70%. All of which sounds reasonable.
> So there shouldn't be any problems when running ponder on dual xeon, if engines does not support NUMA?
That's right and also for NUMA aware engines with NUMA turned off. In the case of Houdini, if NA is disabled and LP hash is disabled then it is probably simpler to run with the standard engine. asmFish will still benefit from the assembly code speed up over the C coded engine.
> Mark Lefler's theory is that TCEC shouldn't necessary be worse off with 22-core ponder on than 44-core ponder off, assuming ponder hit rate of 70%. All of which sounds reasonable.
I wouldn't disagree but I would say with 60% ponder hit rate although that is a bit sketchy because some engines seem better at predicting opponent's move than others and it is very difficult to measure an accurate value. Core efficiency should also be considered that may be Mark's benchmark but time gained through a ponder hit is much more significant than stored positions in hash of ponder = off. Unclear how that could be measured. It is my opinion that the important consideration is to ensure sufficient hash is allocated to give a fill rate of around 30 to 50% on average. That way not all is lost by overwriting entries upon a ponder miss and for a ponder hit the engine has gained significant time and possibly deeper analysis.
16384 Gb hash may seem large but considering Houdini will show over 90% fill rate in just over 4 minutes for 32 Gb hash on my dual Xeon, it would suggest in TCEC engines are not running with optimised hash values.
I have stayed with ponder = on migrating from using two machines to the dual Xeon machine 4 years ago and still currently use for most of the games I run.
There is one contentious point for purists though and that comes with tablebase access when with ponder = on both engines are trying to access the same bases and the question then arises as to whether or not there is equal proportionment of access.
Ponder = on increase hash-moves, although ponder hit doesn't always mean it triggers hash-move (insta move)
> hash-moves doesn't happen too often if ponder hit on ponder = disabled. Usually engine continue thinking but often much less than ponder miss.
A ponder (opponents move prediction) hit is just as likely with ponder = off as ponder = on. Engines do not clear hash with ponder = off therefore a ponder hit (as in correct prediction of opponents move) will benefit an engine significantly from retained information in hash
There are two uses of Ponder here ...
1. Ponder hit or miss i.e. engine correctly or incorrectly predicted opponents move.
2. Ponder function i.e. engine continues analysing on opponents time based on pondered move opponent will likely play.
A ponder hit or miss is possible whether ponder function is on or off.
> Ponder = on increase hash-moves, although ponder hit doesn't always mean it triggers hash-move (insta move)
Once hash is full, as far as I am aware, hash entries are overwritten on an oldest first basis therefore the number of hash entries do not increase beyond a certain point i.e. hash=full. That is why I made the comment regarding sizing hash is important. Once overwriting begins there is less chance of transpositional information being overwritten on a ponder miss if hash is sized correctly. Of course the relevance of remaining hash information depends on how broad or narrow are the entries relating to the position at the time.
A ponder hit can trigger an instant move whether ponder function is on or off. A ponder hit may also cause an engine to use more time where it searches deeper and does not like its score or it finds a move requiring deeper analysis. An engine's behaviour with ponder = on is much more complex than perhaps seen on the surface.
There is also the situation where an engine cannot identify a suitable move for its opponent and gives just a half ply output. The engine stops analysing even with ponder = on because there is no ponder move to analyse.
Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill