An Algorithm to Parallelise Parton Showers on a GPU

Dear Editor and Referees,

Apologies for the delayed update, but we have now submitted the updated paper. We have addressed the referees' queries and concerns (see list of changes). We hope you find these changes suitable for your concerns. Please don't hesitate to contact us for further clarifications/concerns.

Thanks!
The Authors

1. While making the revisions, we discovered a minor physics bug in the code. After fixing the bug, we observed minor changes to the speedups (the Parton Shower Speedup went from 260 to 295). This has NOT affected any of our findings or theory; it is just a change in the number in the manuscript.

2. Revamped the Algorithm Section: After learning more about GPUs over the last few months, we have written a more accurate explanation of why the algorithm works and how it differs from a multi-core simulation (based on the feedback by referee 1). We hope that it now clearly explains why this is a novel approach. To further avoid any confusion, we've removed the use of the word 'simultaneously' and replaced it with the more coherent 'in parallel'.

3. We Added comments about future implementation and relevance to production-ready showers in the conclusion section.

4. Added a few references - One Paper in the intro ([2]) and GPU Histogramming References

5. Updated the Execution Time Slide - Added vertical line where the number of events = number of cores of the GPU, which helps explain the increase in runtime

6. Addressed Comments by Dr. Delsart:

- Figure 2 & annexe : For non experts, it is not immediately obvious what exactly is calculated as part of one parallel flow ( i.e. horizontal arrow connected boxes) : is it the successive emissions from 1 parton or all the emissions in one collision event. Simply stating it explicitely, ex as part of the caption of fig 2, would ease the reading. - ADDED A FEW SENTENCES TO FIGURE 2, AS WELL AS TO FIGURE 1 TO EXPLAIN BETTER

- Figure 4 : the variables are not described. It would be good to give a description, even if very brief and an explanation of why they are relevant w.r.t. simpler variable such as pT or rapidity. - DONE

- figure 7 : Is the following interpretation correct : at cycle=80 we have 95% of events done but we need to wait 40 more cycle (That is 50% time more) for the parton shower step to end and move to observable calculation ? If so, is this (=waiting 50% longer for 5% of events) an intrinsic limitation of using GPUs ? if so this is an interesting point I would suggest is made in the article. - ADDED COMMENTS EXPLAINING CYCLE != TIME, AND TALKED MORE ABOUT THEIR RELATION

- Annexes : the pseudo-code are generally useful as they convey well the general ideas of the algs. There are a few confusing points which could be clarified :

* the is the parton_list in the 1st example a dynamic list owned by each thread ? Is it populated by the line "new parton(...)" in the 2nd example ? - ADDED COMMENTS TO CODE

* what is the "DeviceToHost" at the end of annex B ? - ADDED COMMENTS TO EXPLAIN THIS

* there is multiple reference to "events [ idx ]. endShower" but it is nt very clear at which point in the examples this could be set to True ? - ADDED COMMENTS IN A FEW SECTIONS TO EXPLAIN