OK, I compiled gnubg. It was not a pleasant experience. And the rollout time dropped from 2 min to 1:45.
So compiling helped only a little bit. This is probably what GNUBG is capable off, as this rollout at 2-ply cube decisions needs about 44M evaluations. People familiar with XG, how fast is its rollouts at this setting? What we really need is someone with access to some computing power (aka grid) to run a set of reference positions - 0-ply cube decisions vs 2-ply, and see what the difference is. That would give a hint as to what to do. -Joseph On Wed, 4 Dec 2019 at 12:53, Joseph Heled <[email protected]> wrote: > > Just for the record: 450924 evaluations/second. > > -Joseph > > On Wed, 4 Dec 2019 at 12:49, Joseph Heled <[email protected]> wrote: > > > > I set number of threads to 4 > > > > Rolled a cube decision > > > > world-class: 2-ply for move/cube-action : 18 minutes > > expert (0ply) moves/ 2-ply cube actions: 2 minutes. > > exper: 0 ply both 0.041 > > > > Still seems something is amiss. > > > > -Joseph > > > > On Wed, 4 Dec 2019 at 12:07, Philippe Michel <[email protected]> > > wrote: > > > > > > On Wed, Dec 04, 2019 at 09:46:09AM +1300, Joseph Heled wrote: > > > > > > > All I know is that I installed gnubg from the repository (GNU > > > > Backgammon 1.06.002) and the rollouts speed seemed terrible. > > > > > > > > Do I need to do something in the GUI to enable multi-threading? (and I > > > > hope that by multi-threading we are talking about multi-core, not just > > > > threading, which does not help) > > > > > > You may need to change the number of evaluation threads in the > > > Settings|Other window. The default is 1. > > > > > > This is really multi-threading, It is up to you to choose a number of > > > threads adapted to your processor. Maybe the number of cores, or that > > > number minus 1, or a fraction of that if you intent to run multiple > > > rollouts or 4-ply analyses in parallel. > > > > > > FWIW, I had the opportunity, at a previous job, to try to run gnubg on a > > > Knights Landing processor with 256 threads. It didn't run very > > > efficiently, maybe 100 times faster that with one thread, but it ran > > > without crashes or lock-ups or similar issues. > > >
