Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #70923 > unrolled thread

C++ threshold for "stupid" sorting algorithms (O(n^2))

Started bySoviet_Mario <SovietMario@CCCP.MIR>
First post2020-01-01 13:17 +0100
Last post2020-01-03 21:00 +0000
Articles 11 on this page of 51 — 12 participants

Back to article view | Back to comp.lang.c++


Contents

  C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-01 13:17 +0100
    Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-01 13:25 +0100
      Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-01 17:33 +0000
        Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 03:54 +0100
          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 04:04 +0100
          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-05 03:59 +0000
            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 05:03 +0100
              Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-05 21:13 +0100
                Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 05:50 +0100
                Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 06:55 +0100
          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-05 04:20 +0000
            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 05:26 +0100
              Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-05 13:33 +0000
                Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 15:01 +0100
                  Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-05 22:26 +0000
                    Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 05:39 +0100
                      Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-05 23:54 -0800
                        Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 08:59 +0100
                          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-06 01:02 -0800
                            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-06 09:34 +0000
                            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 10:36 +0100
                              Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-06 03:33 -0800
                                Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-06 12:59 +0100
                      Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-06 22:54 +0000
                        Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-07 04:57 +0100
                          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-07 07:51 +0000
            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-05 15:16 +0000
          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 05:50 +0100
    Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bo Persson <bo@bo-persson.se> - 2020-01-01 13:34 +0100
      Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-01 14:09 +0100
        Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bo Persson <bo@bo-persson.se> - 2020-01-01 15:16 +0100
    Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Robert Wessel <robertwessel2@yahoo.com> - 2020-01-01 09:24 -0600
      Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-01 17:12 +0100
        Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-02 15:11 -0800
      Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 13:53 -0800
        Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Robert Wessel <robertwessel2@yahoo.com> - 2020-01-10 16:45 -0600
          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 03:11 -0800
            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-21 15:04 +0000
              Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 11:52 -0800
                Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-30 00:32 +0000
                  Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 05:30 -0800
                    Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-15 16:39 +0000
    Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Christian Gollwitzer <auriocus@gmx.de> - 2020-01-02 11:28 +0100
      Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-02 19:46 +0100
        Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-02 20:00 +0100
          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 07:37 +0100
          Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-03 20:06 +0100
            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Öö Tiib <ootiib@hot.ee> - 2020-01-03 11:12 -0800
              Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Soviet_Mario <SovietMario@CCCP.MIR> - 2020-01-04 17:58 +0100
            Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) David Brown <david.brown@hesbynett.no> - 2020-01-03 21:25 +0100
              Re: C++ threshold for "stupid" sorting algorithms (O(n^2)) Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 21:00 +0000

Page 3 of 3 — ← Prev page 1 2 [3]


#71854

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-02-15 05:30 -0800
Message-ID<86eeuwgept.fsf@linuxsc.com>
In reply to#71649
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
> <cut lots>
>
> I left this a few days in the hope that I'd have something interesting
> to say about it since your post was itself interesting and clearly not
> trivial to write.  Unfortunately I failed, but such a thoughtful post
> merits a reply, even if the reply is not thoughtful.

Thanks, I appreciate the followup.

(for Ben:  I sent you an email earlier this week.  Did you get that
or did it fall through the cracks?)

[toc] | [prev] | [next] | [standalone]


#71860

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2020-02-15 16:39 +0000
Message-ID<87blpzg5yr.fsf@bsb.me.uk>
In reply to#71854
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
<cut>
> (for Ben:  I sent you an email earlier this week.  Did you get that
> or did it fall through the cracks?)

I replied a 3 days ago.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]


#70960

FromChristian Gollwitzer <auriocus@gmx.de>
Date2020-01-02 11:28 +0100
Message-ID<qukgll$52j$2@dont-email.me>
In reply to#70923
Am 01.01.20 um 13:17 schrieb Soviet_Mario:
> In your experience, what is (roughly) a reasonable threshold (n) in 
> terms of convenience of passing from stupid algorithms (bubblesort, 
> gnomesort) to better and more complex ones ?
> 
> I know this depends a lot also on HW. 
> I did not mention that the algorithm HAS TO BE "stable" : not to move 
> equally ranked items (in order to allow tables to be sorted by multiple 
> keys)

