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] Simple malloc benchtest.


On Mon, Dec 23, 2013 at 11:29:02PM +0530, Siddhesh Poyarekar wrote:
> On 23 December 2013 22:00, OndÅej BÃlka <neleai@seznam.cz> wrote:
> > No that would be bad first step. Tweak could look like improvement in
> > simple tests but really be a regression in real world. And if you have
> > real world data then simulated data are useless.
> 
> You're again talking about microbenchmarks vs system benchmarks, which
> is honestly just a waste of time and in this thread, it is
> contradicting your own point of introducing an initial simple
> microbenchmark.
> 
> > When you want to compare alternative allocator you need to check effects of
> > fragmentation, number of cache misses, RSS and virtual memory size and other
> > factors on hooked applications and there is no shortcut around that.
> 
> You need all this to form a complete picture of the performance of an
> allocator regardless of whether you're comparing with another
> allocator or not.  That is, ideally one ought to be looking at the
> impact of a change in an allocator on all these parameters, but you
> need to start somewhere.  I thought the intention of your patch was to
> make that start, so if you're saying that it's not useful then you're
> essentially contradicting yourself.
> 

>From original mail in thread:

"
It should be used mostly for microoptimizations that does not change how
allocations are made, this rules out effect for other factors.
"

A measurement must start somewhere but microbenchmarks is not that
place. These should be integrated directly to profiler which skips
unnecessary step of adding these to microbenchmarks, migrating them and
telling users that managed to improve score on these that they are wrong
because it will harm real workloads. There is no contradiction here.


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