CUDA Ico Backend Refactoring (Persistence, Encapsulation)

[mroethlin]

The encapsulation in the generated code for CUDA Ico is quite bad. The outer class does not properly wrap the inner class, and the driver needs to access the generated name of the stencil directly. This is quite cumbersome when the stencil is evolving since the id changes depending on the stencil structure. For this issue: Generate code closer to the unstructured naive interface, with proper forwarding to inner stencil classes

[mroethlin]

This is less pressing now because we offer various run_STENCILNAME wrappers now, which enable the driver to run the stencil without the need of holding a stencil object themselves. However, one problem this approach has is that the stencil object is not persistent in these run functions. This may impose severe performance penalties when the stencil needs to allocate fields in its constructor.

[mroethlin]

This may require more discussion after all. In our current scope, each stencil instantiation may only hold a single stencil. From a conceptual stand point wrapping the stencil is thus not necessary.

[mroethlin]

Further discussions revealed that we may want to introduce distinct setup and run functions. This would enable us to do clean timings further down the road, and ensure proper separation of concerns (the first call to run would otherwise need to allocate temp fields). It would be preferable if both setup and run functions return void s.t. we don't need to introduce a opaque c_ptr to be returned to FORTRAN, which then needs to be managed on the FORTRAN end. A current rough sketch how this might look like reads:

class stencil {
  static double *tmpField;
  static size_t size_;
public:
  stencil() {}
  static void setup(size_t size) {
  	size_ = size;
  	tmpField = new double[size];
  }
  void run() {
    for (size_t i = 0; i < size_; i++) {
      tmpField[i] = i;
    }
  }
};
void setup(size_t size) { stencil::setup(size); }
void run() { stencil().run(); }