Do mergesort: it is inherently stable, rather simple and scales well for 
large sorts, too.

Christian

[toc] | [prev] | [next] | [standalone]


#70978

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2020-01-02 19:46 +0100
Message-ID<quldq1$7hb$1@dont-email.me>
In reply to#70960
On 02/01/2020 11:28, Christian Gollwitzer wrote:
> Am 01.01.20 um 13:17 schrieb Soviet_Mario:
>> In your experience, what is (roughly) a reasonable 
>> threshold (n) in terms of convenience of passing from 
>> stupid algorithms (bubblesort, gnomesort) to better and 
>> more complex ones ?
>>
>> I know this depends a lot also on HW. I did not mention 
>> that the algorithm HAS TO BE "stable" : not to move 
>> equally ranked items (in order to allow tables to be 
>> sorted by multiple keys)
> 
> Do mergesort: it is inherently stable, rather simple and 
> scales well for large sorts, too.
> 
> Christian

I'll look for it, tnx

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]


#70979

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-02 20:00 +0100
Message-ID<quleld$sna$1@news.albasani.net>
In reply to#70978
>> Do mergesort: it is inherently stable, rather simple and scales well 
>> for large sorts, too.
>> Christian

> I'll look for it, tnx

And there's std::stable_sort which is usually implemented with megesort.
With parallel_policy or parallel_unsequenced_policy it even exploits all
cores.

[toc] | [prev] | [next] | [standalone]


#70998

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-01-03 07:37 +0100
Message-ID<qumnep$35c$1@news.albasani.net>
In reply to#70979
>>> Do mergesort: it is inherently stable, rather simple and scales well 
>>> for large sorts, too.
>>> Christian

>> I'll look for it, tnx

> And there's std::stable_sort which is usually implemented with megesort.
> With parallel_policy or parallel_unsequenced_policy it even exploits all
> cores.

Here's a simple parallel mergesort in C++.
Use it as a temporary object to sort anything.

template<typename T>
struct invoke_on_destruct
{
private:
     T    &m_t;
     bool  m_enabled;

public:
     invoke_on_destruct( T &t ) :
         m_t( t ), m_enabled( true )
     {
     }

     ~invoke_on_destruct()
     {
         if( m_enabled )
             m_t();
     }

     void invoke_and_disable()
     {
         m_t();
         m_enabled = false;
     }
};

template<typename It,
          typename Cmp       = std::less<typename 
std::iterator_traits<It>::value_type>,
          typename Allocator = std::allocator<typename 
std::iterator_traits<It>::value_type>>
class merge_sort
{
private:
     using ep_allocator      = typename 
std::allocator_traits<Allocator>::template rebind_alloc<std::exception_ptr>;
     using exceptions_vector = std::vector<std::exception_ptr, 
ep_allocator>;

public:
     merge_sort( It start, It end, Cmp const &cmp = Cmp(), unsigned 
nThreads = 0, Allocator const &alloc = Allocator() );

     struct par_exception : public std::exception
     {
         using iterator = typename exceptions_vector::iterator;
         // there's no copy-constructor because of internal vector
         // so catch par_exception only via reference
         iterator begin();
         iterator end();
     private:
         friend class merge_sort;
         par_exception( exceptions_vector &&exceptions );
         exceptions_vector m_exceptions;
     };

private:
     Cmp               m_cmp;
     Allocator         m_alloc;
     // mutex that protects the exception-array
     std::mutex        m_excMtx;
     exceptions_vector m_exceptions;
     template<typename UpIt>
     void parRecursion( UpIt start, UpIt end, unsigned nThreads );
     template<typename UpIt, typename BufIt>
     void recursion( UpIt start, UpIt end, BufIt buf );
     template<typename UpIt, typename BufIt>
     void merge( UpIt start, BufIt leftBuf, BufIt rightBuf, BufIt bufEnd );
};

