search

rust-cv / header-vec

Allows one to store a header struct and a vector all inline in the same memory on the heap and share weak versions for minimizing random lookups in data structures
MIT License
5 stars 2 forks source link

Investigations of storing multiple types in separate buffers in one allocation #7

Closed makoConstruct closed 1 month ago

makoConstruct commented 3 years ago

... For me the largest improvement would actually be if I could store multiple types in separate buffers in the allocation rather than as tuples

Originally posted by @vadixidav in https://github.com/rust-cv/header-vec/issues/4#issuecomment-899149076

makoConstruct commented 3 years ago

On this, I've just sort of maybe finished up working on something very closely related to that, VecWithGaps, and I can report that it did not go well. Once you have multiple inner vecs, The increased adjacency just doesn't seem to be doing much. I don't really feel that I understand what is going on here, yet, though. Performance remains unimpressive even when the extra capacity of all of the inner vecs is trimmed out, and even when there's a large number of small subvecs.

vadixidav commented 3 years ago

On this, I've just sort of maybe finished up working on something very closely related to that, VecWithGaps, and I can report that it did not go well. Once you have multiple inner vecs, The increased adjacency just doesn't seem to be doing much. I don't really feel that I understand what is going on here, yet, though. Performance remains unimpressive even when the extra capacity of all of the inner vecs is trimmed out, and even when there's a large number of small subvecs.

Interesting. I would be curious to see how it performs with SIMD operations as well, but I suppose even with tuples things are "close enough" in memory already. In my code, each tuple already contains a (usize, 512-bit chunk), where the 512-bit chunk can use SIMD, so its already separated and aligned such that SIMD is possible. The reason why I was interested in this is because the memory could be more compact than it currently is. Currently, I am wasting a lot of space because the usize and the 512-bit chunk are not the same size, but the 512-bit chunk needs to be aligned for SIMD. Perhaps you could investigate this scenario?

makoConstruct commented 3 years ago

Hmm I think it wouldn't be too hard to fit all of these things into vecwithgaps, but I wont do it just now. Moving onto implementing CSR++.

On Sat, Aug 28, 2021, 07:16 Geordon Worley @.***> wrote:

On this, I've just sort of maybe finished up working on something very closely related to that, VecWithGaps https://github.com/makoConstruct/vec-with-gaps, and I can report that it did not go well. Once you have multiple inner vecs, The increased adjacency just doesn't seem to be doing much. I don't really feel that I understand what is going on here, yet, though. Performance remains unimpressive even when the extra capacity of all of the inner vecs is trimmed out, and even when there's a large number of small subvecs.

Interesting. I would be curious to see how it performs with SIMD operations as well, but I suppose even with tuples things are "close enough" in memory already. In my code, each tuple already contains a (usize, 512-bit chunk), where the 512-bit chunk can use SIMD, so its already separated and aligned such that SIMD is possible. The reason why I was interested in this is because the memory could be more compact than it currently is. Currently, I am wasting a lot of space because the usize and the 512-bit chunk are not the same size, but the 512-bit chunk needs to be aligned for SIMD. Perhaps you could investigate this scenario?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rust-cv/header-vec/issues/7#issuecomment-907421644, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACUTSJD4VWWNQLVG4CDKXLT67QBHANCNFSM5C26PKAQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

vadixidav commented 1 month ago

I think I will go ahead and close this. I think this investigation has concluded for now. Open another ticket if this comes up again.