I've run with fast alloc, without fast alloc and without fast alloc but with tcmalloc (http://code.google.com/p/gperftools/). I've run each twice and the results are reasonable conclusive. FastAlloc appears to be slightly faster (1-2%) after increasing the max size to 1024 bytes and adding FastAlloc to a few more classes in the O3 CPU. TCMalloc is an astonishingly 8%-10% faster, so I vote for TCMalloc.
Thanks, Ali On 29.05.2012 14:11, Steve Reinhardt wrote: > 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 [3], 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 flag); it would be interesting to see if that matters. Of course, if most story. > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev Links: ------ [1] mailto:[email protected] [2] http://m5sim.org/mailman/listinfo/gem5-dev [3] http://www.m5sim.org/docs/classFastAlloc.html _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