template<typename It, typename Cmp, typename Allocator>
merge_sort<It, Cmp, Allocator>::merge_sort( It start, It end, Cmp const 
&cmp, unsigned nThreads, Allocator const &alloc ) :
     m_cmp( cmp ),
     m_alloc( alloc ),
     m_exceptions( ep_allocator( alloc ) )
{
     using namespace std;
     // threads == 0 -> number of threads = hardware-threads
     unsigned hwThreads = thread::hardware_concurrency();
     hwThreads += hwThreads == 0;
     nThreads   = nThreads == 0 ? hwThreads : nThreads <= hwThreads ? 
nThreads : hwThreads;
     // reserve number of threads elements in the exception_ptr-vector
     // so that there will be no exception when we do emplace_back
     m_exceptions.reserve( nThreads );
     try
     {
         parRecursion( start, end, nThreads );
     }
     catch( ... )
     {
         if( m_exceptions.size() )
         {
             // additional exception catched: throw par_exception
             m_exceptions.emplace_back( current_exception() );
             throw par_exception( move( m_exceptions ) );
         }
         else
             // single exception: rethrow it
             throw;
     }
     if( m_exceptions.size() )
         if( m_exceptions.size() > 1 )
             // multiple exceptions from threads: throw par_exception
             throw par_exception( move( m_exceptions ) );
         else
             // only one exception from threads: rethrow it
             rethrow_exception( m_exceptions[0] );
}

template<typename It, typename Cmp, typename Allocator>
template<typename UpIt>
void merge_sort<It, Cmp, Allocator>::parRecursion( UpIt start, UpIt end, 
unsigned nThreads )
{
     using namespace std;
     using T = typename iterator_traits<It>::value_type;
     size_t n = end - start;
     if( nThreads <= 1 )
     {
         size_t bs = 0;
         // calculate buffer-/stack-size
         for( size_t split = n; split > 1; bs += split, split -= split / 
2 );
         vector<T, Allocator> buf( bs, T(), m_alloc );;
         recursion( start, end, buf.begin() );
     }
     else
     {
         if( n < 2 )
             return;
         // split-buffer
         vector<T, Allocator> buf( start, end, m_alloc );
         // array for left-recursion and right-recursion thread
         array<thread, 2> threads;
         // automatically join threads when an exception is thrown
         auto joinThreads = [&threads]()
         {
             for( thread &thr : threads )
                 if( thr.get_id() != thread::id() )
                     // try to join infinitely because the thread
                     // will continue to access our buffer
                     for( ; ; )
                         try
                         {
                             thr.join();
                             break;
                         }
                         catch( ... )
                         {
                         }
         };
         invoke_on_destruct iodJoin( joinThreads );
         // iterator-type for our split-buffer
         using BufIt = typename vector<T, Allocator>::iterator;
         // proxy thread-lambda for our new threads
         auto prProxy = [this]( BufIt start, BufIt end, unsigned nThreads )
         {
             try
             {
                 parRecursion( start, end, nThreads );
             }
             catch( ... )
             {
                 // remember exception in our exception-array
                 unique_lock<mutex> excLock( m_excMtx );
                 m_exceptions.emplace_back( current_exception() );
             }
         };
         unsigned rightThreads = nThreads / 2,
                  leftThreads  = nThreads - rightThreads;
         // if the left number of threads is uneven give the threads 
more input
         size_t   left         = (size_t)(n * ((double)leftThreads / 
nThreads)),
                  right        = n - left;
         BufIt    leftBuf      = buf.begin(),
                  leftBufEnd   = buf.begin() + left,
                  rightBuf     = leftBufEnd,
                  bufEnd       = buf.begin() + n;
         // start left thread
         threads[0] = move( thread( prProxy, leftBuf, leftBufEnd, 
leftThreads ) );
         if( rightThreads > 1 )
             // start right thread
             threads[1] = move( thread( prProxy, rightBuf, bufEnd, 
rightThreads ) );
         else
             // there's only one thread right, so we do it on our own
             parRecursion( rightBuf, bufEnd, 1 );
         // join threads
         iodJoin.invoke_and_disable();
         // stop if there are any exceptions from the threads
         unique_lock<mutex> excLock( m_excMtx );
         if( m_exceptions.size() )
             return;
         excLock.unlock();
         // merge split-buffer back into input-buffer
         merge( start, leftBuf, rightBuf, bufEnd );
     }
}

