Good talk :)! I think there was one point about stack allocation that is important but is not mentioned: stack allocation does not let you share memory with other threads. A stack is by definition associated with a thread. If that thread allocates something on the stack, it can't share that memory with other threads. Actually, it can but that memory may disappear "anytime" so if you do that you are just introducing a terrible bug. That is one thing that you can't use stack allocation for (but you can use the stack-like custom allocator mentioned).
Well yeah, but you can make the same mistake with malloc, this is just freeing the shared memory too early. There's nothing wrong with using the stack for shared memory if allocating it in the main thread and joining all the threads at the end of the same function for example.
Actually, on Windows, MS CRT malloc() just calls HeapAlloc(). It was doing some magic back in the days of the Visual C++ 6, but later on it has became just a tiny wrapper of the HeapAlloc().
Right you can't pop on a monotonic allocator, it's in the name. Monotonic refers to the strictly increasing behavior of the pointer, that pointer being something to that's "free", when you "free" you don't do anything until the allocator needs to go, or you know you can clear the allocator entirely. However, if you drop the simplicity of the monotonic behavior, with a bit a bookmarking you can let's say keep track of more than one pointer etc, allowing you to pop a fixed number of times. The trick at that point is understanding how your application / algorithm works in terms of allocation, do you have a structure or data that is stack-like that tends to grow larger and larger over time/use anyway? Probably a better fit than a monotonic allocator.
Yes, only for a few seconds. Unfortunately, there's nothing I can do about it due to an issue with the slide recording, but you shouldn't miss any important content.
Best talk title ever
Good talk :)! I think there was one point about stack allocation that is important but is not mentioned: stack allocation does not let you share memory with other threads.
A stack is by definition associated with a thread. If that thread allocates something on the stack, it can't share that memory with other threads.
Actually, it can but that memory may disappear "anytime" so if you do that you are just introducing a terrible bug.
That is one thing that you can't use stack allocation for (but you can use the stack-like custom allocator mentioned).
Well yeah, but you can make the same mistake with malloc, this is just freeing the shared memory too early. There's nothing wrong with using the stack for shared memory if allocating it in the main thread and joining all the threads at the end of the same function for example.
Great talk, thanks for sharing
For #6 you could also use a callback and avoid any allocations and redundant reserves(), ie.
find_neighbours( current, [&](Point p) { ... } );
Actually, on Windows, MS CRT malloc() just calls HeapAlloc(). It was doing some magic back in the days of the Visual C++ 6, but later on it has became just a tiny wrapper of the HeapAlloc().
Very good.
The monotonic allocator talk that is mentioned in this talk is most probable ua-cam.com/video/IGtKstxNe14/v-deo.html
Right you can't pop on a monotonic allocator, it's in the name. Monotonic refers to the strictly increasing behavior of the pointer, that pointer being something to that's "free", when you "free" you don't do anything until the allocator needs to go, or you know you can clear the allocator entirely. However, if you drop the simplicity of the monotonic behavior, with a bit a bookmarking you can let's say keep track of more than one pointer etc, allowing you to pop a fixed number of times. The trick at that point is understanding how your application / algorithm works in terms of allocation, do you have a structure or data that is stack-like that tends to grow larger and larger over time/use anyway? Probably a better fit than a monotonic allocator.
Instead of output parameters you can use an arena
You can use aggregate initialization instead, to avoid the free:
void clear()
{
*this = {};
}
Slides froze at 20:30
Yes, only for a few seconds. Unfortunately, there's nothing I can do about it due to an issue with the slide recording, but you shouldn't miss any important content.
that title lmao