Thanks! If there actually is a consistent 1.5% performance improvement I'd be pretty impressed, particularly since (according to Ali) FastAlloc isn't actually being used for DynInsts. Of course, 1.5% could well be within the measurement error too.
Steve On Tue, May 29, 2012 at 10:41 AM, William Wang <[email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
