A simple check showed there isn't much difference by turning NO_FAST_ALLOC on. Simple test (nothing conclusive without more rigorous testing), Linux booting ARM O3, with NO_FAST_ALLOC set to FALSE (default) and TRUE, showed that FastAlloc is 1.5% better than without. According to this graph http://www.m5sim.org/docs/classFastAlloc.html, FastAlloc is probably used mostly in BaseDynInst, Event, LSQUnit and Packet.
>My guess is that we should just stop using it since we're heading >towards multithreaded code anyway. I'd be quite surprised if it were >better than malloc. One real win that we could get is if we could >take advantage of partially constructed objects (I think that was in >the original slab allocator paper). > - I wouldn't take it on faith that FastAlloc is faster. It might be, but I > wrote that a *long* time ago, and malloc has probably improved in the > interim. It's easy to compile without it (I think there's a NO_FAST_ALLOC > flag); it would be interesting to see if that matters. Of course, if most > of the allocations aren't using it anyway, maybe that won't tell the whole > story. > >looking at the picture there seem to be plenty of other places where > >there are a lot of calls to new (teal-ish)/free(orange). It seems like > >we could certainly make more use of FastAlloc, assuming it's actually > >helping. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
