Hai provato con blocchi più piccoli?
Quando provo sulla mia workstation, noto un miglioramento successivo quando si abbassa la dimensione del blocco. È solo nell'ordine del 10% nel mio test, ma è comunque un miglioramento. Stai cercando il 100%.
Come risulta da ulteriori test, le dimensioni dei blocchi davvero piccole sembrano fare il trucco:
Ho provato
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
E con il tuo originale
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 quindi questo è un fattore considerevole.
Sembra che le pipe di Linux rendano al lettore solo 4096 byte alla volta, indipendentemente da quanto fossero grandi le scritture dello scrittore.
Quindi provare a inserire più di 4096 byte in una pipe già riempita per chiamata di sistema write (2) causerà solo lo stallo dello scrittore, fino a quando il lettore non può invocare le letture multiple necessarie per estrarre così tanti dati dalla pipe ed eseguire qualsiasi elaborazione ha in mente di fare.
Questo mi dice che su CPU multi-core o multi-thread (qualcuno crea ancora una CPU single core, single thread,?), si può ottenere più parallelismo e quindi tempi di clock trascorsi più brevi facendo in modo che ciascun writer in una pipeline scriva solo 4096 byte alla volta, prima di tornare a qualsiasi elaborazione o produzione di dati che può fare per creare il prossimo blocco 4096.