[maintenance] lazy load dpnp.tensor/dpnp and prepare for array_api lazy importing

[icfaust]

Description

Dpctl and dpnp are quasi-dependencies which will silently error out if not installed. This is done at import time throughout the codebase, meaning that it is mixed into the codebase in a difficult manner. As the number of supported data frameworks are increased, such a strategy is unsustainable. Lazy loading of the necessary packages must be done, as the load time of follow-on frameworks like PyTorch are non-negligible (>1s). If we were to follow the same strategy, load times of sklearnex would be even longer even if pytorch isn't used but is available. This will compound as we would add framework support. Cleanly separating and isolating their use is necessary.

Therefore we need to first move dpnp and dpctl.tensor support to a lazy loading approach which will then be extended by follow-on frameworks. The next step will be pytorch queue extraction, which will require this infrastructure.

The strategy will follow that of array_api_compat which can check for namespaces without importing the actual modules, and for the direct use of the frameworks, a depedency injection + monkeypatching scheme is used with decorator lazy_import.

NOTE TO REVIEWERS: Let me know if I should do a performance benchmarks for this.

---

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

• I have reviewed my changes thoroughly before submitting this pull request.
• I have commented my code, particularly in hard-to-understand areas.
• 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.
• Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
• I have added a respective label(s) to PR if I have a permission for that.
• I have resolved any merge conflicts that might occur with the base branch.

Testing

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

Performance

• 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.
• I have provided justification why performance has changed or why changes are not expected.
• I have provided justification why quality metrics have changed or why changes are not expected.
• I have extended benchmarking suite and provided corresponding scikit-learn_bench PR if new measurable functionality was introduced in this PR.

[david-cortes-intel]

Could also use np.prod, since numpy is already imported throughout the codebase.

[icfaust]

https://github.com/scikit-learn/scikit-learn/blob/73a8a656b8df6d02cf88ef8f9cf98373a3f42051/sklearn/utils/_array_api.py#L215 Not entirely sure how numpy would interact with pytorch in that case. Could check that if you want, but its following the precedent set by sklearn itself

[david-cortes-intel]

Would this work if one of those array classes is subsetted by the user?

[icfaust]

Nope, but neither would array_api_compat, meaning that steps before in sklearnex are likely to have thrown an error: https://github.com/data-apis/array-api-compat/blob/main/array_api_compat/common/_helpers.py#L63

[icfaust]

actually let me check this, i may be wrong

[icfaust]

Here is an example:

import functools, sys
import numpy as np
@functools.lru_cache(100)
def _is_subclass_fast(cls: type, modname: str, clsname: str) -> bool:
    try:
        mod = sys.modules[modname]
    except KeyError:
        return False
    parent_cls = getattr(mod, clsname)
    return issubclass(cls, parent_cls)

class test(np.ndarray):
    pass

testobj = test((3,5))
print(type(testobj))
print(issubclass(type(testobj), np.ndarray))
print(_is_subclass_fast(type(testobj), "numpy", "ndarray"))

Will print:
<class '__main__.test'>
True
True

[david-cortes-intel]

Wouldn't importing the module inside the function have the same effect?

[icfaust]

Trying to avoid adding an unnecessary slowdown via the dictionary search of sys.modules. I don't think it impacts the readability as it is, and follows precedent set by other codebases like sqlite3: https://stackoverflow.com/a/61647085

[david-cortes-intel]

I don't follow. Their idea is to use the module multiple times, but here it gets only used inside a single function. Why would that lazy loader decorator be more efficient than importing the module inside of the function?

[icfaust]

Since this is in line with this discussion: #2509 (comment) , the monkeypatch is attempting remove the slow down of the additional sys.module checks that would otherwise be added by the lazy load (if import was just added in the function). Just trying to have my cake and eat it too.

[icfaust]

/intelci: run

[Alexsandruss]

I'm not sure if third_party is the most correct term for these frameworks. Is frameworks_support or frameworks_compat better?

[icfaust]

I'd agree with that except for the fact that we centralize the import of SyclQueue for use in a number of locations there (which isn't part of a framework) and that we already have an equivalent 'datatypes' onedal module.

[Alexsandruss]

A comment why this error type might be expected is needed.

[icfaust]

Added for every use of this (in onedal logistic_regression, onedal forest, and sklearnex forest). It looks like get_unique_values_with_dpep was not extended to all of our classifiers, so there is definitely some gap here. I will make a follow up ticket to investigate.

[icfaust]

/intelci: run