[-- Attachment #1: Type: text/plain, Size: 665 bytes --] Hi Following the message to propose an alternative lower_bound and the reply to use three way comparison I try to implement this. Before going further I wonder if this is something possible ? The purpose of the: if constexpr (three_way_comparable<>) is to make sure that we use it only if there is a proper <=> operator defined. Afai understood what is in <compare> we can have the __synth3way for any type as long as < exist. But I think that if <=> is implemented in terms of < then it might be too expensive, the actual lower_bound might already be implemented this way. My main concerns is of course Standard conformity, could it be ok ? François [-- Attachment #2: lower_bound_three_way.patch --] [-- Type: text/x-patch, Size: 2081 bytes --] diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h index d001b5f9dae..3ccb3c0301b 100644 --- a/libstdc++-v3/include/bits/stl_algobase.h +++ b/libstdc++-v3/include/bits/stl_algobase.h @@ -1473,6 +1473,48 @@ _GLIBCXX_END_NAMESPACE_CONTAINER return __first; } +#if __cpp_lib_three_way_comparison + template<typename _ForwardIterator, typename _Tp, typename _Compare> + _GLIBCXX20_CONSTEXPR + _ForwardIterator + __lower_bound_three_way(_ForwardIterator __first, _ForwardIterator __last, + const _Tp& __val, _Compare __comp) + { + auto __len = std::distance(__first, __last); + + while (__len > 0) + { + auto __half = __len >> 1; + if (__half == 0) + { + if (auto __c = __comp(*__first, __val); __c < 0) + return std::next(__first); + return __first; + } + + _ForwardIterator __prev_mid = __first; + std::advance(__prev_mid, __half - 1); + _ForwardIterator __middle = std::next(__prev_mid); + if (auto __c = __comp(*__middle, __val); __c != 0) + { + if (__c < 0) + { + __first = __middle; + ++__first; + __len = __len - __half - 1; + } + else + __len = __half; + } + else if (__c = __comp(*__prev_mid, __val); __c != 0) + return __middle; + else // __c == 0. + __len = __half - 1; + } + return __first; + } +#endif + /** * @brief Finds the first position in which @a val could be inserted * without changing the ordering. @@ -1496,6 +1538,13 @@ _GLIBCXX_END_NAMESPACE_CONTAINER typename iterator_traits<_ForwardIterator>::value_type, _Tp>) __glibcxx_requires_partitioned_lower(__first, __last, __val); +#if __cpp_lib_three_way_comparison + if constexpr (three_way_comparable_with< + typename iterator_traits<_ForwardIterator>::reference, + const _Tp&>) + return std::__lower_bound_three_way(__first, __last, __val, + compare_three_way{}); +#endif return std::__lower_bound(__first, __last, __val, __gnu_cxx::__ops::__iter_less_val()); }
[-- Attachment #1: Type: text/plain, Size: 844 bytes --] Any feedback regarding this proposal: https://gcc.gnu.org/pipermail/libstdc++/2021-June/052821.html On 23/06/21 22:34, François Dumont wrote: > Hi > > Following the message to propose an alternative lower_bound and the > reply to use three way comparison I try to implement this. > > Before going further I wonder if this is something possible ? > > The purpose of the: > > if constexpr (three_way_comparable<>) > > is to make sure that we use it only if there is a proper <=> operator > defined. Afai understood what is in <compare> we can have the > __synth3way for any type as long as < exist. But I think that if <=> > is implemented in terms of < then it might be too expensive, the > actual lower_bound might already be implemented this way. > > My main concerns is of course Standard conformity, could it be ok ? > > François > [-- Attachment #2: lower_bound_three_way.patch --] [-- Type: text/x-patch, Size: 2081 bytes --] diff --git a/libstdc++-v3/include/bits/stl_algobase.h b/libstdc++-v3/include/bits/stl_algobase.h index 84a1f9e98f6..7a0c42a4909 100644 --- a/libstdc++-v3/include/bits/stl_algobase.h +++ b/libstdc++-v3/include/bits/stl_algobase.h @@ -1472,6 +1472,48 @@ _GLIBCXX_END_NAMESPACE_CONTAINER return __first; } +#if __cpp_lib_three_way_comparison + template<typename _ForwardIterator, typename _Tp, typename _Compare> + _GLIBCXX20_CONSTEXPR + _ForwardIterator + __lower_bound_three_way(_ForwardIterator __first, _ForwardIterator __last, + const _Tp& __val, _Compare __comp) + { + auto __len = std::distance(__first, __last); + + while (__len > 0) + { + auto __half = __len >> 1; + if (__half == 0) + { + if (auto __c = __comp(*__first, __val); __c < 0) + return std::next(__first); + return __first; + } + + _ForwardIterator __prev_mid = __first; + std::advance(__prev_mid, __half - 1); + _ForwardIterator __middle = std::next(__prev_mid); + if (auto __c = __comp(*__middle, __val); __c != 0) + { + if (__c < 0) + { + __first = __middle; + ++__first; + __len = __len - __half - 1; + } + else + __len = __half; + } + else if (__c = __comp(*__prev_mid, __val); __c != 0) + return __middle; + else // __c == 0. + __len = __half - 1; + } + return __first; + } +#endif + /** * @brief Finds the first position in which @a val could be inserted * without changing the ordering. @@ -1495,6 +1537,13 @@ _GLIBCXX_END_NAMESPACE_CONTAINER typename iterator_traits<_ForwardIterator>::value_type, _Tp>) __glibcxx_requires_partitioned_lower(__first, __last, __val); +#if __cpp_lib_three_way_comparison + if constexpr (three_way_comparable_with< + typename iterator_traits<_ForwardIterator>::reference, + const _Tp&>) + return std::__lower_bound_three_way(__first, __last, __val, + compare_three_way{}); +#endif return std::__lower_bound(__first, __last, __val, __gnu_cxx::__ops::__iter_less_val()); }
On Wed, 23 Jun 2021, 21:34 François Dumont via Libstdc++, < libstdc++@gcc.gnu.org> wrote: > Hi > > Following the message to propose an alternative lower_bound and the > reply to use three way comparison I try to implement this. > > Before going further I wonder if this is something possible ? > > The purpose of the: > > if constexpr (three_way_comparable<>) > > is to make sure that we use it only if there is a proper <=> operator > defined. Afai understood what is in <compare> we can have the > __synth3way for any type as long as < exist. But I think that if <=> is > implemented in terms of < then it might be too expensive, the actual > lower_bound might already be implemented this way. > > My main concerns is of course Standard conformity, could it be ok ? > I don't think so. For a built-in type like int I don't think using <=> will be faster. For a class type type with overloaded operator< it's observable whether it gets called or not, so this patch would be a change in observable behaviour. I think we have to use < instead. > François > >
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --] On Wed, 23 Jun 2021, 21:34 François Dumont via Libstdc++, < libstdc++@gcc.gnu.org> wrote: > Hi > > Following the message to propose an alternative lower_bound and the > reply to use three way comparison I try to implement this. > > Before going further I wonder if this is something possible ? > > The purpose of the: > > if constexpr (three_way_comparable<>) > > is to make sure that we use it only if there is a proper <=> operator > defined. Afai understood what is in <compare> we can have the > __synth3way for any type as long as < exist. But I think that if <=> is > implemented in terms of < then it might be too expensive, the actual > lower_bound might already be implemented this way. > > My main concerns is of course Standard conformity, could it be ok ? > I don't think so. For a built-in type like int I don't think using <=> will be faster. For a class type type with overloaded operator< it's observable whether it gets called or not, so this patch would be a change in observable behaviour. I think we have to use < instead. > François > >
[-- Attachment #1.1: Type: text/plain, Size: 1547 bytes --] On 01/09/22 08:47, Jonathan Wakely wrote: > > > On Wed, 23 Jun 2021, 21:34 François Dumont via Libstdc++, > <libstdc++@gcc.gnu.org <mailto:libstdc%2B%2B@gcc.gnu.org>> wrote: > > Hi > > Following the message to propose an alternative lower_bound and the > reply to use three way comparison I try to implement this. > > Before going further I wonder if this is something possible ? > > The purpose of the: > > if constexpr (three_way_comparable<>) > > is to make sure that we use it only if there is a proper <=> operator > defined. Afai understood what is in <compare> we can have the > __synth3way for any type as long as < exist. But I think that if > <=> is > implemented in terms of < then it might be too expensive, the actual > lower_bound might already be implemented this way. > > My main concerns is of course Standard conformity, could it be ok ? > > > > I don't think so. For a built-in type like int I don't think using <=> > will be faster. I could not believe it so I wrote the small bench attached and it turns out that indeed, performance are very bad. In pre- <=> mode: lower_bound.cc-thread lower_bound (int) 657r 657u 0s 0mem 0pf With <=> support: lower_bound.cc-thread lower_bound (int) 8621r 8620u 0s 0mem 0pf Now I wonder if it is <=> implementation that is making it so bad, I'll try to find out. Thanks for the feedback François [-- Attachment #2: lower_bound.cc --] [-- Type: text/x-c++src, Size: 647 bytes --] #include <algorithm> #include <testsuite_performance.h> int main() { using namespace __gnu_test; using namespace std; time_counter time; resource_counter resource; int iarr[1000000]; for (int i = 0; i != 1000000; ++i) iarr[i] = i; int jfound = 0; start_counters(time, resource); for (int j = 0; j != 100; ++j) { int found = 0; for (int i = 0; i != 1000000; ++i) found += lower_bound(iarr + 0, iarr + 1000000, i) == iarr + i; jfound += found == 1000000; } stop_counters(time, resource); report_performance(__FILE__, "lower_bound (int)", time, resource); return jfound == 1000 ? 0 : 1; }