4 ms·

Or you could just use C++11/14 allocators instead which fix this in a much more transparent way...

by octo_t 11y ago

jhartmann 11y ago
There are prebuilt slab allocators that do this well. I used the arena allocator in facebook's libfolly recently as the base for a huge page allocator, and the code turned out quite nice. I think the allocator is a much better abstraction here. You could use something like the arena allocator here to carve out the memory for all the vertex and mesh storage and amortize the cost of hundreds of objects as well, so I don't like the argument in the first few sentences of the article actually that allocators would take more space.
humanrebar 11y ago
Exactly. Stateful allocators were added to the standard library especially for this sort of problem. Before, allocators were assumed to have no internal state, which made it problematic to manage memory from an arena or pool. Perhaps there's a reason allocators wouldn't work here, but if so, it deserves a little discussion.
- quicknir 11y ago
  I did discuss stateful allocators. They're nice, I'm a big fan. But as I said, they would impose pointless space overhead of one extra pointer per array. Also, you now have more complicated issues: each of the arrays is now an owner. What if you try to make a copy of it? Move construction? What if the container tries to deallocate, how does our allocator handle that? When I copy Mesh, would I need to change the allocator's state in the copies? How would that even work? I think that once you think about trying to accomplish the very specific and relatively simple thing being done here with allocators, you'll see that it would be quite a bit more complexity to no benefit. I think I did give it a "little" discussion :-). Guess it depends on your definition of a little. I didn't want to talk more about it because I didn't want to get sidetracked, and this is ultimately the way I chose to do it. Hope that sheds some light on the post and the choices I made with it.

Or you could just use C++11/14 allocators instead which fix this in a much more transparent way...

by octo_t 11y ago

Or you could just use C++11/14 allocators instead which fix this in a much more transparent way...

There are prebuilt slab allocators that do this well. I used the arena allocator in facebook's libfolly recently as the base for a huge page allocator, and the code turned out quite nice. I think the allocator is a much better abstraction here. You could use something like the arena allocator here to carve out the memory for all the vertex and mesh storage and amortize the cost of hundreds of objects as well, so I don't like the argument in the first few sentences of the article actually that allocators would take more space.

humanrebar 11y ago

Exactly. Stateful allocators were added to the standard library especially for this sort of problem. Before, allocators were assumed to have no internal state, which made it problematic to manage memory from an arena or pool. Perhaps there's a reason allocators wouldn't work here, but if so, it deserves a little discussion.

quicknir 11y ago
I did discuss stateful allocators. They're nice, I'm a big fan. But as I said, they would impose pointless space overhead of one extra pointer per array. Also, you now have more complicated issues: each of the arrays is now an owner. What if you try to make a copy of it? Move construction? What if the container tries to deallocate, how does our allocator handle that? When I copy Mesh, would I need to change the allocator's state in the copies? How would that even work? I think that once you think about trying to accomplish the very specific and relatively simple thing being done here with allocators, you'll see that it would be quite a bit more complexity to no benefit. I think I did give it a "little" discussion :-). Guess it depends on your definition of a little. I didn't want to talk more about it because I didn't want to get sidetracked, and this is ultimately the way I chose to do it. Hope that sheds some light on the post and the choices I made with it.