Re:Handles Are the Better Pointers (2018)
by rightbyte on Thursday August 13, 2020 @08:30AM
(#24142664)
I don't know. The hugest saving from not malloc-ing small objects comes from the memory-chunk overhead I believe. You could do object pools and still use pointer as usual I think with no runtime cost of passing handles to getter-functions. The usual pattern of "wrapping" malloc/free.
[ Parent
| on HN ]
Re:Handles Are the Better Pointers (2018)
by OnACoffeeBreak on Thursday August 13, 2020 @08:40AM
(#24142721)
What about CPU data cache misses due to the fact that malloc doesn't have a concept for how best to organize that data chunk of data based on your application's specific usage pattern?
Re:Handles Are the Better Pointers (2018)
by batty_alex on Thursday August 13, 2020 @09:12AM
(#24142974)
That can definitely be a problem. Using handles makes it easier to swap out your allocation mechanism if you ever have to optimize your cache efficiency.
Hell, projects that need to squeeze out that level of performance will typically have multiple different memory allocation mechanisms.
Re:Handles Are the Better Pointers (2018)
by rightbyte on Thursday August 13, 2020 @09:21AM
(#24143040)
Ye well then you'll need something fancy. The size saving is there though.
Re:Handles Are the Better Pointers (2018)
by learc83 on Thursday August 13, 2020 @09:11AM
(#24142957)
Object pools pale in comparison to striping the data into arrays (or as we call it in the game dev world a Struct of Arrays) when it comes to reduced cache misses.
Re:Handles Are the Better Pointers (2018)
by rightbyte on Thursday August 13, 2020 @09:15AM
(#24142996)
Given that you iterate over the object fields in a "column like" manner, right? Random access should be slower since an object of say four elements would have to fetch four cache lines.
You're more likely to have the next object cached by the time you access it compared to separate allocations.
The more sequential the access pattern is and the smaller the objects are, the greater benefit.