Sort --parallel não está paralelizando

Estou tentando criar um conjunto exclusivo de linhas extraídas de um arquivo com egrep com sort -u e depois contá-las. Aproximadamente 10% das linhas (todos os 100 caracteres do alfabeto [ATCG]) são duplicados. Existem dois arquivos, cerca de 3 shows cada, 50% não são relevantes, portanto, 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 é a classificação. A leitura das páginas de manual me levou a --parallel = n, mas a experimentação não mostrou absolutamente nenhuma melhoria. Uma pequena escavação com top mostrou que, mesmo com --parallel = 24, o processo de classificação só é executado em um processador de cada vez.

Eu tenho 4 chips com 6 núcleos e 2 threads / core, fornecendo 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 se o processo estiver vinculado a E / S, não devo ver o processamento paralelo? O processo de classificação usa 99% do processador em que está realmente a qualquer momento, portanto, devo ver paralelismo, se estiver acontecendo. Memória não é uma preocupação, tenho 256 GB para brincar e nada disso é usado por mais nada.

Algo que descobri canalizando grep para um arquivo e depois lendo o arquivo com a classificaçã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, é bastante claro que, quando a entrada de pipeline não é paralela. Quando é permitido ler uma classificação de arquivo, a carga é dividida conforme as instruções.

A classificação não cria um encadeamento, a menos que seja necessário, e para arquivos pequenos, é muito sobrecarga. Agora, infelizmente, a classificação trata um cachimbo como um pequeno arquivo. Se você deseja alimentar dados suficientes para 24 threads, precisará especificar a classificação para usar um buffer interno grande (a classificação é feita automaticamente quando apresentada 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)

Observe que eu configurei LC_ALL = C para todos os processos, pois todos eles serão beneficiados com esses dados).

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

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