Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split the sigmakin kernel into smaller kernels #310

Open
valassi opened this issue Dec 9, 2021 · 4 comments
Open

Split the sigmakin kernel into smaller kernels #310

valassi opened this issue Dec 9, 2021 · 4 comments

Comments

@valassi
Copy link
Member

valassi commented Dec 9, 2021

This is just a placeholder to discuss the idea of implementing smaller kernels.

A lot of pointers already exist related to this:

One of the main points towards using smaller kernels is the need to allow each ixx/oxxx and each ffv function to handle pointers to large buffers for many events and to do the indexing themselves. This is discussed in #175 (comment) for instance. Presently instead only the ixx/oxx functions are able to find an event in the input array, but then their output (and all inputs/outputs of the ffv functions) refer for CUDA to a single event. This is the first thing that must be changed to allow smaller kernels.

@valassi
Copy link
Member Author

valassi commented Dec 11, 2021

Note a basic prototype idea in #313: it would be enough to add for instance bufferAccessWavefunction( fptype* buffer, int iw6 ) wherethe iw6 index is passed in the same way as the ip4 now.

@valassi
Copy link
Member Author

valassi commented Jan 20, 2022

Note that PR #328 is the first step for this and contains several comments related to this

@valassi
Copy link
Member Author

valassi commented Feb 3, 2022

The color algebra optimisation has a separate issue #155. Improving the timing measurements is in #372.

@valassi
Copy link
Member Author

valassi commented Apr 22, 2022

One of the main issues in splitting kernels is the clarification of the relative roles of MEK and CPPProcess: who holds intermediate data buffers? who orchestrates the order of kernels? who is allowed to have process specific stuff? I am discussing this largely in #356, specifically in the econtxt of running alphas issue #373 and draft PR #434

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant