Re: howto use malloc instead of the internal memory allocator

On 9 January 2015 at 17:54, Bradley C. Kuszmaul <[email protected]> wrote:

> Hi ghostscripters,
>
> I'm benchmarking malloc(), and I'm asking you for help for benchmarking
> malloc() with ghostscript.
>
> Historically, papers about new implementations of malloc have benchmarked
> ghostscript (along with many other experiments).  They have had some
> trouble measuring performance, since ghostscript uses its own allocator.
> For example Evans06 says (
> http://people.freebsd.org/~jasone/jemalloc/bsdcan2006/jemalloc.pdf)
>
> > gs overwhelmingly allocates either 240-byte objects or large objects,
> since it uses a custom allocator
> > internally. As a result, this benchmark stresses performance of large
> object allocation.
>
> I was wondering if there is any way to convince gs to simply call malloc()
> and free() for every object it wants, instead of using its internal
> allocator.  I've looked (briefly) at the code in gsmalloc.c and gsmemory.c,
> and it's not clear whether this is reasonable idea. The comments talk about
> garbage collection and object relocation, so maybe it's just infeasible to
> think of calling malloc() and free() on every object.
>
> So here are my questions:
>  1) Is the internal allocator in ghostscript used primarily for
> performance, or for features such as garbage collection?
>

Both. We have a "chunk allocator" which effectively caches allocations from
a parent allocator (that allocator maybe be the lowest level "heap"
allocator, i.e, malloc/free, or maybe another allocator instance internal
to gs), and we also have a garbage collecting memory manager.


 2) Would it be possible to use malloc/free more heavily so that I can find
> out how much of a performance difference there is?  How would I do that?
>

It is possible but, primarily because of the garbage collector, there's no
way to avoid the management overhead of the internal memory manager, so the
performance hit is *huge*.

Basically, you would hack the chunk memory manager (in base/gsmchunk.c) to
simply return the "parent" allocator passed to it, and to do nothing when
the chunk allocator instance is shut down.

Then, in base/gsalloc.c, around line 222, use the setting of
"iimem->large_size = 1;" (it's already there for our internal memory
debugging tool "memento".

That *should* get every object allocated into it's own chunk (from malloc),
and each chunk freed again when the object it contains is freed.

As I said, the performance hit to Ghostscript is *huge*, so not sure how
much use it will be.

Chris

_______________________________________________
gs-devel mailing list
[email protected]
http://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel