Wer viele Dateien in einem Verzeichnis komprimieren oder konvertieren möchte, kann das auf der Shell mit einer Schleife machen:
for i in *; do gzip $i; done
Dieses Beispiel komprimiert nacheinander alle Dateien mit gzip. Um die Auflösung (also die Abmessungen) aller Bilder mit der Endung .png um 50 Prozent zu verkleinern, kann man zum Werkzeug mogrify aus dem ImageMagick-Paket greifen (unter Ubuntu 12.10 im Paket imagemagick):
for i in *.png; do mogrify -resize 50% $i; done
Beide Lösungen haben jedoch die unangenehme Eigenschaft, dass sie jede Datei nacheinander behandeln. Oder mit anderen Worten: Je mehr Dateien im Verzeichnis liegen, desto länger dauert der gesamte Vorgang.
Die Kompression oder Umwandlung könnte man beschleunigen, indem man mehrere Dateien gleichzeitig einpacken beziehungsweise bearbeiten lässt. Damit würde dann auf modernen Prozessoren auch nicht nur ein Rechnenkern beschäftigt, während die anderen Däumchen drehen.
Je mehr Dateien zu verarbeiten sind, desto deutlicher sind die Unterschiede zwischen einer Schleife und der parallelen Verarbeitung.
Genau hier springt das kleine Programm parallel ein, das alle großen Distributionen in ihren Repositories anbieten. Unter Ubuntu 12.10 steckt es beispielsweise im Paket parallel. Das Werkzeug startet einfach einen Befehl mehrfach. Alle Informationen, mit denen man parallel über die Standardeingabe füttert, reicht es an die von ihm gestarteten Befehle weiter. Klingt kompliziert, ist in der Praxis aber ganz einfach. Um alle Dateien im aktuellen Verzeichnis parallel verpacken zu lassen, ruft man einfach folgenden Befehl auf:
ls | parallel gzip
Die gepackten Dateien muss man nicht alle wieder einzeln auspacken. Stattdessen hilft auch hier wieder parallel:
ls | parallel gunzip
In beiden Fällen startet parallel gleich mehrfach gzip beziehungsweise gunzip und setzt die Bande dann auf die von ls herübergereichten Dateinamen an.
Nach dem gleichen Prinzip skaliert der folgende Befehl die Auflösung aller Bilder mit der Endung .png um die Hälfte herunter:
ls *.png | parallel mogrify -resize 50%
Die wesentlichen limitierenden Faktoren sind hier nur noch die Geschwindigkeit der Festplatte und die Anzahl der Prossorkerne.
Hallo,
nettes Progrämmchen, man sollte es allerdings mit bedacht einsetzten.
Zum einen bringt es nur etwas bei Hyberthreding und Mehrkern-CPUs und zum anderen kann man damit einen PC (je nach Kernel) quasi lahmlegen. und zwar wenn man mindestens so viele Tasks wie CPU Kerne (auch Hyberthredding) hat. Dieses tritt dann auf, wenn man den Prozess startet und zeitweise wenig z.B. auf dem Desktop tut. Denn nach einiger Zeit ordnet Linux den Prozessen mit hoher Last höhere Resourcen (RAM und CPU zeit zu). Dann sollte man die Priorität der Tasks herunter stufen – damit das nicht so gravierend auftritt.
Gruß
Ulf
Haben die Macher auch bemerkt:
https://www.linux-community.de/Internal/Nachrichten/GNU-Parallel-20121122
Siehe Überschrift. Den Output von ls zu parsen ist die schlechteste idee ever. Und wenn es nur ein Beispiel war, dann ein schlechtes. So lehrt man User, Bugs zu bauen.
näheres dazu: http://mywiki.wooledge.org/ParsingLs
Nein, nicht pauschal. Es kommt darauf an, was nach dem Pipe mit den Dateinamen passiert.
“ls” wird übrigens auch in der offiziellen parallel-Dokumentation als Beispiel genannt.
Auf Nummer sicher gehen kann man mit den doppelt geschweiften klammern:
ls | parallel befehl {}