search

kokkos / kokkos-kernels

Kokkos C++ Performance Portability Programming Ecosystem: Math Kernels - Provides BLAS, Sparse BLAS and Graph Kernels
Other
304 stars 96 forks source link

Maintain "approved" Kokkos version as a submodule of Kokkos Kernels? #1364

Closed jgfouca closed 1 year ago

jgfouca commented 2 years ago

I am a new developer on Kokkos Kernels (KK), so forgive me if I am ignorant about KK's development practices. I recently attempted a medium-term ( on the order of a few months) ) git bisection of a minor problem in KK and my efforts were stymied by my KK repo falling out of sync with Kokkos installation as I went further back in the KK commit history. This raised a question: how do I know what version of Kokkos I should build my KK against? My sense is that we expect the HEAD of the develop branch of KK to work with the HEAD of the develop branch of Kokkos at any point in time, but I have seen this not be the case already in my short time on KK. If I go back to KK develop merge commit that happened on MM/DD/YYYY, I can try to checkout a Kokkos develop commit around the same time, but this is cumbersome and difficult to automate.

I'm wondering if we should be more explicit about what version of Kokkos should be used for KK by maintaining this approved version of Kokkos as a submodule of KK? We could frequently update this version (weekly?) but would make sure that the update had at least passed some basic testing first. KK developers would be under no obligation to use this submodule and we would still be free to use any Kokkos_ROOT we want in our cmake commands.

lucbv commented 2 years ago

In general we strive to have Kokkos Core and Kokkos Kernels both work with the head of their respective develop. To that end we have eliminated dependencies in Kokkos Kernels on impl files from Kokkos Core and are striving to only use the public interface provided. However both projects are working on new features that are sometimes dependent on each other and this can lead to failures in Kokkos Kernels. There is not much that can be done except trying to resolve these as they come.

If others want to add to this response feel free to do so. I am pinging @dalg24 here as he probably has an opinion on this.

jgfouca commented 2 years ago

@lucbv , yes, I understand that is the current approach. I made this issue because I'm wondering if that's sufficient for our needs, specifically regarding git bisection. There are probably other use cases in which developers might want to go significantly far back in KK's commit history.

lucbv commented 1 year ago

Reading old issues before the end of the year so I see we did not fully finish this conversation. Here is the approach I recommend:

  1. do a coarse grain dissection that only works on release commit to find within which release cycle the error is introduce. During this coarse dissection you need to checkout both Kokkos Core and Kokkos Kernels
  2. start an automated dissection with the release cycle to find the bug

It is a bit slower than a fully automated dissection but there is really no good way around this and sub-module is a big no in my opinion.