Perormance regressions introduced by latest changes to main

[diptorupd]

I also see segfaults, makes me think that something is wrong with local memory.

Originally posted by @fcharras in #816 (comment)

The new problems are not related to #877 but to #876 , reported in #816

Originally posted by @fcharras in #867 (comment)

[fcharras]

@diptorupd @chudur-budur

We're having conversations about this in multiple separate issues, let's keep it in this dedicated thread ?

I also see segfaults, makes me think that something is wrong with local memory.

The problem most likely is because I without realizing the impact changed the way the global and local range args passed to the __getitem__. We are working on reverting my changes and fixing the issue.

Do you still need a minimal reproducer ? I haven't come up with one yet. Yet again it's not trivial to reproduce, simple kernels still work.

If you have a commit that revert those changes I can easily say if it fixes the issues though. (basically running the benchmark script in https://github.com/soda-inria/sklearn-numba-dpex )

[diptorupd]

@fcharras No we do not need th reproducer. Let @chudur-budur open the PR and then you can test and let us know if the issue is fixed.

[chudur-budur]

@fcharras Could you please test PR #888 and check if you are seeing any performance issues?

[fcharras]

Unfortunately, issues persists in #888 :-/

I just realized that I made a mistake in my bug report that might have misled you. The problems start at the merge commit of #804 not #876 . The merge commits of those two PRs are very close to each other and I missclicked the copy/paste :-/

[chudur-budur]

@fcharras Could you please test #896 and see if you are getting any slowdown?

[fcharras]

@chudur-budur @diptorupd please see #898 that give a minimal reproducer for what caused the regression I was facing, which is more than a performance issue.

However, it appears fixing it will not be the end. After understanding the bug I could test the KMeans in a way that doesn't trigger it (changing some parameters), and I still see a minor slow down. I think the refacto also added some python overhead. But, that should be easier to debug with normal profiling ? maybe the cache keys that are computed are a bit too computationally heavy. There are probably several expensive calls that can be saved. (no need to re-hash the codegen every time for instance)

But~ there are two more important issues to solve first IMO.

[diptorupd]

Closing the issue as the caching related performance regressions have been addressed and the code generation issue in #898 is solved.