master_june24: missing sanity checks that all channelids are the same in a "warp" (or at least inside each SIMD vector)

[valassi]

Another issue introduced in#830 and being reviewed in #882

This is related to (almost a sub-component of) the SIMD issue #894 but I prefer to address it separately.

As clarified during the meeting today and #894 (comment) (thanks @roiser), the cudacpp implementation should assume that all channelids are the same in a warp. To avoid all unexpected behaviour due to hidden assumption, a sanity check (an asser essentially is needed). I think we had discussed this in the past, maybe I will dig that out. Anyway, this is a prerequisite to simplifying the SIMD implementation.

I file this as a separate issue also because it may be appropriate to expose these assumptions in the fortan-cudacpp bridge, so that they have the same assumptions. (Example: warp_size can be modified in the runcard, there must be a sanity check on allowed values).

[valassi]

PS On second thought, what I will do is add a sanity check that channelids are all the same inside a SIMD vector. For GPUs, this is not strictly necessary: the implementation can be made to be functional anyway, but it will be slower.

Example. Take hardware SIMD vectors of 4 elements and hardware GPU warps of 32 threads. If every channelid is different for those elements, then:

• the GPU implementation will give correct results anyway (the channelid of each thread is only accesses in each thread), but there will be a (small) thread divergence
• the SIMD implementation in master_june24: wrong/bugged and unnecessary SIMD handling of numerators and denominators  #894, conversely, must know this in advance: if it can assume 4 equa channelids, SIMD vectors can be used, otherwise explicit loops must be used... but this must be known at the time of writing the code...

[valassi]

Small complication/question: for mixed fptype the check must ensure that TWO double vectors have the same channelId? Or probably not, I must check.

[valassi]

Small complication/question: for mixed fptype the check must ensure that TWO double vectors have the same channelId? Or probably not, I must check.

As discussed in #892 (comment), I am moving to an implementation where calculate_wavefunction and sigmaKin have two differenbt interfaces, in line with what they do

• calaculate_wavefunctions manages a single SIMD vector or single event, which all have a same calar channelId
• sigmaKin does the loops over SIMD vectors and decodes channelids, and implements the check described here

With respect to FPTYPE=m, the point to notice is the following, eg take avx2 with 8 floats and 4 doubles

• sigmakin does a loop over float vectors, so it checks that 8 events have the same channelid
• calculatewavefunction then loops (iParity loop) over two double vectors (first 4 events, then another 4 events)
• the single scalar channelid that sigmakin passes to calculate_wavefunctions is valid for 8 events, ie for both double vectors... and a single channelid argument is enough, again

[valassi]

NB: the complication here is that uint_v has 4 ints, while there is the need to check 8 ints, so probably this needs to be done with two separate vectors. I will check...

[oliviermattelaer]

Concerning:

Small complication/question: for mixed fptype the check must ensure that TWO double vectors have the same channelId? Or probably not, I must check.

I do not see any problem if the two vector will have different channelID in the "m" type. On the contrary it is better to have different one. The point is that the color computation (only part done in float) does not depend of the channelId.
So they are no penalty to have different ChannelID here, and since the more flipping of value we have in channelID, the better it is to avoid potential bias ...

Obviously in that case, you can not have "nb_warp" set to 1 but this is the only limitation.
So I would say that we do not need dedicated check for the "m" case and on the contrary allow for two different value here.