Some problems

• Tried to plug in new optimum parameters for 6 different kernels after grid search
• Parameters should be optimal for 50kHz IR
• Turns out it sync time is almost 7% slower with new parameters
• In grid search, kernels measured individually using rocprof
• In overall evaluation, total sync and async time considered
• Maybe there are hidden slowdowns which have not been measured during the grid search?
• I will measure kernel durations to see which one is slower w.r.t. data taken during the grid search
• In case try to do individual grid searches and see if optimal parameters change
• In case try to find another way to measure kernel durations instead of using ROCM profiler

Idea for a more efficient grid search:

1. Apply a Latin Hypercube Sampling
   
   1. Divide each dimension of the search space in M intervals (bins)
   2. Sample N points s.t. each interval (bin) has only one sample point
      
      
      
   3. This way the search space should be explored evenly
2. Select the configuration with the best result
3. Recursively apply LHS in a more fine-grained search space around that sample

Important question

Should I try this type of optimisation or should I just try to apply a known external optimsation framework and somehow adapt it to this problem?

Main concern

• SliceTracker step has 8 main kernels, 16 parameters --> 16 dimension search space (w.r.t. 2 dimension of independent kernels)
• Each time 15 minutes are taken to compile the standalone benchmark to evaluate a sample point in the search space
• Will this euristic be enough to have feasible runtime of the search space?
• External frameworks might be faster?

Other questions

• In GPUDefGPUParameters.h kernel parameters are defined like that:
  • #define GPUCA_LB_GPUTPCCompressionKernels_step0attached 192, 2 where 192 is block_size and grid_size is 2 * Available Compute Units

    How can I define a grid_size which is not multiple of Compute Units?
• How compression mode is selected? When doing grid search, I get this result from step 0 of compression kernels:
  
  The problem arises becuase the default configuration, i.e. the dashed cell, is 1.3 slower than the same configuration outside the grid search. This problem arises only for this kernel. I suspect that the compression mode is changed, may it be true? For comparison, with another kernel:
  
  Here default configuration is correctly around 1