I didn't do any comprehensive testing, but averaging a few short runs of the ruby tester on m5.opt showed compiling with FastAlloc about 3% faster than not.
Steve On Thu, Mar 10, 2011 at 2:11 PM, nathan binkert <n...@binkert.org> wrote: > Seems reasonable. One question. Do we know that FAST_ALLOC actually > is faster than the built in allocator? It's pretty darned old and > memory allocators are pretty modern now. > > Nate > > On Thu, Mar 10, 2011 at 8:23 AM, Steve Reinhardt <ste...@gmail.com> wrote: > > Brad pointed out that he habitually sets NO_FAST_ALLOC when compiling > > m5.debug because the way FastAlloc handles memory allocation tends to be > > tolerant of memory allocation errors (like reusing objects after they've > > been deleted), and he's run across other people's bugs simply by running > > with NO_FAST_ALLOC. I pointed out that he's abusing the purpose of a > sticky > > config variable by toggling it based on which binary he's compiling, but > he > > didn't seem to care ;-). > > > > He has a good point though, so what I would like to do is condition the > use > > of FastAlloc on whether DEBUG is set. While this sounds straightforward, > > there are several minor complications I want to solicit input on before I > do > > this. (Though of course people are free to object with the basic premise > if > > they choose.) > > > > - It seems like there should be a way to force FastAlloc to be on even > for > > m5.debug, on the off chance you might want to debug FastAlloc itself, or > if > > there's some other bug that presents itself more readily in combination > with > > FastAlloc. I propose adding a FORCE_FAST_ALLOC sticky config var to do > > this. > > > > - There's some code protected by '#if FAST_ALLOC_DEBUG' that is intended > to > > help debug memory leaks using FastAlloc. I've used it once or twice, but > I > > kind of doubt that anyone else has, and I'm sure it's not as good as > using > > valgrind or probably several other malloc debug packages. It seems > > particuarly ironic to have debug code in a module that is disabled in > > m5.debug, so I propose getting rid of this. That would also let us get > rid > > of the FAST_ALLOC_DEBUG scons sticky var, so we'd be at a wash in terms > of > > sticky var count. > > > > Any comments? > > > > Steve > > _______________________________________________ > > m5-dev mailing list > > m5-dev@m5sim.org > > http://m5sim.org/mailman/listinfo/m5-dev > > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
