Feat: batched manhattan distance for a faster python implementation of the Laplacian kernel

[liam-o-marsh]

Requirements: #115

[briling]

can you please rebase onto new update-docs?

[briling]

@liam-o-marsh thanks!

ruff is not supposed to check setup.py I think, at least in the CI workflow (also there are exclusion rules in the config)

[briling]

should close #120

[briling]

@liam-o-marsh what do you think of this suggestion 3ba2079? (i can revert)

[briling]

btw why is RAM_BATCHING_SIZE so big?

[liam-o-marsh]

@liam-o-marsh what do you think of this suggestion 3ba2079? (i can revert)

looks good to me, thanks!

btw why is RAM_BATCHING_SIZE so big?

I assumed this would mostly run on server hardware, but yeah for highly-multithreaded stuff this won't work
but if this is too low, then it's back to the same performance as the old python-for-loop-over-R1 technique, but with the overhead of managing batch sizes of 1
maybe 1GiB would be more reasonable?
how big is the average R2? 1k samples times 10k features? that's already 80Mb for a single row of R1.

[briling]

slatm for qm7 is ~11k features, but we can use the C implementation...
i just noticed that any bigger size in the test slows it down

[briling]

2b rebased onto new update-docs

[briling]

I think it's ready to be merged?

[briling]

maybe rebase on master first though
and shall we squash?

[liam-o-marsh]

sounds good to me!