Por que coreutils é mais lento que Python?

Eu escrevi o seguinte script para testar a velocidade da funcionalidade de classificação do Python:

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

Comparei isso com o sortcomando coreutils em um arquivo contendo 10 milhões de linhas:

$ 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

O comando interno usou todas as quatro CPUs (Python usou apenas uma), mas levou cerca de três vezes mais tempo para ser executado! O que da?

Estou usando o Ubuntu 12.04.5 (32 bits), Python 2.7.3 e sort8.13

O comentário de Izkata revelou a resposta: comparações específicas de localidade. O sortcomando usa o código do idioma indicado pelo ambiente, enquanto o Python usa como padrão uma comparação de ordem de bytes. Comparar cadeias de caracteres UTF-8 é mais difícil do que comparar cadeias de bytes.

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

Que tal isso.

Isso é mais uma análise extra do que uma resposta real, mas parece variar dependendo dos dados que estão sendo classificados. Primeiro, uma leitura básica:

$ 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 é muito mais rápido. No entanto, você pode sortacelerar o coreutils dizendo para ordenar 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

Isso é muito mais rápido, mas o python ainda vence por uma ampla margem. Agora, vamos tentar novamente, mas com uma lista não classificada de 1 milhão de números:

$ 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

O coreutils sort -né mais rápido para dados numéricos não classificados (embora você possa ajustar o cmpparâmetro da classificação python para torná-lo mais rápido). Coreutils sortainda é significativamente mais lento sem a -nbandeira. Então, e os caracteres aleatórios, não os números puros?

$ 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

O Python ainda supera os coreutils, mas por uma margem muito menor do que o que você mostra na sua pergunta. Surpreendentemente, ainda é mais rápido quando se olha para dados alfabéticos puros:

$ 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

Também é importante observar que os dois não produzem a mesma saída classificada:

$ 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

Curiosamente, a --buffer-sizeopção não pareceu fazer muita (ou nenhuma) diferença nos meus testes. Em conclusão, presumivelmente por causa dos diferentes algoritmos mencionados na resposta do goldilock, o python sortparece ser mais rápido na maioria dos casos, mas o GNU numérico osort supera em números não classificados ¹ .

O OP provavelmente encontrou a causa raiz, mas, para fins de completude, aqui está uma comparação final:

$ 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

¹ _{Alguém com mais python-fu do que eu deveria tentar testar os ajustes list.sort()para ver a mesma velocidade pode ser alcançado especificando o método de classificação.}

Ambas as implementações estão em C, portanto, há condições iguais. sort Aparentemente, Coreutils usa o algoritmo mergesort . O Mergesort faz um número fixo de comparações que aumenta logaritmicamente com o tamanho da entrada, ou seja, O grande (n log n).

A classificação do Python usa uma classificação híbrida exclusiva de inserção / mesclagem, timsort , que fará um número variável de comparações com o melhor cenário de O (n) - presumivelmente, em uma lista já classificada - mas geralmente é logarítmica (logicamente, você não pode ser melhor que logarítmico para o caso geral ao classificar).

Dados dois tipos logarítmicos diferentes, um pode ter uma vantagem sobre o outro em alguns conjuntos de dados específicos. Uma classificação de mesclagem tradicional não varia, portanto, o mesmo será executado independentemente dos dados, mas, por exemplo, o quicksort (também logarítmico), que varia, terá um desempenho melhor em alguns dados, mas pior em outros.

Um fator de três (ou mais de 3, uma vez que sorté paralelo) é bastante, o que me faz pensar se não há alguma contingência aqui, como a sorttroca para o disco (a -Topção parece implicar). No entanto, seu baixo sistema versus tempo de usuário implica que esse não é o problema.