GlobalEntryRange assumes single threaded run in RNTupleDS

[GeorgiLH]

Explain what you would like to see improved and how.

When using GlobalEntryRange from RNTupleDS it assumes that the run is single threaded or that is what is written as a comment in the header file. More specifically it assumes that there are less slots than open files. Is that a conscious decision to avoid some sort of issues? I have a local implementation which seems to work. Wanted to get some more info on the matter before opening a PR for the changes.

ROOT version

6.40

Installation method

built from source

Operating system

Linux (Ubuntu 24.04.4)

Additional context

No response

[vepadulano]

Dear @GeorgiLH ,

Thanks for reaching out! I'm not sure I follow what you mean, could you provide a reproducer of the issue you are describing?

[GeorgiLH]

@vepadulano Thanks for the quick reply!

Restating the problem

The problem arises when using an RDataFrame made from an RNTuple with an entry range. This can be done with a RDataSetSpec or an internal overload of an RDataFrame constructor(the result is the same as far as I can tell). When any action is executed on the RDataFrame with IMT enabled the RNTupleDS responsible for the entry ranges assigns one range (and that subsequently leads to one thread/slot) per file, regardless of the actual number of files or the number of slots. I had the case where there was a Filter and a Count on a single file with IMT enabled and rather than the 16 threads I was expecting it only used one. There is a comment in the RNTupleDS.hxx header about this exact behaviour(line 43):

The event range will be respected when processing this RNTuple.It is assumed that processing happens within one thread only.

Here is the line of code which ensures this functionality(RNTupleDS.cxx:567):

if ((nRemainingFiles >= fNSlots) || (fGlobalEntryRange.has_value()))

My question is whether this was done as a design decision or as a temporary measure?
I already have some local changes which enable multiple ranges on one file with entry range that I have tested with a single file and seem to work normally but wanted some confirmation on the issue before opening a PR.

Reproducer

To the best of my knowledge this happens regardless of the type of action performed on the RDataFrame since all of them need entry ranges to operate.
Here is a simple reproducer which leads to the stated outcome:

int main(){
ROOT::EnableImplicitMT(threadCount);
std::vector<std::string> files = {file};

auto df = ROOT::Internal::RDF::FromRNTuple(rnt_name, files, range);
auto count = df.Filter([](int32_t data){return data>= 20;}, {"colname"}).Count();

std::cout << *count << '\n';
return 0;
}

[vepadulano]

Dear @GeorgiLH ,

Yes I understand what you meant, I asked explicitly for a reproducer because I was not aware of any way for the user to achieve the scenario you described. Thanks for confirming: since your reproducer uses an Internal method, it's invalid.

Nonetheless, you are not wrong about the assumption that is made when there is a global entry range. There is no particular reason for that assumption, other than a missing motivating use case so far. ROOT welcomes external contributions and since you mention having a local branch that improves the current implementation, feel free to open a PR, I will be happy to review it.

[GeorgiLH]

@vepadulano I also tested this with an RDatasetSpec with one sample from one file and the same aoutcome is observed.

[GeorgiLH]

As far as the motivating use case, I think using the the GlobalEntryRange is the only way to effectively make use of a range in a multithreaded context when using RDataFrame. If there is an alternative I would be glad to know of it.

[GeorgiLH]

@vepadulano Here is a valid reproducer using the experimental RDatasetSpec:

 int main(){
ROOT::EnableImplicitMT(threadCount);
ROOT::RDF::Experimental::RDatasetSpec spec;
ROOT::RDF::Experimental::RSample sample("test_name", "RNTupleName", "file_name");
spec.AddSample(sample);
spec.WithGlobalRange({start, end});

auto df = ROOT::RDataFrame(spec);
auto count = df.Filter([](int32_t data){return data>= 20;}, {"colname"}).Count();

std::cout << *count << '\n';
return 0;
}

As long as Experimental is allowed in reproducers this should be acceptable and leads to the same result of only using one thread regardless of the IMT. This and the previous reproducer are the only methods of setting an entry range on an RDataFrame with multithreading on as far as I can tell(I have only checked with RNTuples). Also is there somewhere where I can check what isn't and is allowed for reproducers in order to avoid any mistakes in the future.

[GeorgiLH]

@vgvassilev

[vepadulano]

Dear @GeorgiLH ,

Thanks for the reproducer, that is public API so indeed it's valid. I'll try to reproduce this myself and then look at your PR, thanks for contributing!