Hey Gabe, Are you thinking that a custom allocator would make a difference in terms of memory footprint or in terms of performance (or both)?
A couple of thoughts: - I'm hesitant to put the final keyword on Packet. I think we could see some code cleanup by making Packet a polymorphic object (e.g., Daniel has been talking about implementing packets with compressed data). Obviously, using polymorphism isn't required, and I don't have any plans to make this change in the near future. But it's something that I've been thinking about. - I like the idea of requiring the use of a small function to allocate requests and packets. In many cases, for Packets, we use Packet::createRead()/createWrite(), which is a step in that direction. I think this would be a relatively non-controversial change moving in the direction of custom allocators. It may also allow us to do some testing on this more easily. Another argument against custom allocators is that we'll be adding a significant amount of error-prone code. I like the idea of using standard libraries as much as possible to aid in understanding the code and reducing the bug surface. That said, if we get a 20% speedup or a reduction in memory footprint then this change would likely be worth it! Cheers, Jason On Wed, Nov 28, 2018 at 7:22 PM Gabe Black <gabebl...@google.com> wrote: > I was just wondering whether it would make sense to have custom allocators > defined for Request and Packet types which would keep around a pool of them > rather than defaulting to the normal allocator. I suspect since both types > of objects are allocated very frequently this could save a lot of heap > overhead. > > I think there are two complications to doing this. First, we'd want to make > sure Request and Packet objects are truly those objects and are of the > appropriate size. Subclasses could add new members and make the types > bigger. I think to ensure that, we'd need to add the "final" keyword (added > in C++11) to ensure those types can't be subclassed and have unpredictable > sizes. > > Second, we use make_shared a lot to build Requests, and that actually > allocates a larger amount of memory to hold the object and reference count > information. It allocates that larger object with new, and it looks like > you're supposed to use allocate_shared if you want to use a custom > allocator. Writing a custom allocator looks relatively complicated, but it > might make a big difference if it works correctly. > > Also we'd probably want to put the Request allocator incantation in a small > function rather than calling make_shared or allocate_shared directly to > avoid a lot of boilerplate and churn if things need to change. > > Thoughts? Like I said I suspect this may make a significant difference, but > it might not be easy to implement and may not actually make much of a > difference at all. > > Gabe > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
