Hi!

I created a few simple test cases to be able to show what would be
gained by using the set of unstable_* functions since I didn’t have my
old tests saved.

I’m not sure what’s changed since I wrote the functions, but their
performance is really bad. Only with very contrived data sets will they
outperform the “stable” versions. I assume cache locality explains most
of the difference. I must have been testing them with some bias back
then or used an ancient computer :)

Anyway, I no longer think they are such a good idea.

Kind regards,
Ted Lyngmo

Den 2025-01-30 kl. 23:50, skrev Ted Lyngmo:
> Jens Maurer via Std-Proposals:
>>
>> It was discussed in LEWG in Kona 2015.
>>
>> The poll said "nay", partly because the performance numbers in the paper
>> were unconvincing. Maybe the testcase wasn't good, or the size of the
>> array wasn't large enough or whatever.
>>
>> So, if you can demonstrate an actual (measurable) benefit compared to
>> the alternatives, LEWG ought to get interested (again).
> Thanks! I'll try to put something together using https://quick-
> bench.com/ during the weekend. It was a long ago I wrote this and I
> didn't keep the measurements did back then.
>
>> Sebastian Wittmeier via Std-Proposals:
>>> You might like to compare/contrast your https://github.com/TedLyngmo/
>>> liblyncpp/blob/main/include/lyn/algorithm.hpp#L17-L35
>>> with https://github.com/Quuxplusone/SG14/blob/master/include/sg14/
>>> algorithm_ext.h#L68-L130
>
> I've now looked at it and I think the two implementations do exactly the
> same operations to get it done, so, that's encouraging at least. :)
>
> Note: After the comment about bidirectional iterators being required for
> this to work, I opted to add a fallback to `std::remove_if` for
> iterators that are not bidirectional. I'd be fine with asserting that
> they are in fact bidirectional instead if that would be more in line
> with what expectations a user might have.
>
> Kind regards,
> Ted Lyngmo