In un corso di algoritmi standard ci viene insegnato che quicksort è in media e nel peggiore dei casi. Allo stesso tempo, vengono studiati altri algoritmi di ordinamento che sono nel peggiore dei casi (come mergesort e heapsort ), e persino il tempo lineare nel migliore dei casi (come bubblesort ) ma con qualche necessità aggiuntiva di memoria.O ( n 2 ) O ( n registro n $O(n \log n)$$O(n^2)$$O(n \log n)$

Dopo una rapida occhiata ad alcuni altri tempi di esecuzione , è naturale dire che quicksort non dovrebbe essere efficiente come altri.

Inoltre, considera che gli studenti imparano nei corsi di programmazione di base che la ricorsione non è davvero buona in generale perché potrebbe usare troppa memoria, ecc. Pertanto (e anche se questo non è un vero argomento), questo dà l'idea che Quicksort potrebbe non essere davvero buono perché è un algoritmo ricorsivo.

Perché, quindi, quicksort supera in pratica altri algoritmi di ordinamento? Ha a che fare con la struttura dei dati del mondo reale ? Ha a che fare con il modo in cui la memoria funziona nei computer? So che alcuni ricordi sono molto più veloci di altri, ma non so se questo è il vero motivo di questa performance contro-intuitiva (rispetto alle stime teoriche).

Aggiornamento 1: una risposta canonica sta dicendo che le costanti coinvolte nella del caso medio sono più piccole delle costanti coinvolte in altri algoritmi . Tuttavia, devo ancora vedere una giustificazione adeguata di ciò, con calcoli precisi anziché solo idee intuitive.O ( n registro n $O(n\log n)$$O(n\log n)$

In ogni caso, sembra che la vera differenza si verifichi, come suggeriscono alcune risposte, a livello di memoria, in cui le implementazioni sfruttano la struttura interna dei computer, utilizzando, ad esempio, che la memoria cache è più veloce della RAM. La discussione è già interessante, ma mi piacerebbe comunque vedere maggiori dettagli riguardo alla gestione della memoria, poiché sembra che la risposta abbia a che fare con essa.

Aggiornamento 2: Esistono diverse pagine Web che offrono un confronto tra algoritmi di ordinamento, alcuni più elaborati di altri (in particolare sorting-algorithms.com ). Oltre a presentare un valido aiuto visivo, questo approccio non risponde alla mia domanda.

Risposta breve

L'argomento sull'efficienza della cache è già stato spiegato in dettaglio. Inoltre, c'è un argomento intrinseco, perché Quicksort è veloce. Se implementato come con due "puntatori a incrocio", ad esempio qui , i circuiti interni hanno un corpo molto piccolo. Poiché questo è il codice eseguito più spesso, questo paga.

Risposta lunga

Prima di tutto,

Il caso medio non esiste!

Poiché il caso migliore e il caso peggiore spesso si verificano raramente nella pratica, viene eseguita un'analisi media del caso. Ma qualsiasi analisi del caso medio presuppone una certa distribuzione degli input ! Per l'ordinamento, la scelta tipica è il modello di permutazione casuale (assunto tacitamente su Wikipedia).

Perché -Notation?$O$

L'eliminazione delle costanti nell'analisi degli algoritmi viene eseguita per un motivo principale: se sono interessato a tempi di esecuzione esatti , ho bisogno di costi (relativi) di tutte le operazioni di base coinvolte (anche ignorando ancora i problemi di cache, pipeline nei processori moderni ...). L'analisi matematica può contare la frequenza con cui viene eseguita ciascuna istruzione, ma i tempi di esecuzione di singole istruzioni dipendono dai dettagli del processore, ad esempio se una moltiplicazione di numeri interi a 32 bit impiega tanto tempo quanto l'addizione.

Ci sono due modi per uscire:

1. Risolvi un modello di macchina.

   Questo viene fatto nella serie di libri di Don Knuth "The Art of Computer Programming" per un computer "tipico" artificiale inventato dall'autore. Nel volume 3 trovi risultati esatti di casi medi per molti algoritmi di ordinamento, ad es

   • Quicksort:$11.667(n+1)\ln(n)-1.74n-18.74$
   • Mergesort:$12.5 n \ln(n)$
   • Heapsort: $16 n \ln(n) +0.01n$
   • Insertionsort: ^{[ fonte ]}$2.25n^2+7.75n-3ln(n)$
     

   Questi risultati indicano che Quicksort è il più veloce. Ma è dimostrato solo sulla macchina artificiale di Knuth, non implica necessariamente nulla per dire il tuo PC x86. Si noti inoltre che gli algoritmi si riferiscono in modo diverso per input piccoli:
   
   ^{[ sorgente ]}

2. Analizzare le operazioni di base astratte .

   Per l'ordinamento basato sul confronto, in genere si tratta di scambi e confronti chiave . Nei libri di Robert Sedgewick, ad esempio "Algorithms" , questo approccio è perseguito. Lo trovi lì

   • Quicksort: confronti e swap in media$2n\ln(n)$$\frac13n\ln(n)$
   • Mergesort: confronti, ma fino a accessi array (mergesort non è basato su swap, quindi non possiamo ).8,66 n ln ( n $1.44n\ln(n)$$8.66n\ln(n)$
   • Insertionsort: confronti e scambi in media.$\frac14n^2$$\frac14n^2$

   Come vedi, questo non consente prontamente confronti di algoritmi come l'esatta analisi di runtime, ma i risultati sono indipendenti dai dettagli della macchina.

Altre distribuzioni di input

Come notato sopra, i casi medi sono sempre rispetto ad alcune distribuzioni di input, quindi si potrebbero considerare altri diversi dalle permutazioni casuali. Ad esempio è stata fatta una ricerca per Quicksort con elementi uguali e c'è un bell'articolo sulla funzione di ordinamento standard in Java

Ci sono più punti che possono essere fatti riguardo a questa domanda.

Quicksort è in genere veloce

$O(n^2)$

$n-1$$O(n \log n)$

Quicksort è in genere più veloce della maggior parte dei tipi

$O(n \log n)$$O(n^2)$$n$

$O(n \log n)$$O(\frac{n}{B} \log (\frac{n}{B}))$$B$

Il motivo di questa efficienza della cache è che analizza linearmente l'input e partiziona linearmente l'input. Ciò significa che possiamo sfruttare al massimo ogni carico della cache che facciamo mentre leggiamo tutti i numeri che cariciamo nella cache prima di scambiare quella cache con un'altra. In particolare, l'algoritmo è ignaro della cache, il che fornisce buone prestazioni della cache per ogni livello di cache, che è un'altra vittoria.

$O(\frac{n}{B} \log_{\frac{M}{B}} (\frac{n}{B}))$$M$$k$

Quicksort è in genere più veloce di Mergesort

Questo confronto riguarda completamente i fattori costanti (se consideriamo il caso tipico). In particolare, la scelta è tra una scelta non ottimale del pivot per Quicksort rispetto alla copia dell'intero input per Mergesort (o la complessità dell'algoritmo necessaria per evitare questa copia). Si scopre che il primo è più efficiente: non c'è alcuna teoria dietro questo, sembra solo essere più veloce.

$n$$O(\log n)$$O(n)$

Infine, nota che Quicksort è leggermente sensibile all'input che sembra essere nel giusto ordine, nel qual caso può saltare alcuni swap. Mergesort non ha tali ottimizzazioni, il che rende Quicksort un po 'più veloce rispetto a Mergesort.

Usa il tipo adatto alle tue esigenze

In conclusione: nessun algoritmo di ordinamento è sempre ottimale. Scegli quello che più si adatta alle tue esigenze. Se hai bisogno di un algoritmo che è il più veloce per la maggior parte dei casi e non ti dispiace che potrebbe finire per essere un po 'lento in rari casi e non hai bisogno di un ordinamento stabile, usa Quicksort. Altrimenti, usa l'algoritmo più adatto alle tue esigenze.

In uno dei tutorial di programmazione presso la mia università, abbiamo chiesto agli studenti di confrontare le prestazioni di quicksort, mergesort, insertion sort e list.sort integrato di Python (chiamato Timsort ). I risultati sperimentali mi hanno sorpreso profondamente dal fatto che list.sort integrato ha funzionato molto meglio di altri algoritmi di ordinamento, anche con istanze che hanno reso facilmente quicksort, crash di fusione. Quindi è prematuro concludere che la solita implementazione di quicksort è la migliore in pratica. Ma sono sicuro che ci sia un'implementazione molto migliore di quicksort o una versione ibrida di esso.

Questo è un bell'articolo sul blog di David R. MacIver che spiega Timsort come una forma di fusione adattiva.

Penso che uno dei motivi principali per cui QuickSort è così veloce rispetto ad altri algoritmi di ordinamento sia perché è compatibile con la cache. Quando QS elabora un segmento di un array, accede agli elementi all'inizio e alla fine del segmento e si sposta verso il centro del segmento.

Quindi, quando si avvia, si accede al primo elemento dell'array e un pezzo di memoria ("posizione") viene caricato nella cache. E quando provi ad accedere al secondo elemento, è (molto probabilmente) già nella cache, quindi è molto veloce.

Altri algoritmi come heapsort non funzionano in questo modo, saltano molto nella matrice, il che li rende più lenti.

Altri hanno già detto che l' autonomia media asintotica di Quicksort è migliore (nella costante) di quella di altri algoritmi di ordinamento (in determinate impostazioni).

$\cal{O}(n \log n)$

Nota che ci sono molte varianti di Quicksort (vedi ad esempio la tesi di Sedgewick). Si comportano diversamente su diverse distribuzioni di input (uniformi, quasi ordinate, quasi inversamente ordinate, molti duplicati, ...) e altri algoritmi potrebbero essere migliori per alcuni.

$k \approx 10$

$O(n \lg n)$

ps: per essere precisi, essere migliore di altri algoritmi dipende dal compito. Per alcune attività potrebbe essere meglio utilizzare altri algoritmi di ordinamento.

Guarda anche:

• Confronto di ordinamento rapido con altri algoritmi di ordinamento

• Confronto di heap-sort con altri algoritmi di ordinamento

$\Theta(n^2)$$\Theta(n\log n)$

Il secondo motivo è che esegue l' in-placeordinamento e funziona molto bene con ambienti di memoria virtuale.

AGGIORNAMENTO:: (Dopo i commenti di Janoma e Svick)

Per illustrare meglio ciò, lasciatemi fare un esempio usando Merge Sort (perché Merge sort è il prossimo algoritmo di ordinamento ampiamente adottato dopo l'ordinamento rapido, penso) e vi dico da dove provengono le costanti extra (al meglio delle mie conoscenze e perché penso L'ordinamento rapido è migliore):

Considera la seguente sequenza:

12,30,21,8,6,9,1,7. The merge sort algorithm works as follows:

(a) 12,30,21,8    6,9,1,7  //divide stage
(b) 12,30   21,8   6,9   1,7   //divide stage
(c) 12   30   21   8   6   9   1   7   //Final divide stage
(d) 12,30   8,21   6,9   1,7   //Merge Stage
(e) 8,12,21,30   .....     // Analyze this stage

Se ti interessa vedere come sta accadendo l'ultimo stadio, i primi 12 vengono confrontati con 8 e 8 è più piccolo, quindi inizia per primo. Ora 12 è ANCORA rispetto a 21 e 12 va avanti e così via e così via. Se prendi l'unione finale, cioè 4 elementi con altri 4 elementi, incorre in molti confronti EXTRA come costanti che NON sono sostenuti nell'ordinamento rapido. Questo è il motivo per cui si preferisce l'ordinamento rapido.

La mia esperienza di lavoro con i dati del mondo reale è che quicksort è una scelta sbagliata . Quicksort funziona bene con dati casuali, ma i dati del mondo reale spesso non sono casuali.

Nel 2008 ho rintracciato un bug del software sospeso fino all'uso di quicksort. Qualche tempo dopo ho scritto semplici impianti di inserimento tipo, quicksort, heap sort e merge sort e li ho testati. Il mio tipo di unione ha superato tutti gli altri mentre lavoravo su grandi set di dati.

Da allora, merge sort è il mio algoritmo di ordinamento preferito. È elegante. È semplice da implementare. È un tipo stabile. Non degenera in comportamenti quadratici come fa Quicksort. Passo all'ordinamento per inserzione per ordinare piccoli array.

In molte occasioni mi sono trovato a pensare che una determinata implementazione funzioni sorprendentemente bene per quicksort solo per scoprire che in realtà non è quicksort. A volte l'implementazione passa da quicksort a un altro algoritmo e talvolta non utilizza affatto quicksort. Ad esempio, le funzioni qsort () di GLibc utilizzano effettivamente l'ordinamento di tipo merge. Solo se l'allocazione dello spazio di lavoro fallisce, si ricorre al quicksort sul posto che un commento di codice chiama "l'algoritmo più lento" .

Modifica: i linguaggi di programmazione come Java, Python e Perl utilizzano anche l'ordinamento di tipo merge o, più precisamente, una derivata, come Timsort o ordinamento di tipo merge per insiemi di grandi dimensioni e ordinamento di inserzione per insiemi di piccole dimensioni. (Java utilizza anche quicksort dual-pivot che è più veloce di quicksort semplice.)

1 - L' ordinamento rapido è attivo (non richiede memoria aggiuntiva, se non un importo costante).

2 - L' ordinamento rapido è più facile da implementare rispetto ad altri algoritmi di ordinamento efficienti.

3 - L' ordinamento rapido ha fattori costanti minori nel suo tempo di esecuzione rispetto ad altri algoritmi di ordinamento efficienti.

Aggiornamento: per unire l'ordinamento, è necessario eseguire alcune "unioni", che richiedono array aggiuntivi per archiviare i dati prima di unire; ma in rapido ordine, non lo fai. Ecco perché è attivo l'ordinamento rapido. Ci sono anche alcuni confronti extra fatti per l'unione che aumentano i fattori costanti nell'unione dell'ordinamento.

In quali condizioni uno specifico algoritmo di ordinamento è effettivamente il più veloce?

$\Theta(\log(n)^2)$$\Theta(n \cdot \log(n)^2)$

$\Theta(n \cdot k)$$\Theta(n \cdot m)$$k=2^{\#number\_of\_Possible\_values}$$m = \#maximum\_length\_of\_keys$

3) La struttura dati sottostante è composta da elementi collegati? Sì -> usa sempre l'ordinamento unione in posizione. Esistono sia misure facili da implementare fisse sia adattive (ovvero naturali) dal basso verso l'alto che uniscono tipi di arità diverse per strutture di dati collegate e poiché non richiedono mai la copia di tutti i dati in ogni passaggio e non richiedono nemmeno ricorsioni, sono più veloce di qualsiasi altro tipo basato sul confronto generale, anche più veloce di un ordinamento rapido.

$\Theta(n)$

5) Le dimensioni dei dati sottostanti possono essere associate a dimensioni medio-piccole? ad es. n <10.000 ... 100.000.000 (a seconda dell'architettura e della struttura dati sottostanti)? Sì -> usa l'ordinamento bitonico o l'unione pari-dispari di Batcher. Vai a 1)

$\Theta(n)$$\Theta(n^2)$$\Theta(n \cdot \log(n)^2)$il tempo di esecuzione peggiore è noto, o forse provare a ordinare i pettini. Non sono sicuro che sia l'ordinamento della shell che quello del pettine funzionino ragionevolmente bene in pratica.

$\Theta(\log(n))$$\Theta(n)$$\Theta(n)$$\Theta(\log(n))$$\Theta(n^2)$$\Theta(n)$$\Theta(n)$$\Theta(\log(n))$$\Theta(n \cdot \log(n))$

$\Theta(n \cdot \log(n))$

Suggerimenti per l'implementazione di quicksort:

$\Theta(n)$$\Theta(\log(n))$$\Theta(n^{\log_k(k-1)})$

2) Esistono varianti iterative bottom-up e rapide di quicksort, ma AFAIK, hanno lo stesso spazio asintotico e limiti di tempo di quelli top-down, con i lati negativi aggiuntivi che sono difficili da implementare (ad esempio la gestione esplicita di una coda). La mia esperienza è che, per scopi pratici, non vale la pena considerarli.

Suggerimenti per l'implementazione di mergesort:

1) Il fusesort bottom-up è sempre più veloce del mergesort top-down, poiché non richiede chiamate di ricorsione.

