Parallelize on histogram bins

ROOT
1

Dear PROOF experts,

Is there a way to get a unique event number when running the ProofSimple example?

I am trying to parallelize the computation of the value of each bin of a histogram with PROOF.
The values come from the computation of an integral done in the macro which depends only on the bin.
I tried to start from the ProofSimple example in /tutorials/proof and I am using root version 5.22/00a at CERN.

From my understanding the ProofSimple example when asked to fill N histograms with M random events, generates M slave processes each one filling one point in the N histogram and at the end merges them.

In my case I have only one histogram and I need each slave to compute a different bin. So I need a way to distinguish the bins.

I tried using the entry value passed to:
Bool_t ProofSimple::Process(Long64_t entry)
but it seems that some slaves share the same entry, so it is not a unique identifier.

Is there a simple way to get the event number I am in, so that I can use it to compute the bin?

Thank you in advance for any help!

2

Dear Demattia,

This is not quite correct. The number of worker (slave) processes is fixed to K by the configuration settings. Each of the K workers gets a fraction of the M events (approximately M/K, but not strictly that) and produces one copy of the N histograms. Finally the K copies of each histogram are merged to the set of N histograms.

For each assigned event, PROOF calls on the workers the Process(Long64_t entry) method of the TSelector implementation to run. The value of ‘entry’ is unique, so perhaps this is the unique identifier you are looking for.
For example, if you want to integrate on 1000 bins in parallel, you should implement your code in ‘myselector.C’ and run

   TProof::Process( "myselector.C",1000)

and inside myselector::Process(Long64_t j) you should evaluate your function for bin j.

Note that PROOF adds some overhead (creation and movement of objects, …), the thing may make sense only if the integrate computing time is large.

G. Ganis