Date: Mon, 12 Apr 2021 14:40:09 -0400
> On Apr 12, 2021, at 1:34 PM, Peter Dimov via SG7 <sg7_at_[hidden]> wrote:
>
> Jean-Baptiste Vallon wrote:
>> This is true — looping over the entire members_of, with a condition
>> inside, seems to be 2-3x slower in this example:
>>
>> https://cppx.godbolt.org/z/bxGhGPfKo
>>
>> Presumably this is due to the cost of instantiating each body of the
>> `template for`, which involves considerable allocations of its own internally
>> (e.g. lots of Stmt::Create(…) inside clang).
>>
>>
>> David : I am unable to reproduce your results (the left side with a condition
>> inside the loop is faster for me, which i think wasn't what you meant?).
>> Also, the template for is not needed here, but replacing it by a simple for
>> doesn't change the result (i suppose the compiler doesn't instantiate any
>> statements since the body of the loop can simply be evaluated).
>
> Left side isn't faster for me. However, both functions return 0, which means
> something isn't right. https://cppx.godbolt.org/z/bGcP848zh
The results are indeed different today, and the fact that they are both zero indeed suggests this example is no longer measuring what we expect, if it ever was.
FWIW originally, left side consistently took ~2500-6000 ms, right side consistently took ~1000-1500 ms — and that was with me wanting to see it the other way. It would make sense that, with the additional `template for` body instantiations required, the left side would be considerably slower, were this working as expected.
It is logical that `template for` could indeed be replaced by `for`, i.e. that `template for` is just a relic from when each reflected object required its own instantiation. However I get errors when using an ordinary `for` ("constexpr variable 'men' must be initialized by a constant expression"). There are many such unexplainable errors though, so this could well just be a bug.
It would be interesting to see results with this working as expected, *and* with an ordinary `for` replacing `template for`. This should improve the left-side performance (relative to my original measurements, anyway).
Though, it occurs to me the right side may not, or at least need not, do an allocation at all - maybe `members_of(reflection, predicate)` just creates custom iterators with the predicates built in to the operator++ def? If that is the case it is at worst harmless, and if this is done internally it may well be a bit faster than the left side.
In any case as the implementations are fixed up this will be a good test to verify `members_of(reflection, predicate)` is at worst harmless, and ideally a good bit faster than the left side.
Dave
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
> Jean-Baptiste Vallon wrote:
>> This is true — looping over the entire members_of, with a condition
>> inside, seems to be 2-3x slower in this example:
>>
>> https://cppx.godbolt.org/z/bxGhGPfKo
>>
>> Presumably this is due to the cost of instantiating each body of the
>> `template for`, which involves considerable allocations of its own internally
>> (e.g. lots of Stmt::Create(…) inside clang).
>>
>>
>> David : I am unable to reproduce your results (the left side with a condition
>> inside the loop is faster for me, which i think wasn't what you meant?).
>> Also, the template for is not needed here, but replacing it by a simple for
>> doesn't change the result (i suppose the compiler doesn't instantiate any
>> statements since the body of the loop can simply be evaluated).
>
> Left side isn't faster for me. However, both functions return 0, which means
> something isn't right. https://cppx.godbolt.org/z/bGcP848zh
The results are indeed different today, and the fact that they are both zero indeed suggests this example is no longer measuring what we expect, if it ever was.
FWIW originally, left side consistently took ~2500-6000 ms, right side consistently took ~1000-1500 ms — and that was with me wanting to see it the other way. It would make sense that, with the additional `template for` body instantiations required, the left side would be considerably slower, were this working as expected.
It is logical that `template for` could indeed be replaced by `for`, i.e. that `template for` is just a relic from when each reflected object required its own instantiation. However I get errors when using an ordinary `for` ("constexpr variable 'men' must be initialized by a constant expression"). There are many such unexplainable errors though, so this could well just be a bug.
It would be interesting to see results with this working as expected, *and* with an ordinary `for` replacing `template for`. This should improve the left-side performance (relative to my original measurements, anyway).
Though, it occurs to me the right side may not, or at least need not, do an allocation at all - maybe `members_of(reflection, predicate)` just creates custom iterators with the predicates built in to the operator++ def? If that is the case it is at worst harmless, and if this is done internally it may well be a bit faster than the left side.
In any case as the implementations are fixed up this will be a good test to verify `members_of(reflection, predicate)` is at worst harmless, and ideally a good bit faster than the left side.
Dave
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
Received on 2021-04-12 13:40:16