Repository navigation
[RF] Plot the cost per likelihood eval and event in benchRooFitBackends - #316
Merged
Merged
Conversation
The speedup relative to the single-threaded CPU backend depends on the
CPU in ways that the plot can't show: on a Zen 2 CPU, the Gaussian
resolution models are much slower on the CPU than on Zen 3 because of a
slow libm erfc, which inflates their CUDA speedup. The plot therefore now
shows absolute numbers:
* The quantity is the fit time divided by the number of likelihood
evaluations and the number of events, in ns. This removes the large
differences in fit time between the models and between runs with
different numbers of events.
* A dot plot on a fixed logarithmic axis, one row per model and one
marker per backend, with a line spanning the backends. The speedups
are the distances between the markers.
* Fits that did not converge are marked.
* --compare overlays a second run with hollow markers, e.g. from another
machine, and the run information table shows both runs.
The Gamma component of FitModel (mean 9, width 2.2) was nearly identical to the broad Gaussian (mean 10, width 2), so their yields were almost degenerate, and the yield ranges up to 1e9 and 1e10 put the start values of the fit 1e7 to 1e8 events away from the truth. Migrad often failed to converge: at 1M events with the fixed seed on all backends, and for most random seeds. The Gamma component is now a shoulder at low x (mean 3), and the yield ranges go up to ten times the number of events. With this, the fit converges for all tested seeds at 100k and 1M events, the fitted yields are within a few percent of the truth, and all backends do the same number of likelihood evaluations.
Without an offset, Migrad fails to reach the required EDM for the FitModel benchmark from a few million events on (status -1 at 3M and 10M events, on all backends), because the rounding errors of the large absolute NLL values spoil the numerical gradients. Offsetting the likelihood by its initial value is what should be done for large datasets anyway, and it doesn't change the cost per likelihood evaluation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The speedup relative to the single-threaded CPU backend depends on the CPU in ways that the plot can't show: on a Zen 2 CPU, the Gaussian resolution models are much slower on the CPU than on Zen 3 because of a slow libm erfc, which inflates their CUDA speedup. The plot therefore now shows absolute numbers: