Ordina - parallelo non sta parallelizzando

Sto cercando di rendere unico un insieme di linee estratte da un file con egrep con sort -u, quindi contarle. Circa il 10% delle righe (tutti i 100 caratteri dell'alfabeto [ATCG]) sono duplicati. Ci sono due file, circa 3 concerti ciascuno, il 50% non è rilevante, quindi forse 300 milioni di righe.

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

Tra LC_ALL = C e l'uso di -x per accelerare grep, la parte più lenta è di gran lunga l'ordinamento. Leggere le pagine man mi ha portato a --parallel = n, ma la sperimentazione non ha mostrato alcun miglioramento. Un piccolo scavo con top ha mostrato che anche con --parallel = 24, il processo di ordinamento viene eseguito su un solo processore alla volta.

Ho 4 chip con 6 core e 2 thread / core, per un totale di 48 processori logici. Vedi lscpu perché / proc / cpuinfo sarebbe troppo lungo.

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

Cosa mi sto perdendo? Anche se il processo è associato a IO, non dovrei comunque vedere l'elaborazione parallela? Il processo di ordinamento utilizza il 99% del processore su cui è effettivamente acceso in qualsiasi momento, quindi dovrei essere in grado di vedere la parallelizzazione se sta accadendo. La memoria non è un problema, ho 256 Gb con cui giocare e nessuno di questi viene utilizzato da nessun altro.

Qualcosa che ho scoperto convogliare grep in un file, quindi leggere il file con ordinamento:

 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

Nel fare questi benchmark è abbastanza chiaro che quando l'ordinamento dell'input convogliato non sta affatto parallelizzando. Quando è permesso leggere un ordinamento di file divide il carico come indicato.

sort non crea un thread a meno che non sia necessario e per i file di piccole dimensioni è solo un sovraccarico. Ora purtroppo l'ordinamento tratta una pipe come un piccolo file. Se si desidera fornire dati sufficienti a 24 thread, è necessario specificare l'ordinamento per utilizzare un buffer interno di grandi dimensioni (l'ordinamento lo fa automaticamente quando presentato con file di grandi dimensioni). Questo è qualcosa che dovremmo migliorare a monte (almeno nella documentazione). Quindi vorrai qualcosa di simile:

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

Nota Ho impostato LC_ALL = C per tutti i processi, poiché trarranno tutti vantaggio da questi dati).

A proposito, puoi monitorare i thread di ordinamento con qualcosa del tipo:

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