Developer discussion for the game `Battle for Wesnoth' ()

Ignacio Riquelme Morelle | 18 Feb 2012 17:47

Removal of poolalloc.c and malloc.c

Hi,

If I recall correctly, Dave introduced poolalloc.c and malloc.c to implement 
an alternate memory allocator for C++ objects in Wesnoth that was intended to 
help optimize our memory usage. However, they were disabled and (as far as I 
can tell) abandoned because they caused many hard-to-debug issues on certain 
platforms, presumably x86_64.

Judging by the name, they were intended to reduce memory fragmentation. I'm 
not sure this is still an important issue after several commits by silene 
(config class) and alink (image cache, terrain builder) advertising 
significant memory usage and performance improvements during 2010-2011. I 
haven't made any benchmarks myself, and it's important to consider that the 
codebase has grown significantly larger and complex (terrain graphics WML in 
particular) since the point at which the alternate allocator entered mainline, 
in late 2008.

Considering they aren't being maintained or used by anything other than a 
build option that's decidedly disabled by default (a user asked me about it 
the other day), would it be all right if they were removed from the source 
tree along with any references to them in the cmake and scons source file 
listings?

--

-- 
Regards
  Ignacio Riquelme Morelle <shadowmaster>

_______________________________________________
Wesnoth-dev mailing list

(Continue reading)

headers

Mark de Wever | 19 Feb 2012 10:02

Re: Removal of poolalloc.c and malloc.c

On Sat, Feb 18, 2012 at 01:47:24PM -0300, Ignacio Riquelme Morelle wrote:
> Hi,
> 
> Considering they aren't being maintained or used by anything other than a 
> build option that's decidedly disabled by default (a user asked me about it 
> the other day), would it be all right if they were removed from the source 
> tree along with any references to them in the cmake and scons source file 
> listings?

I wanted to send a mail regarding this issue as well, so I'm in favour
to remove them as well. The poolalloc might help, but as far as I know
it's broken on some platforms and not maintained. So unless somebody
steps up to maintain it I'm in favour for removal.

--

-- 
Regards,
Mark de Wever aka Mordante/SkeletonCrew

headers

David White | 19 Feb 2012 16:46

Re: Removal of poolalloc.c and malloc.c

On Sat, Feb 18, 2012 at 10:47 AM, Ignacio Riquelme Morelle <shadowm2006 <at> gmail.com> wrote:

Considering they aren't being maintained or used by anything other than a
build option that's decidedly disabled by default (a user asked me about it
the other day), would it be all right if they were removed from the source
tree along with any references to them in the cmake and scons source file
listings?

Yes, at this point it'd be best to remove them.

There are now many mature and high quality allocation libraries we could choose from that most likely reduce fragmentation. For instance, Google's allocator, Intel's allocator (shipping with Intel TBB) and jmalloc, used by Firefox. I think that it'd be worth exploring these different allocators and see if any of them offers significant performance improvements for Wesnoth. (Actually doing something like this seems like a nice example of an achievable GSoC project to me).

David

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev

headers

Ignacio Riquelme Morelle | 19 Feb 2012 19:50

Re: Removal of poolalloc.c and malloc.c

On Sunday 19 February 2012 12:46:45 David White wrote:
> Yes, at this point it'd be best to remove them.

All right; I have just removed the custom allocator and its support bits in 
the Wesnoth proper in r53125. I hope I didn't miss anything.

> There are now many mature and high quality allocation libraries we could
> choose from that most likely reduce fragmentation. For instance, Google's
> allocator, Intel's allocator (shipping with Intel TBB) and jmalloc, used by
> Firefox. I think that it'd be worth exploring these different allocators
> and see if any of them offers significant performance improvements for
> Wesnoth. (Actually doing something like this seems like a nice example of
> an achievable GSoC project to me).

I'm not sure whether this kind of tasks belongs to GSoC. I always thought (or 
maybe I was told so at some point) that the program was more about producing a 
substantial amount of lines of code for open-source software while being paid. 
Assuming other custom allocators are set up in a similar fashion, wouldn't 
this just require choosing the right library and doing a lot of benchmarking 
and regression testing work rather than actual programming?

--

-- 
Regards
  Ignacio Riquelme Morelle <shadowmaster>

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev