* Add three way lower_bound
@ 2021-06-23 20:34 François Dumont
2022-09-01 5:01 ` François Dumont
2022-09-01 6:47 ` Jonathan Wakely
0 siblings, 2 replies; 5+ messages in thread
From: François Dumont @ 2021-06-23 20:34 UTC (permalink / raw)
To: libstdc++
[-- 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());
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Add three way lower_bound
2021-06-23 20:34 Add three way lower_bound François Dumont
@ 2022-09-01 5:01 ` François Dumont
2022-09-01 6:47 ` Jonathan Wakely
1 sibling, 0 replies; 5+ messages in thread
From: François Dumont @ 2022-09-01 5:01 UTC (permalink / raw)
To: libstdc++; +Cc: gcc-patches
[-- 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());
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Add three way lower_bound
2021-06-23 20:34 Add three way lower_bound François Dumont
2022-09-01 5:01 ` François Dumont
@ 2022-09-01 6:47 ` Jonathan Wakely
2022-09-01 6:47 ` Jonathan Wakely
2022-09-07 4:53 ` François Dumont
1 sibling, 2 replies; 5+ messages in thread
From: Jonathan Wakely @ 2022-09-01 6:47 UTC (permalink / raw)
To: François Dumont; +Cc: libstdc++
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
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Add three way lower_bound
2022-09-01 6:47 ` Jonathan Wakely
@ 2022-09-01 6:47 ` Jonathan Wakely
2022-09-07 4:53 ` François Dumont
1 sibling, 0 replies; 5+ messages in thread
From: Jonathan Wakely @ 2022-09-01 6:47 UTC (permalink / raw)
To: François Dumont; +Cc: libstdc++
[-- 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
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Add three way lower_bound
2022-09-01 6:47 ` Jonathan Wakely
2022-09-01 6:47 ` Jonathan Wakely
@ 2022-09-07 4:53 ` François Dumont
1 sibling, 0 replies; 5+ messages in thread
From: François Dumont @ 2022-09-07 4:53 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: libstdc++
[-- 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;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-09-07 4:53 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-23 20:34 Add three way lower_bound François Dumont
2022-09-01 5:01 ` François Dumont
2022-09-01 6:47 ` Jonathan Wakely
2022-09-01 6:47 ` Jonathan Wakely
2022-09-07 4:53 ` François Dumont
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).