bug-gnulib
[Top][All Lists]
Advanced

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

Re: attributes pure and const


From: Jim Meyering
Subject: Re: attributes pure and const
Date: Tue, 26 Apr 2011 12:34:54 +0200

Bruno Haible wrote:
> 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?

My goal is not to gain performance, but rather to express more
accurately the semantics of the affected functions.  Any code size
reduction or performance improvement is merely a welcome side effect.

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

IMHO, it is no more a waste of time than adding "const"
where possible and ensuring that there are no stray,
needlessly-global declarations in a package.

> I would think that
> <http://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00232.html>
> is higher priority.

I investigated a little and reported it to the git list.
This reply makes me think a release will soon include the fix:

    http://marc.info/?l=git&m=130380478428809&w=2

I should be able to test it today.

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

Good.  Then I'll pursue that.  Thanks.



reply via email to

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