bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: attributes pure and const


From: Bruno Haible
Subject: Re: attributes pure and const
Date: Mon, 25 Apr 2011 14:45:52 +0200
User-agent: KMail/1.9.9

Hi Jim,

> I've started using some new gcc-4.6 options,
> by adding these lines to coreutils' configure.ac:
> 
>     +  gl_WARN_ADD([-Wsuggest-attribute=const])
>     +  gl_WARN_ADD([-Wsuggest-attribute=pure])
>     +  gl_WARN_ADD([-Wsuggest-attribute=noreturn])
> 
> I've already adjusted all of coreutils, but wanted to fix
> gnulib first

How many percent of speed can you gain by doing this?

I mean, 'const' and 'pure' optimizations can be very useful in numeric
code, especially once you have derivatives, e.g.

   f(x) = 2*sin(x)*cos(x)^3
   f'(x) = 2*sin(x)*3*cos(x)^2*-sin(x) + 2*cos(x)*cos(x)^3

But in code like gnulib or coreutils, where common subexpressions have
been extracted from loops by hand already, you gain no more performance.

So I think this is just a waste of time. I would think that
<http://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00232.html>
is higher priority.

I have been able to get speedups of more than 5% by judiciously placing
'inline' keywords before function definitions. I think that's much more
promising than providing the attributes 'pure' and 'const'.

> It seems wrong to have to define these
> 
>     __attribute__
>     _GL_ATTRIBUTE_PURE
>     _GL_ATTRIBUTE_CONST
> 
> in every compilation unit that uses these attributes.

We shouldn't define __attribute__ [1], and fortunately your patch does not
do it. _GL_ATTRIBUTE_PURE and _GL_ATTRIBUTE_CONST could be defined through
gnulib-common.m4, that's fine with me.

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00165.html
-- 
In memoriam Nikolay Gikalo <http://en.wikipedia.org/wiki/Nikolay_Gikalo>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]