template<typename It, typename Cmp, typename Allocator>
template<typename UpIt, typename BufIt>
void merge_sort<It, Cmp, Allocator>::recursion( UpIt start, UpIt end, 
BufIt buf )
{
     using namespace std;
     if( end - start < 2 )
         return;
     copy( start, end, buf );
     size_t n          = end - start,
            right      = n / 2,
            left       = n - right;
     BufIt  leftBuf    = buf,
            leftBufEnd = buf + left,
            rightBuf   = leftBufEnd,
            bufEnd     = buf + n;
     recursion( leftBuf,  leftBufEnd, bufEnd );
     recursion( rightBuf, bufEnd,     bufEnd );
     merge( start, leftBuf, rightBuf, bufEnd );
}

template<typename It, typename Cmp, typename Allocator>
template<typename UpIt, typename BufIt>
void merge_sort<It, Cmp, Allocator>::merge( UpIt start, BufIt leftBuf, 
BufIt rightBuf, BufIt bufEnd )
{
     assert(leftBuf < rightBuf && rightBuf < bufEnd);
     BufIt leftBufEnd = rightBuf;
     for( UpIt wrtBack = start; ; )
         if( m_cmp( *leftBuf, *rightBuf ) )
         {
             *wrtBack++ = *leftBuf;
             if( ++leftBuf == leftBufEnd )
             {
                 // faster for small number of elements than std::copy
                 do
                     *wrtBack++ = *rightBuf;
                 while( ++rightBuf != bufEnd );
                 return;
             }
         }
         else
         {
             *wrtBack++ = *rightBuf;
             if( ++rightBuf == bufEnd )
             {
                 do
                     *wrtBack++ = *leftBuf;
                 while( ++leftBuf != leftBufEnd );
                 return;
             }
         }
}

[toc] | [prev] | [next] | [standalone]


#71047

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2020-01-03 20:06 +0100
Message-ID<quo3b8$eb4$2@dont-email.me>
In reply to#70979
On 02/01/20 20:00, Bonita Montero wrote:
>>> Do mergesort: it is inherently stable, rather simple and 
>>> scales well for large sorts, too.
>>> Christian
> 
>> I'll look for it, tnx
> 
> And there's std::stable_sort which is usually implemented 
> with megesort.
> With parallel_policy or parallel_unsequenced_policy it even 
> exploits all
> cores.


do you happen to remember in which header is that 
stable_sort declared ? I can't find it under namespace std:: 
without some proper #include ...

-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]


#71048

FromÖö Tiib <ootiib@hot.ee>
Date2020-01-03 11:12 -0800
Message-ID<f388bdc9-c435-417a-b062-d0e3b95bb94e@googlegroups.com>
In reply to#71047
On Friday, 3 January 2020 21:06:26 UTC+2, Soviet_Mario  wrote:
> On 02/01/20 20:00, Bonita Montero wrote:
> >>> Do mergesort: it is inherently stable, rather simple and 
> >>> scales well for large sorts, too.
> >>> Christian
> > 
> >> I'll look for it, tnx
> > 
> > And there's std::stable_sort which is usually implemented 
> > with megesort.
> > With parallel_policy or parallel_unsequenced_policy it even 
> > exploits all
> > cores.
> 
> 
> do you happen to remember in which header is that 
> stable_sort declared ? I can't find it under namespace std:: 
> without some proper #include ...

