Haben Sie es mit kleineren Blöcken versucht?
Wenn ich es auf meiner eigenen Workstation versuche, bemerke ich eine sukzessive Verbesserung beim Verringern der Blockgröße. In meinem Test liegt sie nur im Bereich von 10%, aber immer noch eine Verbesserung. Sie suchen 100 %.
Wie sich beim weiteren Testen herausstellt, scheinen wirklich kleine Blockgrößen den Zweck zu erfüllen:
Ich habe versucht
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
Und mit Ihrem 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, das ist also ein beträchtlicher Faktor.
Es scheint, dass Linux-Pipes jeweils nur 4096 Bytes an den Leser liefern, unabhängig davon, wie groß die Schreibvorgänge des Schreibers waren.
Der Versuch, mehr als 4096 Bytes in eine bereits gefüllte Pipe pro Systemaufruf write(2) zu stopfen, wird den Writer nur zum Stillstand bringen, bis der Reader die mehreren Lesevorgänge aufrufen kann, die erforderlich sind, um so viele Daten aus der Pipe zu ziehen und die Verarbeitung durchzuführen es hat zu tun.
Dies sagt mir, dass man auf Multi-Core- oder Multi-Thread-CPUs (macht noch jemand einen Single-Core, Single-Thread, CPU?) mehr Parallelität und damit kürzere verstrichene Taktzeiten erzielen kann, indem jeder Writer in einer Pipeline nur 4096 schreibt Bytes auf einmal, bevor es zur Datenverarbeitung oder -produktion zurückkehrt, um den nächsten 4096-Block zu erstellen.