Re: [PATCH] Add malloc micro benchmark

[DJ Delorie <dj@redhat.com>]

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
transfer):

http://www.delorie.com/malloc/

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
> algorithms.

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.

Yup.

> 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.
Etc.

> Szabolcs or I would be happy to run the traces on AArch64.

That would be helpful :-)