2) l'unione molto ingenua può essere velocizzata usando un doppio buffer e commuta il buffer invece di copiare i dati dall'array temporale dopo ogni passaggio.

3) Per molti dati del mondo reale, il mergesort adattivo è molto più veloce di un mergesort di dimensioni fisse.

$\Theta(k)$$\Theta(\log(k))$$\Theta(1)$$\Theta(n)$

Da quello che ho scritto, è chiaro che quicksort spesso non è l'algoritmo più veloce, tranne quando si applicano tutte le seguenti condizioni:

1) ci sono più di "pochi" possibili valori

2) la struttura dati sottostante non è collegata

3) non abbiamo bisogno di un ordine stabile

4) i dati sono abbastanza grandi da far entrare il leggero runtime asintotico subottimale di uno smistatore bitonico o della fusione pari-dispari di Batcher

5) i dati non sono quasi ordinati e non sono costituiti da parti più grandi già ordinate

6) possiamo accedere simultaneamente alla sequenza di dati da più punti

$\Theta(\log(n))$$\Theta(n)$

ps: qualcuno deve aiutarmi con la formattazione del testo.

La maggior parte dei metodi di ordinamento deve spostare i dati in pochi passaggi (ad esempio, unisci ordinamento apporta modifiche localmente, quindi unisce questo piccolo pezzo di dati, quindi unisce uno più grande ...). Di conseguenza, sono necessari molti movimenti di dati se i dati sono lontani dalla sua destinazione.

$a \le b$