This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v3] benchtests: Add malloc microbenchmark
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 25 Jun 2014 11:29:26 +0200
- Subject: Re: [PATCH v3] benchtests: Add malloc microbenchmark
- Authentication-results: sourceware.org; auth=none
- References: <1403196368-26785-1-git-send-email-will dot newton at linaro dot org>
On Thu, Jun 19, 2014 at 05:46:08PM +0100, Will Newton wrote:
> Add a microbenchmark for measuring malloc and free performance with
> varying numbers of threads. The benchmark allocates and frees buffers
> of random sizes in a random order and measures the overall execution
> time and RSS. Variants of the benchmark are run with 1, 4, 8 and
> 16 threads.
> The random block sizes used follow an inverse square distribution
> which is intended to mimic the behaviour of real applications which
> tend to allocate many more small blocks than large ones.
> 2014-06-19 Will Newton <firstname.lastname@example.org>
> * benchtests/Makefile: (bench-malloc): Add malloc thread
> scalability benchmark.
> * benchtests/bench-malloc-threads.c: New file.
> benchtests/Makefile | 20 ++-
> benchtests/bench-malloc-thread.c | 299 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 316 insertions(+), 3 deletions(-)
> create mode 100644 benchtests/bench-malloc-thread.c
> Changes in v3:
> - Single executable that takes a parameter for thread count
> - Run for a fixed duration rather than a fixed number of loops
> - Other fixes in response to review suggestions
> Example of a plot of the results versus tcmalloc and jemalloc on
> a 4 core i5:
That graph looks interesting. It is little weird that in libc a 2 and
three thread take nearly same time but not when you use four thread one.
For other allocators a dependency is linear. How could you explain that?