Add a SplitKernels example

[hageboeck]

• New example based on example 18
• Discrete interactions moved to dedicated kernels for tests, profiling and R&D

@bernhardmgruber

[phsft-bot]

Can one of the admins verify this patch?

[hahnjo]

Can we call this example19, please, following the existing naming scheme?

[bernhardmgruber]

Can we call this example19, please, following the existing naming scheme?

We purposely chose something different and there is precedence for it with ECS, FisherPrice_*, Raytracer_Benchmark, TestEm3, etc. It is also different compared to the other examples, which seem rather finished, in that we want to continuously apply patches and improvements to SplitKernels. We want a playground for fast evolution.

And generally, the name example19 does not carry any semantic meaning. It is already confusing enough that many other examples also carry no names indicating what they do, and they also not necessarily share a chronology. I would even propose to rename the existing examples as well so they include names like Geant4_integration or standalone, etc.

[hahnjo]

example19 is the naming scheme for the next example, and I'd like to ask that you follow that. What would you do if you have another idea, to implement on top of split kernels? Creating a new example20 or whatever the number will be is easy and cheap.

[bernhardmgruber]

example19 is the naming scheme for the next example, and I'd like to ask that you follow that.

As I pointed out, it is not the naming scheme for all examples. And IMO it is also not a great naming scheme.

What would you do if you have another idea, to implement on top of split kernels?

Easy, if the change is strictly better we change SplitKernels. If it is a variant that is not better, like a compacted or double buffered version, we can name it e.g. SplitKernels_compact. We also have precedence for that with TestEm3 and TestEm3Compact, which are definitely better names than exampleX.

[hahnjo]

As I pointed out, it is not the naming scheme for all examples.

Yes, and as I pointed out in the past, this was not supposed to happen.

[bernhardmgruber]

Can we call this example19, please, following the existing naming scheme?

By now I don't care anymore whether this is called SplitKernels or example19. I would just really like to see it merged.

@hahnjo, @hageboeck and me would like to continue to work on that example and merge multiple PRs on top, including very experimental changes. So it is important for us to have freedom in that example.

[hahnjo]

I stand by my previous comments:

1. This should be called example19, following the established naming scheme. If there are smaller tweaks to the example maintaining the workflow, they can be done in this example in follow-up PRs. For bigger changes, just add a new example.
2. IMO at least the default batch size should be adjusted to provide comparable results to the existing examples (on second thought, I don't care so much about the capacity, but right now these two are linked).
3. The arbitrary choices in the launch configurations for the split kernels should take the number of particles currently in flight into account. For an easy start, I suggested just defaulting to transportBlocks.

[hageboeck]

I stand by my previous comments:

1. This should be called example19, following the established naming scheme. If there are smaller tweaks to the example maintaining the workflow, they can be done in this example in follow-up PRs. For bigger changes, just add a new example.
2. IMO at least the default batch size should be adjusted to provide comparable results to the existing examples (on second thought, I don't care so much about the capacity, but right now these two are linked).
3. The arbitrary choices in the launch configurations for the split kernels should take the number of particles currently in flight into account. For an easy start, I suggested just defaulting to transportBlocks.

I believe all of the above are addressed now. @bernhardmgruber @hahnjo
For the batch sizes I went for 52 in the end, as that's what example18 would do by default.

[hahnjo]

Looks good from a code point of view; some minor last comments inline.

FWIW here are the results for -particles 10000 (10k) on my RTX 2070 SUPER:

	example18	example19
-batch 52 (default)	102s	117s
-batch 209	54.6s	63.8s
-batch 419	45.5s	49.5s

[hahnjo]

From #203 (comment)

Another approach (that I think we had in the past? not sure) is having queues for the discrete processes. That would even save us from determining which Track need to run in which of the (split) kernels.

I gave this a try, and it seems to be equivalent in terms of performance but we don't need that awfully templated InteractionLoop. Let me know if you want me to submit this as a PR...