3 ms·
> it takes effort to make a standard library vector worse than a manually optimized one A simple use case is a 2D array where rows are padded to be multiples o
by Const-me 2y ago
> it takes effort to make a standard library vector worse than a manually optimized one
A simple use case is a 2D array where rows are padded to be multiples of 32 bytes (size of AVX SIMD vectors, saves a lot of implementation complexity because no need to handle remainders) or 64 bytes (saves a tiny bit of performance when parallelizing, guarantees cache lines aren’t shared between rows).
When element size is not a power of 2, it’s impossible to implement that RAM layout on top of an std::vector
- jltsiren 2y agoIt's obviously possible to find niche cases where the standard containers are not good enough. But the remaining 9999 cases out of 10000 are more interesting. I also had one of those, in an application that created and deleted a large number of fixed-size arrays across many threads. A naive implementation using glibc malloc ended up with a massive memory leak caused by hundreds/thousands of fragmented arenas. A thread could usually not reuse the memory it had just freed, because it was using a different arena. And because the arena was not empty, it was not possible to unmap the memory.