Multiple backends prototype

[SergeyKopienko]

This PR is only prototype for descussions.

The goal of this PR

The goal of this PR - redesign our host backends (SERIAL, TBB, OMP) :

• to use them depends on backend_tag;
• to safe use them together (if required).

How we trying to achieve these goals (the main idea):

• in the namespace oneapi::dpl::__backend we declare common backend template structure:

// Template for backend implementations
template <typename __backend_tag>
struct __backend_impl;

• in the namespace oneapi::dpl::__backend for each of our host backends (SERIAL, TBB, OMP) we create it's specializations:

// parallel_backend_omp.h
template <>
struct __backend_impl<oneapi::dpl::__internal::__omp_backend_tag>
{
    // Declare here public API functions of OMP backend
};

// parallel_backend_serial.h
template <>
struct __backend_impl<oneapi::dpl::__internal::__serial_backend_tag>
{
    // Declare here public API functions of SERIAL backend
};

// parallel_backend_tbb.h
template <>
struct __backend_impl<oneapi::dpl::__internal::__tbb_backend_tag>
{
    // Declare here public API functions of TBB backend
};

• move backend public API functions into these structures;
• move private backend functions into some separate namespaces: oneapi::dpl::__backend::__tbb_backend_details, oneapi::dpl::__backend::__omp_backend_details. These separate namespaces give guaranties to us that each backend implementation used their own implementation details.
• in the file include/oneapi/dpl/pstl/parallel_backend.h create/modify some useful template aliases:

namespace oneapi
{
namespace dpl
{

template <typename __backend_tag>
using __par_backend = oneapi::dpl::__backend::__backend_impl<__backend_tag>;

template <typename __backend_tag, typename _ExecutionPolicy, typename _Tp>
using __par_backend_buffer = typename __par_backend<__backend_tag>::template __buffer<_ExecutionPolicy, _Tp>;

} // namespace dpl
} // namespace oneapi

The usage of this approach in the code (examples):

// __backend_tag{} removed from arguments here
__par_backend<__backend_tag>::__parallel_for(...);

__par_backend_buffer<__backend_tag, _ExecutionPolicy, bool> __mask_buf(__exec, __n);

If this approach looking good we are able to repack device and fpga backend by the same way too, implementing them inside two additional hetero backend implementations:

template <>
struct __backend_impl<oneapi::dpl::__internal::__device_backend_tag>
{
    // Declare here public API functions of device hetero backend
};

template <>
struct __backend_impl<oneapi::dpl::__internal::__fpga_backend_tag> : __backend_impl<oneapi::dpl::__internal::__device_backend_tag>
{
    // Declare here public API additional functions of FPGA hetero backend
};

[SergeyKopienko]

@akukanov If this approach looks ok we may try to extend it for hetero backends too,

[MikeDvorskiy]

• move backend public API functions into these structures;

Unfortunately, it breaks one of tag dispatching advantage - to have possibility to overload (via C++ function overloading mechanism) backend pattern implementation by a user tag.

[SergeyKopienko]

May be I don’t understand what you mean, but I think it’s still possible for the users:

• Instead of function overload whey should implement some full backend that they wants.

With the best regards, Sergey Kopienko

From: MikeDvorskiy @.> Sent: Tuesday, May 7, 2024 4:08 PM To: oneapi-src/oneDPL @.> Cc: Kopienko, Sergey @.>; Assign @.> Subject: Re: [oneapi-src/oneDPL] Multiple backends prototype (PR #1509)

• move backend public API functions into these structures;

Unfortunately, it breaks one of tag dispatching advantage - to have possibility to overload (via C++ function overloading mechanism) backend pattern implementation by a user tag.

— Reply to this email directly, view it on GitHubhttps://github.com/oneapi-src/oneDPL/pull/1509#issuecomment-2098497389, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AWBJJSW2DEWEZ2G6GSGEXWTZBDN4RAVCNFSM6AAAAABGLAQFGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJYGQ4TOMZYHE. You are receiving this because you were assigned.Message ID: @.@.>> Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928