¿Has probado con bloques más pequeños?
Cuando pruebo en mi propia estación de trabajo, noto una mejora sucesiva al reducir el tamaño del bloque. Está solo en el ámbito del 10% en mi prueba, pero sigue siendo una mejora. Buscas el 100%.
A medida que se realizan más pruebas, los tamaños de bloque realmente pequeños parecen funcionar:
Probé
dd if=/dev/zero bs=32k count=256000 | dd of=/dev/null bs=32k
256000+0 records in
256000+0 records out
256000+0 records in
256000+0 records out
8388608000 bytes (8.4 GB) copied8388608000 bytes (8.4 GB) copied, 1.67965 s, 5.0 GB/s
, 1.68052 s, 5.0 GB/s
Y con su original
dd if=/dev/zero bs=8M count=1000 | dd of=/dev/null bs=8M
1000+0 records in
1000+0 records out
1000+0 records in
1000+0 records out
8388608000 bytes (8.4 GB) copied8388608000 bytes (8.4 GB) copied, 6.25782 s, 1.3 GB/s
, 6.25203 s, 1.3 GB/s
5.0/1.3 =3.8 por lo que es un factor considerable.
Parece que las canalizaciones de Linux solo producen 4096 bytes a la vez para el lector, independientemente del tamaño de las escrituras del escritor.
Por lo tanto, tratar de introducir más de 4096 bytes en una tubería ya llena por llamada al sistema write(2) solo hará que el escritor se detenga, hasta que el lector pueda invocar las lecturas múltiples necesarias para extraer esa cantidad de datos de la tubería y hacer cualquier procesamiento. tiene en mente hacer.
Esto me dice que en CPU de varios núcleos o subprocesos múltiples (¿alguien todavía fabrica una CPU de un solo núcleo, un solo subproceso?), se puede obtener más paralelismo y, por lo tanto, tiempos de reloj más cortos si cada escritor en una canalización solo escribe 4096 bytes a la vez, antes de volver a cualquier procesamiento de datos o producción que pueda hacer para hacer el siguiente bloque 4096.