Message ID | 20141217184219.A76452C3AA0@topped-with-meat.com |
---|---|
State | New |
Headers | show |
On Wed, Dec 17, 2014 at 10:42:19AM -0800, Roland McGrath wrote: > 2014-12-17 Roland McGrath <roland@hack.frob.com> > > * malloc/malloc.c (alloc_perturb, free_perturb): Remove inline keyword. > Roland, did you ran benchtest before commiting that? You caused a 5% performance regression on malloc microbenchmark when using gcc version 4.4.7 (Debian 4.4.7-8)
On Tue, Jan 13, 2015 at 02:58:06PM -0800, Roland McGrath wrote: > > On Wed, Dec 17, 2014 at 10:42:19AM -0800, Roland McGrath wrote: > > > 2014-12-17 Roland McGrath <roland@hack.frob.com> > > > > > > * malloc/malloc.c (alloc_perturb, free_perturb): Remove inline keyword. > > > > > Roland, did you ran benchtest before commiting that? > > No. What I did verify is that on x86_64-linux-gnu with gcc 4.8.2 (Ubuntu > 4.8.2-19ubuntu1), where the warning was not produced beforehand, it did > not change the generated code. > > > You caused a 5% performance regression on malloc microbenchmark when > > using gcc version 4.4.7 (Debian 4.4.7-8) > > I assume you're talking about x86_64-linux-gnu, but you should be > clear when citing such things (in fact, you should probably say > something about the hardware, since the results might be quite > different even with the same compiler on different hardware). > > That is older than the minimum required to build 2.21 (which is 4.6). > Even if it were true with 4.6, I'm not convinced we should care. It's > always going to be the case that not all compiler vintages will > produce good code from the same source. We need to be able to move > forward with cleanups and new best practices and not worry overmuch > about building libc with compilers that are very old. As of now, I'd > say that anything that is suboptimal with a compiler older than 4.8 > but just fine with 4.8 or newer is something we should not be worrying > about. > No Roland, this does work only by chance, how can you know that gcc-5.2 would decide not to inline these again? You cannot get always get correct decision without profile feedback which improves performance by 10% on decisions like this.
--- a/malloc/malloc.c +++ b/malloc/malloc.c @@ -1854,14 +1854,14 @@ static int check_action = DEFAULT_CHECK_ACTION; static int perturb_byte; -static inline void +static void alloc_perturb (char *p, size_t n) { if (__glibc_unlikely (perturb_byte)) memset (p, perturb_byte ^ 0xff, n); } -static inline void +static void free_perturb (char *p, size_t n) { if (__glibc_unlikely (perturb_byte))