spirit icon indicating copy to clipboard operation
spirit copied to clipboard

Core: variadic templates for backend.

Open GPMueller opened this issue 4 years ago • 3 comments

The assign and reduce parallelisation functions can now handle arbitrary numbers of function arguments, which are forwarded to the lambda. Therefore, the lambda is now placed before the variadic arguments. Note that they can now also be called without arguments, allowing e.g. an assignment of zero to an entire field.

This PR is related to issue #529.

TODO:

  • [x] create variadic lambdas in backend and update usage
  • [ ] replace Vectormath and Manifoldmath with backend functions to get rid of the cuda files

GPMueller avatar Mar 28 '20 09:03 GPMueller

Coverage Status

Coverage remained the same at 79.423% when pulling 61da747c698dfb4bc47d47669e860a2ab407bb58 on feature-variadic-lambda into 55cc299074d9947a3838d47c31e41f1a1ea691ba on develop.

coveralls avatar Mar 28 '20 13:03 coveralls

Codecov Report

Merging #559 into develop will increase coverage by 0.21%. The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #559      +/-   ##
===========================================
+ Coverage    50.06%   50.27%   +0.21%     
===========================================
  Files           88       88              
  Lines        10136    10183      +47     
===========================================
+ Hits          5075     5120      +45     
- Misses        5061     5063       +2     

codecov[bot] avatar Apr 02 '20 08:04 codecov[bot]

Unfortunately, the extended lambdas in CUDA are more restricted than I thought, see https://docs.nvidia.com/cuda/cuda-c-programming-guide/#extended-lambda-restrictions

The main issue is this rule:

  1. If the enclosing function is a class member, then the following conditions must be satisfied:
  • All classes enclosing the member function must have a name.
  • The member function must not have private or protected access within its parent class.
  • All enclosing classes must not have private or protected access within their respective parent classes.

This means that, for example, most Method_GNEB functions and members would need to be public or it cannot really use Backend::par::apply etc.


Note also

  1. __host__ __device__ extended lambdas cannot be generic lambdas.
  2. ...
  3. ...
  4. An extended lambda has the following restrictions on captured variables:
    • ...
    • A variable can only be captured by value.
    • A variable of array type cannot be captured if the number of array dimensions is greater than 7.
    • ...
    • A function parameter that is an element of a variadic argument pack cannot be captured.
    • ...
    • Init-capture is not supported for __host__ __device__ extended lambdas. Init-capture is supported for __device__ extended lambdas, except when the init-capture is of array type or of type std::initializer_list.
    • The function call operator for an extended lambda is not constexpr. The closure type for an extended lambda is not a literal type. The constexpr specifier cannot be used in the declaration of an extended lambda.

GPMueller avatar Apr 21 '20 15:04 GPMueller