3 ms·

I've been using std::vector with arrays that take up to tens of gigabytes for ~15 years without any real issues. Once the size of the allocation exceeds a few m

• 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 ago
    It'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.