Investigations of storing multiple types in separate buffers in one allocation about header-vec HOT 4 CLOSED

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.

from header-vec.

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?

from header-vec.

from header-vec.