public inbox for libstdc++@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).