The <algorithm> also you need to compile in compiler set to C++17.
That perhaps means adding

    CONFIG += c++17

To your qtcreator .pro project.

[toc] | [prev] | [next] | [standalone]


#71115

FromSoviet_Mario <SovietMario@CCCP.MIR>
Date2020-01-04 17:58 +0100
Message-ID<quqg6r$kqs$1@dont-email.me>
In reply to#71048
On 03/01/20 20:12, Öö Tiib wrote:
> On Friday, 3 January 2020 21:06:26 UTC+2, Soviet_Mario  wrote:
>> On 02/01/20 20:00, Bonita Montero wrote:
>>>>> Do mergesort: it is inherently stable, rather simple and
>>>>> scales well for large sorts, too.
>>>>> Christian
>>>
>>>> I'll look for it, tnx
>>>
>>> And there's std::stable_sort which is usually implemented
>>> with megesort.
>>> With parallel_policy or parallel_unsequenced_policy it even
>>> exploits all
>>> cores.
>>
>>
>> do you happen to remember in which header is that
>> stable_sort declared ? I can't find it under namespace std::
>> without some proper #include ...
> 
> The <algorithm> also you need to compile in compiler set to C++17.
> That perhaps means adding
> 
>      CONFIG += c++17

tnx to you both

I'd have to verify if GCC installed supports such a recent 
standard.
But I guess some proper version of algorithm exist also in 
less recent version, or at least I hope


> 
> To your qtcreator .pro project.
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]


#71050

FromDavid Brown <david.brown@hesbynett.no>
Date2020-01-03 21:25 +0100
Message-ID<quo7vi$b8o$1@dont-email.me>
In reply to#71047
On 03/01/2020 20:06, Soviet_Mario wrote:
> On 02/01/20 20:00, Bonita Montero wrote:
>>>> Do mergesort: it is inherently stable, rather simple and scales well 
>>>> for large sorts, too.
>>>> Christian
>>
>>> I'll look for it, tnx
>>
>> And there's std::stable_sort which is usually implemented with megesort.
>> With parallel_policy or parallel_unsequenced_policy it even exploits all
>> cores.
> 
> 
> do you happen to remember in which header is that stable_sort declared ? 
> I can't find it under namespace std:: without some proper #include ...
> 

<https://en.cppreference.com/w/cpp/algorithm/stable_sort>

That site is an excellent reference for this sort of thing.

[toc] | [prev] | [next] | [standalone]


#71051

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2020-01-03 21:00 +0000
Message-ID<SXNPF.172491$X71.138486@fx02.am4>
In reply to#71050
On 2020-01-03, David Brown <david.brown@hesbynett.no> wrote:
> On 03/01/2020 20:06, Soviet_Mario wrote:
>> On 02/01/20 20:00, Bonita Montero wrote:
>>>>> Do mergesort: it is inherently stable, rather simple and scales well 
>>>>> for large sorts, too.
>>>>> Christian
>>>
>>>> I'll look for it, tnx
>>>
>>> And there's std::stable_sort which is usually implemented with megesort.
>>> With parallel_policy or parallel_unsequenced_policy it even exploits all
>>> cores.
>> 
>> 
>> do you happen to remember in which header is that stable_sort declared ? 
>> I can't find it under namespace std:: without some proper #include ...
>> 
>
><https://en.cppreference.com/w/cpp/algorithm/stable_sort>
>
> That site is an excellent reference for this sort of thing.

and pops up on every google search metionig cpp.
>


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

[toc] | [prev] | [standalone]


Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++


csiph-web