You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nearly all of the runtime (> 90%) now gets spent in ranking move candidates. This is because we currently rank move candidates based on the BIC score we get after performing the move and optimizing the 1-neighborhood of the branches affected by the move. This can be seen in this call graph:
We are only interested in the best-ranking move candidate, as this is the one we will apply.
This focuses all optimization efforts on the candidate ranking. Ideas:
Filter the candidates to rank by doing a fast pre-ranking before the actual ranking (-> optimize even less branches? use some pseudo-likelihood function?).
Parallelize the ranking of move candidates.
The text was updated successfully, but these errors were encountered:
Nearly all of the runtime (> 90%) now gets spent in ranking move candidates. This is because we currently rank move candidates based on the BIC score we get after performing the move and optimizing the 1-neighborhood of the branches affected by the move. This can be seen in this call graph:
We are only interested in the best-ranking move candidate, as this is the one we will apply.
This focuses all optimization efforts on the candidate ranking. Ideas:
The text was updated successfully, but these errors were encountered: