[squid-dev] Fwd: [PATCH] for loops modernization

[Alex Rousskov]

On 03/16/2017 11:00 AM, khaled belhout wrote:
> but we need to annotate the some functions with [[noreturn]] attribute like :

I do not think such annotations belong to the source code. If we add
various annotations for various tools, the code readability and
maintainability will suffer.

AFAIK, Coverity can be told which functions never return without
changing source code. Perhaps your tool supports that as well? If not,
request that essential tool feature (meanwhile consider automatically
patching your annotations in before running your code analysis; there
are not so many of them...).


> i hit a problem with xassert in: src/debug.cc
> print the debug massage ,never return if shutting_down flag is clear
> and return if shutting_down flag is set!

FWIW, I have been bitten by this shutting_down exception in xassert() as
well during triage. While I am sure it is helpful in some situations, I
think that special condition is a bug that should be removed so that
Squid always aborts when an assertion fails.

Alex.



> 2017-03-16 6:34 GMT+01:00 Amos Jeffries <squid3 at treenet.co.nz>:
>> On 16/03/2017 3:43 a.m., Adam Majer wrote:
>>> On 03/15/2017 03:17 PM, Amos Jeffries wrote:
>>>> Theoretically range-for loops should allow multi-threaded CPU to run
>>>> those loops a bit faster. If that can be demonstrated using a tool like
>>>> polygraph you have a good argument for a patch containing that change to
>>>> go in as a pure performance change.
>>>
>>> No. That would break many many things. There are special directives that
>>> allow this to happen with things like OpenMPI compilers, but that's not
>>> what we are talking about here.
>>>
>>> And theoretically, if you blindly allow compilers to optimize loops like
>>> that, you are just as likely to introduce hardware stalls that will
>>> result in slower execution of the overall loop. The only way to look at
>>> these,
>>>
>>>     for (TYPE _i : _c )
>>>
>>> is syntactic sugar.
>>>
>>>
>>> Best regards,
>>> - Adam
>>>
>>> PS. And if you are talking about vertorization of these loops, that
>>> already happens with regular loops. See,
>>>
>>>     https://gcc.gnu.org/projects/tree-ssa/vectorization.html
>>
>> I mean tricks like compiler with CPU-specific knowledge being able to
>> emit assembly that helps pre-fetch the address pointers for all objects
>> in the container, and/or if it can prove the objects are read-only can
>> have hyper-threads pre-load the container contents into L1/L2 cache in
>> time for the main thread to run the business logic faster without much
>> loading delays.
>>
>> AFAIK the range-for does allow certain code flow guarantees (like
>> full-length container iteration) being known without any analysis. So
>> not completely syntactic sugar. Yes compiler could do the same with
>> traditional loops, but only after extra analysis which might be turned off.
>>
>> I'm not sure if thus would have any visible effect at all. We might be
>> unlucky in that these things are not supportable, or the data sizes
>> Squid handles blow the benefits away. Thus the request for proof.
>>
>> Amos
>>
>> _______________________________________________
>> squid-dev mailing list
>> squid-dev at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-dev
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>