Komodo 12.1

[lkaufman]

As you double the number of physical cores with MCTS do you double "search speed" (or whatever the right term is) or is there a mulithread penalty as with normal engines?

There is still a multithread penalty. That is why we limit threads to 12, since our testing indicates that beyond 12 adding more threads actually hurts slightly. We could have set a much higher limit, but we felt that would be dishonest. I expect we'll find a way to use more than 12 threads before too long.

[mjlef]

As you double the number of physical cores with MCTS do you double "search speed" (or whatever the right term is) or is there a mulithread penalty as with normal engines?

There is still a multithread penalty. That is why we limit threads to 12, since our testing indicates that beyond 12 adding more threads actually hurts slightly. We could have set a much higher limit, but we felt that would be dishonest. I expect we'll find a way to use more than 12 threads before too long.

MP never scales perfectly since more cores are fighting for access to memy, and memory speeds have not increased much compared to processor speeds. A perfect MCTS search is not possible in NO so very processors need to widen the tree more so they do not try to expand the same nodes. But overall scaling is pretty good.

[mjlef]

From Larry's post, it seems like the idea is to shift developmental emphasis from traditional search to MCTS. This worries me slightly. Standard Komodo is immensely strong, and runs well on laptops, slower hardware, etc. MCTS may not. I'd really hope that work continues on the standard engine, and with the new linkup with chess.com, perhaps now Komodo can have access to Fishtest-esque hardware needed to chase down new ideas and test them.

MCTS runs fine on my laptop. Anyway we'll continue to try new ideas in standard Komodo, but MCTS ideas get priority over just tweaking parameter values in standard Komodo.

Although we have concentrated on MCTS search the last several weeks, I promise we will work on regular search mode too. Regular search and evil improvements benefits both regular and MCTS search since we currently use shorts searches and Komodo's eval to estimate win probabilities.

[schack]

Evil improvements?

[Werewolf]

As you double the number of physical cores with MCTS do you double "search speed" (or whatever the right term is) or is there a mulithread penalty as with normal engines?

There is still a multithread penalty. That is why we limit threads to 12, since our testing indicates that beyond 12 adding more threads actually hurts slightly. We could have set a much higher limit, but we felt that would be dishonest. I expect we'll find a way to use more than 12 threads before too long.

MP never scales perfectly since more cores are fighting for access to memy, and memory speeds have not increased much compared to processor speeds. A perfect MCTS search is not possible in NO so very processors need to widen the tree more so they do not try to expand the same nodes. But overall scaling is pretty good.

Does it scale better than Lazy SMP?

[lkaufman]

There is still a multithread penalty. That is why we limit threads to 12, since our testing indicates that beyond 12 adding more threads actually hurts slightly. We could have set a much higher limit, but we felt that would be dishonest. I expect we'll find a way to use more than 12 threads before too long.

MP never scales perfectly since more cores are fighting for access to memy, and memory speeds have not increased much compared to processor speeds. A perfect MCTS search is not possible in NO so very processors need to widen the tree more so they do not try to expand the same nodes. But overall scaling is pretty good.

Does it scale better than Lazy SMP?

Maybe a bit better up to 12 cores. Apparently not beyond that.

[Werewolf]

MP never scales perfectly since more cores are fighting for access to memy, and memory speeds have not increased much compared to processor speeds. A perfect MCTS search is not possible in NO so very processors need to widen the tree more so they do not try to expand the same nodes. But overall scaling is pretty good.

Does it scale better than Lazy SMP?

Maybe a bit better up to 12 cores. Apparently not beyond that.

Oh. I thought one of the great hopes of this approach was its potential on massive hardware. If it doesn’t scale better than alpha beta >12 cores...the old way will always win as 12 cores will be increasingly common over the next few years.

[mjlef]

From Larry's post, it seems like the idea is to shift developmental emphasis from traditional search to MCTS. This worries me slightly. Standard Komodo is immensely strong, and runs well on laptops, slower hardware, etc. MCTS may not. I'd really hope that work continues on the standard engine, and with the new linkup with chess.com, perhaps now Komodo can have access to Fishtest-esque hardware needed to chase down new ideas and test them.

MCTS runs fine on my laptop. Anyway we'll continue to try new ideas in standard Komodo, but MCTS ideas get priority over just tweaking parameter values in standard Komodo.

Although we have concentrated on MCTS search the last several weeks, I promise we will work on regular search mode too. Regular search and eval improvements benefits both regular and MCTS search since we currently use shorts searches and Komodo's eval to estimate win probabilities.

[mjlef]

Does it scale better than Lazy SMP?

Maybe a bit better up to 12 cores. Apparently not beyond that.

Oh. I thought one of the great hopes of this approach was its potential on massive hardware. If it doesn’t scale better than alpha beta >12 cores...the old way will always win as 12 cores will be increasingly common over the next few years.

am pretty sure we can improve it on more cores. Testing with a lot of cores is hard because it takes a lot of time and we only have limited machines, especially above 24 cores.

[Ron Langeveld]

Oh. I thought one of the great hopes of this approach was its potential on massive hardware. If it doesn’t scale better than alpha beta >12 cores...the old way will always win as 12 cores will be increasingly common over the next few years.

Just a few posts back Larry did write "I expect we'll find a way to use more than 12 threads before too long."

I suggest you don't develop an accidental blindspot to free info by developers (in general) that tend to be reluctant with info on future versions. You may have misread it, but from where I am sitting I applaud the Komodo team for listening to customers and providing a significant enhancement within a couple of weeks. If you are one of the few Komodo customers with a core count that far exceeds the 12 core boundary for now than posts like this won't get any pity from me

Ron