-
-
Notifications
You must be signed in to change notification settings - Fork 132
Bug: GCXS slicing can take inordinate amount of time / crash kernel #853
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Here's a transcript of running the same in a python repl:
|
Funny, I can't seem to reproduce this: >>> import sparse
>>> a = sparse.COO(
... [[1, 100, 215, 66],[5, 101, 242, 11],[3, 5, 1, 11],[13, 1, 3, 1],[55, 1, 6, 8]],
... [5, 10, 2, 1],
... shape=(255, 255, 255, 255, 255)
... )
>>> b = a.asformat('gcxs')
>>> b[1, :, :, :, :]
<GCXS: shape=(255, 255, 255, 255), dtype=int64, nnz=1, fill_value=0, compressed_axes=(np.int64(0),)> I also tested with |
Sure, what can I give you so it's hopefully easier to reproduce? It's a Conda-Forge venv, with Python 1.13, on Ubuntu 22.04 and an Intel 11th gen CPU. Python just quits, I'm suspecting an infinite loop of some kind. |
That's counter intuitive, the algorithm is completely deterministic and would also lead to a timeout on my machine if there was an infinite loop. |
Okay so I did an experiment with
|
Okay, updated my sparse version to current HEAD ( Here's the test script in full:
|
Hmm, the only deps we have are NumPy and Numba, and I couldn't replicate the issue with those versions. Let me try a Ubuntu 22.04 VM. |
Hmm, you're right. It does happen on Ubuntu 22.04 with Intel emulation on my ARM Mac; so it's either x86-64 related or Linux/Ubuntu 22.04 related. I'll look into this more, it's a curious bug indeed. Edit: What's more, it happens with the Numba JIT entirely disabled, which means very likely this is a pure-NumPy bug you've hit on! Edit 2: It exits almost immediately, it doesn't hang for me. |
It seems to be Numba-related, I've reported it upstream at numba/numba#10040. |
how fun! 😇 thanks for looking into it... |
sparse version checks
I checked that this issue has not been reported before list of issues.
I have confirmed this bug exists on the latest version of sparse.
I have confirmed this bug exists on the main branch of sparse.
Describe the bug
I have noticed that under some circumstances, slicing a GCXS array will take an unexpecteda amount of time, or crash the kernel after a runtime of >45 seconds.
Steps or code to reproduce the bug
Expected results
A slice returned within a short amount of time, provided the sparsity of the matrix.
b[:, 1, :, :, :]
,b[:, :, 1, :, :]
andb[:, :, :, 1, :]
return after a fraction of a second.b[: :, :, :, 1]
for some reason takes ~4 seconds on my machine.Actual results
Kernel crash after >45 seconds of runtime.
Please describe your system.
Relevant log output
The text was updated successfully, but these errors were encountered: