This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] benchtests: Add malloc microbenchmark


On Tue, Jun 10, 2014 at 07:23:01PM +0200, OndÅej BÃlka wrote:
> There is limited amount of criteria that you consider for comparison,
> some are more important than others and this is not very important. 
> 
> A more pressing criteria are measuring a running time of gcc
> compilation. Currently if you replace allocator by tcmalloc then running
> time improves by 10% which is huge. Decreasing gaps like that should be
> top priority.

I really don't think gcc compilation passes is a representative case
for malloc performance, but I'll pass on that since we won't really
reach agreement on what kinds of applications can be considered
representative.

> Then there are possible optimizations of cache locality, prefectching
> and so on for which evaluation you need separate bencmark.
> 
> For patches there will almost always be overriding concern like this and
> numbers from uncontended performance would be rigthfully ignored.

I don't think there's any disagreement on the fact that there are a
large number of cases to consider when benchmarking malloc (the same
point holds for string benchmarks).  The question here though is
whether this is a decent starting point.  Work on malloc benchmark
doesn't end here, it's about to begin.

> You do benchmarks to compare memory usage. When allocation pattern stays fixed
> and algorithm to determine address is also fixed then you will get constant as 
> you said. But then you should omit it as it does not matter.
> 
> And natural question when you change algorithm in way that changes
> allocation pattern how would you check these. Here a specialized
> benchmarks are necessary than one that does comparison badly and would
> be ignored in most of cases.

Agreed, but I don't think it makes sense to wait to commit the first
iteration till all cases raised by everyone are addressed.  Lets take
this as a starting point and build on it.  In fact it might even be a
good idea to get the malloc benchmarks into their own directory within
benchtests.  Likewise for the string benchmarks.

Siddhesh

Attachment: pgpf5xbnyFeR5.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]