Sort --parallel não está em paralelização

Question

Eu estou tentando fazer um conjunto único de linhas extraídas de um arquivo com egrep com sort -u, e depois contá-las. Cerca de 10% das linhas (todos os 100 caracteres do alfabeto [ATCG]) são duplicados. Existem dois arquivos, cerca de 3 GB cada, 50% não são relevantes, talvez 300 milhões de linhas.

LC_ALL=C  grep -E  <files> |  sort --parallel=24  -u | wc -m

Entre LC_ALL = C e usando -x para acelerar o grep, a parte mais lenta é de longe o tipo. Ler as man pages me levou a - parallel = n, mas a experimentação não mostrou nenhuma melhoria. Um pouco de escavação com a parte superior mostrou que, mesmo com --parallel = 24, o processo de classificação só é executado em um processador por vez.

Eu tenho 4 chips com 6 núcleos e 2 threads / core, dando um total de 48 processadores lógicos. Veja lscpu porque / proc / cpuinfo seria muito longo.

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                48
On-line CPU(s) list:   0-47
Thread(s) per core:    2
Core(s) per socket:    6
Socket(s):             4
NUMA node(s):          8
Vendor ID:             AuthenticAMD
CPU family:            21
Model:                 1
Stepping:              2
CPU MHz:               1400.000
BogoMIPS:              5199.96

O que estou perdendo? Mesmo que o processo seja vinculado a E / S, não devo ver o processamento paralelo? O processo de ordenação usa 99% do processador em que ele está realmente ligado a qualquer momento, então eu deveria ser capaz de ver a paralelização se isso estiver acontecendo. A memória não é uma preocupação, eu tenho 256 Gb para brincar e nada disso é usado por qualquer outra coisa.

Algo que eu descobri pipp grep para um arquivo, em seguida, lendo o arquivo com ordenação:

 LC_ALL=C  grep -E  <files>  > reads.txt ; sort reads.txt  -u | wc -m

default, file 1m 50s
--parallel=24, file 1m15s
--parallel=48, file 1m6s
--parallel=1, no file 10m53s
--parallel=2, no file 10m42s
--parallel=4 no file 10m56s

others still running

Ao fazer esses benchmarks, fica bem claro que quando o ordenado input input não está em paralelo. Quando é permitido ler um arquivo, o tipo divide a carga conforme instruído.

    

Answer 1

O

sort não cria um thread a menos que seja necessário, e para arquivos pequenos é apenas uma sobrecarga excessiva. Agora, infelizmente, o sort trata um pipe como um arquivo pequeno. Se você quer alimentar dados suficientes para 24 threads, então você precisa especificar para classificar para usar um grande buffer interno (o tipo faz isso automaticamente quando apresentado com arquivos grandes). Isso é algo que devemos melhorar no upstream (pelo menos na documentação). Então você vai querer algo como:

(export LC_ALL=C; grep -E  <files> | sort -S1G --parallel=24 -u | wc -m)

Note que configurei LC_ALL = C para todos os processos, pois todos eles se beneficiarão com esses dados).

BTW, você pode monitorar os tópicos de classificação com algo como:

watch -n.1 ps -C sort -L -o pcpu