Ordenar --paralelo no está paralelizando

Estoy tratando de hacer un conjunto único de líneas extraídas de un archivo con egrep con sort -u, luego las cuento. Alrededor del 10% de las líneas (todos los 100 caracteres del alfabeto [ATCG]) están duplicados. Hay dos archivos, aproximadamente 3 conciertos cada uno, el 50% no son relevantes, por lo que quizás 300 millones de líneas.

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

Entre LC_ALL = C y el uso de -x para acelerar grep, la parte más lenta es el tipo. Leer las páginas del manual me llevó a --parallel = n, pero la experimentación no mostró absolutamente ninguna mejora. Un poco de excavación con la parte superior mostró que incluso con --parallel = 24, el proceso de clasificación solo se ejecuta en un procesador a la vez.

Tengo 4 chips con 6 núcleos y 2 hilos / núcleo, lo que da un total de 48 procesadores lógicos. Vea lscpu porque / proc / cpuinfo sería demasiado largo.

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

¿Qué me estoy perdiendo? Incluso si el proceso está vinculado a IO, ¿no debería ver el procesamiento paralelo de todos modos? El proceso de clasificación utiliza el 99% del procesador en el que está realmente en cualquier momento dado, por lo que debería poder ver la paralelización si está sucediendo. La memoria no es una preocupación, tengo 256 Gb para jugar y nada de eso es usado por nada más.

Algo que descubrí canalizando grep a un archivo y luego leyendo el archivo con sort:

 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

Al hacer estos puntos de referencia, es bastante claro que cuando la ordenación de entrada canalizada no está paralelizando en absoluto. Cuando se le permite leer un archivo, se divide la carga según las instrucciones.

sort no crea un hilo a menos que sea necesario, y para archivos pequeños es demasiado sobrecarga. Ahora desafortunadamente sort trata las tuberías como un archivo pequeño. Si desea alimentar suficientes datos a 24 subprocesos, deberá especificar la ordenación para usar un búfer interno grande (la ordenación lo hace automáticamente cuando se presenta con archivos grandes). Esto es algo que deberíamos mejorar en sentido ascendente (al menos en la documentación). Entonces querrás algo como:

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

Tenga en cuenta que he configurado LC_ALL = C para todos los procesos, ya que todos se beneficiarán con estos datos).

Por cierto, puede monitorear los hilos de clasificación con algo como:

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