4 ms·

If you know the size of your data upfront this isn't applicable. Usually I use std::vector when I don't know how much data I have. If you already know the size

by _4r6j 5y ago

If you know the size of your data upfront this isn't applicable. Usually I use std::vector when I don't know how much data I have. If you already know the size why not avoid allocating on the heap altogether? I will update the README to be more clear.

Cyph0n 5y ago
1. You only know the size at runtime. 2. You want to avoid the risk of overflowing the stack.
omegalulw 5y ago
Because you can't put arbitrarily large objects on the stack and unless your program is going to be using that memory for all of it's lifetime, it makes no sense to use static storage.
ddlutz 5y ago
You have a large collection of large objects and don't want to allocate on the stack.
- _4r6j 5y ago
  yeah it's not any better in that case then. i updated README to reflect that.
nanidin 5y ago
Is there any benefit to using virtual_vec as opposed to a std::deque then? It guarantees constant time pushes to the back and constant time random element access via operator[][0]. I think the case for std::vector::reserve() is when you know you are about to add N elements via push_back(), you call reserve() with the appropriate size to ensure there is only one reallocation caused by that addition of N elements. [0] https://www.cplusplus.com/reference/deque/deque/operator[]/ https://www.cplusplus.com/reference/deque/deque/operator[]/
- MauranKilom 5y ago
  std::dequeue is useless from a practical/portability perspective. MSVC allocates items in 16 byte chunks (as in, one allocation per item if sizeof(T) > 8). This will not change due to binary compatibility. From a theoretical perspective I agree with you though - having chunked allocations is going to be significantly better, and using iterators instead of raw pointers you can also avoid any trouble that might result from non-contiguity (e.g. trying to subtract two pointers - it will work just fine using the iterators).
  - beached_whale 5y ago
    libc++ uses 4kb
- _4r6j 5y ago
  iterating over vectors (of trivial types that aren't pointers) is generally going to be faster since the memory is contiguous. deque is implemented with chunks i believe? loading in new chunk could be cache eviction.
  - nanidin 5y ago
    Aha, so the contiguity of the actual memory pages must not be what is used for prefetching by the MMU, instead it is the contiguity of the virtual address space? I was thrown for a bit of a loop working through virtual vs actual memory addresses and how this works under the hood, but it makes more sense now. In that case then virtual_vec would be better than std::deque in terms of iterating over the contained data in order.

by _4r6j 5y ago

Cyph0n 5y ago

1. You only know the size at runtime. 2. You want to avoid the risk of overflowing the stack.

omegalulw 5y ago

Because you can't put arbitrarily large objects on the stack and unless your program is going to be using that memory for all of it's lifetime, it makes no sense to use static storage.

ddlutz 5y ago

You have a large collection of large objects and don't want to allocate on the stack.

_4r6j 5y ago
yeah it's not any better in that case then. i updated README to reflect that.

nanidin 5y ago

Is there any benefit to using virtual_vec as opposed to a std::deque then? It guarantees constant time pushes to the back and constant time random element access via operator[][0]. I think the case for std::vector::reserve() is when you know you are about to add N elements via push_back(), you call reserve() with the appropriate size to ensure there is only one reallocation caused by that addition of N elements. [0] https://www.cplusplus.com/reference/deque/deque/operator[]/ https://www.cplusplus.com/reference/deque/deque/operator[]/

MauranKilom 5y ago
std::dequeue is useless from a practical/portability perspective. MSVC allocates items in 16 byte chunks (as in, one allocation per item if sizeof(T) > 8). This will not change due to binary compatibility. From a theoretical perspective I agree with you though - having chunked allocations is going to be significantly better, and using iterators instead of raw pointers you can also avoid any trouble that might result from non-contiguity (e.g. trying to subtract two pointers - it will work just fine using the iterators).
- beached_whale 5y ago
  libc++ uses 4kb
_4r6j 5y ago
iterating over vectors (of trivial types that aren't pointers) is generally going to be faster since the memory is contiguous. deque is implemented with chunks i believe? loading in new chunk could be cache eviction.
- nanidin 5y ago
  Aha, so the contiguity of the actual memory pages must not be what is used for prefetching by the MMU, instead it is the contiguity of the virtual address space? I was thrown for a bit of a loop working through virtual vs actual memory addresses and how this works under the hood, but it makes more sense now. In that case then virtual_vec would be better than std::deque in terms of iterating over the contained data in order.