Skip to content

Reorder spike vectors with a flexible-dtype numba kernel - #4784

Open
grahamfindlay wants to merge 2 commits into
SpikeInterface:mainfrom
grahamfindlay:perf/reorder-record-kernel
Open

grahamfindlay wants to merge 2 commits into
SpikeInterface:mainfrom
grahamfindlay:perf/reorder-record-kernel

Conversation

@grahamfindlay

Copy link
Copy Markdown
Contributor

Follows @samuelgarcia 's comment on #4695 and #4781.

The numba kernel from #4695 moved rows through a flat (N, num_fields) int64 view and addressed unit_index and segment_index as columns 1 and 2, 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)

grahamfindlay and others added 2 commits September 15, 2026 15:23
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant