Optimization of fillArray code

[pgranger23]

Summary

Proposed optimization of the fillArray code. As the used data structure relies on Structure of Arrays (SoA), it is more efficient to apply all the operations, one after the other, to all the events at the same time rather than looping on the events to apply those operations. Also avoids the need to make string comparisons on each event loop.

Interface changes

• The definition of a virtual double* ReturnKinematicParameter(std::string KinematicParamter, int iSample) = 0; function is required for all the experiments in order to return a pointer to the relevant array to use as Kinematic Parameter. Note that this requires the KineMaticParameters to be of type double.
• The fillArray_MP and fillArray functions have been merged. I think it is better for future maintenance to have a single function to deal with and not 2 alternative versions.

Performance improvements

The following performance improvements have been witnessed with these changes. The relevant points to compare here are the red and blue ones. These performances have been obtained on the DUNE FD sample, with the GCC compiler and the use of --march=native compiler flag.

Things to verify

Here are the items that should be verified before the possible approval of this PR:

• Verification that it exactly reproduces the results from the previous code.
• Check that the use of the #pragma omp commands are never an issue, even when not compiling with multi-processing
• Check that this in fact leads to performance improvements for different samples

[KSkwarczynski]

About your comment Check that the use of the #pragma omp commands are never an issue, even when not compiling with multi-processing

Usually what we do is wrap pragma around preprocessor

#ifdef MULTITHREAD
#pragma omp parallel for
#endif

All multithreading flags etc. are ste here https://github.com/mach3-software/MaCh3/blob/82d1fec9ab8db6597053d78eb7b383dd29b30400/CMakeLists.txt#L196

[dbarrow257]

Not that I expect a large change in RAM based on the changes I can see - but it would be good to check that the RAM usage has not significantly expanded in the new approach. In the short/mid term, the RAM usage is still somewhat important for pushing as many chains onto as few nodes as possible.