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] |
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] |