This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Add malloc micro benchmark
- From: DJ Delorie <dj at redhat dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: carlos at redhat dot com, libc-alpha at sourceware dot org, nd at arm dot com
- Date: Thu, 28 Dec 2017 14:01:15 -0500
- Subject: Re: [PATCH] Add malloc micro benchmark
- Authentication-results: sourceware.org; auth=none
Wilco Dijkstra <Wilco.Dijkstra@arm.com> writes:
> Yes I'd be interested in the traces. I presume they are ISA independent and
> can just be replayed?
Yup, they're ISA-agnostic compressed pseudo-codes that run a state
machine. I put them here (except the two biggest, which take days to
Be kind, that's my house's bandwidth ;-)
The simulator is in the dj/malloc branch, in malloc/trace_run.c
> I think in many of these cases we can be far smarter and use adaptive
I'm wary of "smart" algorithms because it's so hard to generalize them
to work sufficiently well in all cases, without accidentally causing
super-stupid behavior in some unusual app.
But yeah :-)
> Longer term we need to make arena's per-thread - see below.
They're sort of per-thread now, but a lot of apps pass malloc'd memory
between threads. A strict one-per-thread isn't optimal either.
> My observation was that the gains from tcache are due to bypassing
> completely uncontended locks.
> If an arena could be marked as owned by
> a thread,
That mark would need to be an uncontended lock...
>> 2. When we say a patch "is faster", let's run all our benchmarks and
>> make sure that we don't mean "on some benchmarks." The whole point
>> of the trace/sim stuff is to make sure key downstream users aren't
>> left out of the optimization work, and end up with worse performance.
> Well you can't expect gains on all benchmarks or have a "never regress
> anything ever" rule.
Sure, I just don't want surprises. Also, benchmarks from the Real World
can be prioritized - a patch which improves a synthetic benchmark but
makes chrome worse should be rejected. A generally good patch that
makes a few apps worse should at least be investigated to find out why.
> Szabolcs or I would be happy to run the traces on AArch64.
That would be helpful :-)