This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Simple malloc benchtest.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 23 Dec 2013 23:59:15 +0100
- Subject: Re: [PATCH] Simple malloc benchtest.
- Authentication-results: sourceware.org; auth=none
- References: <20131221153303 dot GA8420 at domone dot podge> <20131223090627 dot GF4979 at spoyarek dot pnq dot redhat dot com> <20131223095034 dot GA20816 at domone> <20131223110912 dot GG4979 at spoyarek dot pnq dot redhat dot com> <20131223133157 dot GB20816 at domone> <CAAHN_R2+N432brpObQ9RK4cJgjcqvpf+gtF7J4b1wwMShFQu7A at mail dot gmail dot com> <CAAHN_R3k-rydhVTKzV9ovC8+ykhvP+8Stx+rfZ=XbTfwBs29Lg at mail dot gmail dot com> <20131223163025 dot GA4911 at domone> <CAAHN_R0ULs9XQFuPRYMZyx1rmYbXGepQf3zB7TziLx7cmunVdA at mail dot gmail dot com>
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.