Status: Resolved (View Workflow)
Affects Version/s: master
Fix Version/s: None
Component/s: Core Libraries
This was initially observed on ROOT 6.18.0 but is still true as of the current ROOT master (commit 14de58de35eff907054671888ccc2de0f7f27e77 from November 14).
The issue is not operating system nor hardware dependent as it lies in the C++ source code.
ROOT 6 histogram use a column-major binning convention, i.e. the statistical data for bin (i, j, k) is close to the statistical data for bin (i+1, j, k). This can be checked in the code source of e.g. TH2::Fill() and TH2::GetBin().
For RHist, there is a temptation to use a row-major binning convention, i.e. the statistical data for bin (i, j, k) is close to the statistical data for bin (i, j, k+1). The rationale here is that row-major binning is more consistent with the way loops are traditionally written in C-like languages:
Nonetheless, this Jira issue pleas for resisting the temptation and sticking with a column-major ordering in ROOT 7 on the ground that...
- Using opposite binning conventions will greatly pessimize the memory transfer performance of ROOT 7 -> ROOT 6 histogram conversions, which are expected to be frequently performed during the ROOT 6 to ROOT 7 transition period.
- If ROOT 6 trained users for years to believe that iterating on the first histogram index is faster, then it is not a good idea to disturb their looping habits.
- We probably don't even want people to write loops on local RHist bin indices by hand, since RHistBinIter is a thing, and if users don't write the bin iteration loop themselves then our choice of local bin ordering is not part of the public API and can be whatever suits our needs best (ideally it can even be changed later without users noticing).