Repository navigation
Reorder spike vectors with a flexible-dtype numba kernel - #4784
grahamfindlay wants to merge 2 commits into
Conversation
|
The 2 failing tests don't appear to have anything to do with this PR. They're tolerance tests failing on |
|
EDIT: No longer applicable, see below. |
62a512f to
22cd36f
Compare
|
Removed the fix for the unrelated failing tests since another one was already just merged in #4792 |
The counting-sort kernel from SpikeInterface#4695 moved rows through a flat (N, num_fields) int64 view and addressed unit_index and segment_index as columns 1 and 2, essentially assuming minimum_spike_dtype. Samuel suggest that we might want to change the spike vector dtype in the future, so this is a more flexible variant that can take narrow index dtypes (e.g. int8). Also updated the numpy fallback to work for narrow index fields. Measured on ~400M spikes, 342 units: - 11.6 -> 12.0 s (3x int64 fields) - 13.1 -> 13.0 s (4x int64 fields) - 9.1 s (1 each of int64/int32/int8 fields)
for more information, see https://pre-commit.ci
22cd36f to
89ee24f
Compare
|
@samuelgarcia the failing Python 3.14 tests are unrelated and should be fixed in #4845 so this is still ready for your review anytime |
Follows @samuelgarcia 's comment on #4695 and #4781.
The numba kernel from #4695 moved rows through a flat
(N, num_fields)int64view and addressedunit_indexandsegment_indexas columns 1 and 2, assumingminimum_spike_dtype.Samuel suggest that we might want to change the spike vector dtype in the future, so this is a more flexible variant that can take narrow index dtypes (e.g. int8).
Also updated the numpy fallback to work for narrow index fields.
Measured on ~400M spikes, 342 units: