chore: refactor onedal interaction with backend and policies

ahuber21 commented 2 weeks ago

Description

Refactor how and where methods are loaded from backend.
- All functions are now explicitly declared as @abstractmethod and then populated using a decorator loaded from _backend.py.
- It is now explicit where the functionality comes from.
- We can start using the functions with self.infer(...) rather than the convoluted self._get_backend("X", "Y", "infer" , ...).
All dependencies from standard compute functions (compute(), infer(), ...) on backend are unified in _backend.py.
Backend wrapper class around the backend export in onedal/__init__.py to reduce the use of global variables.
More wrapper classes BackendManager, PolicyManager, BackendFunction that simplify interfacing with pybind/C++ backend functionality.
I removed unused imports because there were so many in the files I touched. I didn't stop at the files I modified and did the entire repo, which messed up the diff a little. Sorry. I am constantly rebasing so that all functionality is in a single commit and you can look at the diff of this single commit instead if you want to review.
- Since this is becoming a quite complex PR, I reverted the unused imports changes. This will need its own PR.
Test update (WIP): Enables tests for iris and diabetes SVM algos on GPU. Updated dispatching seems to support GPU just fine. Feedback requested! @samir-nasibli

PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed. This approach ensures that reviewers don't spend extra time asking for regular requirements.

You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way. For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).

Checklist to comply with before moving PR from draft:

PR completeness and readability

[x] I have reviewed my changes thoroughly before submitting this pull request.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have updated the documentation to reflect the changes or created a separate PR with update and provided its number in the description, if necessary.
[x] Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
[x] I have added a respective label(s) to PR if I have a permission for that.
[x] I have resolved any merge conflicts that might occur with the base branch.

Testing

[x] I have run it locally and tested the changes extensively.
[x] All CI jobs are green or I have provided justification why they aren't.
[x] I have extended testing suite if new functionality was introduced in this PR.

Performance

[x] I have measured performance for affected algorithms using scikit-learn_bench and provided at least summary table with measured data, if performance change is expected.
[x] I have provided justification why performance has changed or why changes are not expected.
[x] I have provided justification why quality metrics have changed or why changes are not expected.
[x] I have extended benchmarking suite and provided corresponding scikit-learn_bench PR if new measurable functionality was introduced in this PR.

icfaust commented 2 weeks ago

i guess this contrasts the approach i wanted to take in #2158 . what i had not liked about _get_backend was the indirection it was inducing in accessing the pybind11 generated package, and hoped to bring native syntax back. maybe worth further discussion?

ahuber21 commented 2 weeks ago

/intelci: run

ahuber21 commented 2 weeks ago

/intelci: run

ahuber21 commented 2 weeks ago

/intelci: run