Perché coreutils è più lento di Python?

Ho scritto il seguente script per testare la velocità della funzionalità di ordinamento di Python:

from sys import stdin, stdout
lines = list(stdin)
lines.sort()
stdout.writelines(lines)

Ho quindi confrontato questo con il sortcomando coreutils su un file contenente 10 milioni di righe:

$ time python sort.py <numbers.txt >s1.txt
real    0m16.707s
user    0m16.288s
sys     0m0.420s

$ time sort <numbers.txt >s2.txt 
real    0m45.141s
user    2m28.304s
sys     0m0.380s

Il comando integrato utilizzava tutte e quattro le CPU (Python ne utilizzava solo una) ma impiegava circa 3 volte più tempo per l'esecuzione! Cosa dà?

Sto usando Ubuntu 12.04.5 (32 bit), Python 2.7.3 e sort8.13

Il commento di Izkata ha rivelato la risposta: confronti specifici del luogo. Il sortcomando utilizza le impostazioni locali indicate dall'ambiente, mentre Python utilizza per impostazione predefinita un confronto dell'ordine dei byte. Il confronto delle stringhe UTF-8 è più difficile rispetto al confronto delle stringhe di byte.

$ time (LC_ALL=C sort <numbers.txt >s2.txt)
real    0m5.485s
user    0m14.028s
sys     0m0.404s

Che ne dici di quello.

Si tratta più di un'analisi aggiuntiva che di una risposta effettiva, ma sembra variare a seconda dei dati ordinati. Innanzitutto, una lettura di base:

$ printf "%s\n" {1..1000000} > numbers.txt

$ time python sort.py <numbers.txt >s1.txt
real    0m0.521s
user    0m0.216s
sys     0m0.100s

$ time sort <numbers.txt >s2.txt
real    0m3.708s
user    0m4.908s
sys     0m0.156s

OK, Python è molto più veloce. Tuttavia, puoi rendere i coreutil sortpiù veloci dicendogli di ordinare numericamente:

$ time sort <numbers.txt >s2.txt 
real    0m3.743s
user    0m4.964s
sys     0m0.148s

$ time sort -n <numbers.txt >s2.txt 
real    0m0.733s
user    0m0.836s
sys     0m0.100s

È molto più veloce, ma Python vince ancora con un ampio margine. Ora, riproviamo ma con un elenco non ordinato di numeri 1M:

$ sort -R numbers.txt > randomized.txt

$ time sort -n <randomized.txt >s2.txt 
real    0m1.493s
user    0m1.920s
sys     0m0.116s

$ time python sort.py <randomized.txt >s1.txt
real    0m2.652s
user    0m1.988s
sys     0m0.064s

Il coreutils sort -nè più veloce per i dati numerici non ordinati (anche se potresti essere in grado di modificare il cmpparametro dell'ordinamento python per renderlo più veloce). Coreutils sortè ancora significativamente più lento senza la -nbandiera. E i personaggi casuali, non i numeri puri?

$ tr -dc 'A-Za-z0-9' </dev/urandom | head -c1000000 | 
    sed 's/./&\n/g' > random.txt

$ time sort  <random.txt >s2.txt 
real    0m2.487s
user    0m3.480s
sys     0m0.128s

$ time python sort.py  <random.txt >s2.txt 
real    0m1.314s
user    0m0.744s
sys     0m0.068s

Python batte ancora coreutils ma con un margine molto più piccolo di quello che mostri nella tua domanda. Sorprendentemente, è ancora più veloce se si osservano dati alfabetici puri:

$ tr -dc 'A-Za-z' </dev/urandom | head -c1000000 |
    sed 's/./&\n/g' > letters.txt

$ time sort   <letters.txt >s2.txt 
real    0m2.561s
user    0m3.684s
sys     0m0.100s

$ time python sort.py <letters.txt >s1.txt
real    0m1.297s
user    0m0.744s
sys     0m0.064s

È anche importante notare che i due non producono lo stesso output ordinato:

$ echo -e "A\nB\na\nb\n-" | sort -n
-
a
A
b
B

$ echo -e "A\nB\na\nb\n-" | python sort.py 
-
A
B
a
b

Stranamente, l' --buffer-sizeopzione non sembrava fare molta (o nessuna) differenza nei miei test. In conclusione, presumibilmente a causa dei diversi algoritmi menzionati nella risposta di goldilock, il pitone sortsembra essere più veloce nella maggior parte dei casi, ma GNU numericosort lo batte su numeri non ordinati ¹ .

L'OP ha probabilmente trovato la causa principale, ma per completezza, ecco un confronto finale:

$ time LC_ALL=C sort   <letters.txt >s2.txt 
real    0m0.280s
user    0m0.512s
sys     0m0.084s


$ time LC_ALL=C python sort.py   <letters.txt >s2.txt 
real    0m0.493s
user    0m0.448s
sys     0m0.044s

¹ _{Qualcuno con più python-fu di quanto dovrei provare a testare la modifica list.sort()per vedere la stessa velocità può essere raggiunto specificando il metodo di ordinamento.}

Entrambe le implementazioni sono in C, quindi condizioni di parità. Coreutils sort a quanto pare utilizza il Mergesort algoritmo. Mergesort esegue un numero fisso di confronti che aumenta logaritmicamente alla dimensione dell'input, ovvero grande O (n log n).

L'ordinamento di Python utilizza un ordinamento di unione / inserimento ibrido univoco, timsort , che eseguirà un numero variabile di confronti con uno scenario del caso migliore di O (n) - presumibilmente, in un elenco già ordinato - ma è generalmente logaritmico (logicamente, tu non può andare meglio di logaritmico per il caso generale durante l'ordinamento).

Dati due diversi tipi logaritmici, uno potrebbe avere un vantaggio rispetto all'altro su un determinato set di dati. Un ordinamento di unione tradizionale non varia, quindi funzionerà allo stesso modo indipendentemente dai dati, ma ad esempio quicksort (anche logaritmico), che varia, funzionerà meglio su alcuni dati ma peggio su altri.

Un fattore tre (o più di 3, dato che sortè parallelizzato) è piuttosto un po ', il che mi fa chiedere se non ci sia alcuna contingenza qui, come lo sortscambio su disco (l' -Topzione sembrerebbe implicare che lo faccia). Tuttavia, il tuo tempo basso rispetto al tempo dell'utente implica che questo non è il problema.