This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Simple malloc benchtest.
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: Will Newton <will dot newton at linaro dot org>
- Cc: =?ISO-8859-2?B?T25k+GVqIELtbGth?= <neleai at seznam dot cz>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Sat, 21 Dec 2013 16:47:36 -0500
- Subject: Re: [PATCH] Simple malloc benchtest.
- Authentication-results: sourceware.org; auth=none
- References: <20131221153303 dot GA8420 at domone dot podge> <CANu=DmiknJbnr0donGEEyG__o1Unpd7iEjeQ1LSEpv_vJNO1TA at mail dot gmail dot com>
Will Newton <will.newton@linaro.org> writes:
> [...] It looks like you are using uniformly distributed random
> numbers for allocation sizes. This doesn't necessarily bear any
> relation to what actual allocation sizes are used in a real
> application [...] This means we run through doing a long stream of
> malloc and then a long stream of free. That is again not close to
> application behaviour so I would recommend we interleave malloc and
> free calls in order to introduce some stress on the allocator.
Instead of making up ad-hoc microbenchmarks, how about tracing the
malloc/free traffic of a real application or a dozen, and using an
amalgam of such large traces to drive the measurements? (Insert
cache-invalidation between operations as indicated by e.g. cachegrind
or timestamps.)
- FChE