Ich habe gerade mein Skript pkg_libchk parallelisiert. Auf meinem Dual-Core bringt das 31,309% Laufzeitverkürzung. Im Moment teste ich, ob es Performancekosten auf einem Single-Core System mit sich bringt. Falls nicht, wird das auch so in meinen Port einfließen.
Ein paar Erfahrungen, die ich gemacht habe:
Statusausgaben werden nur von einem Prozess neu gezeichnet. Den Bedarf melden die Kindprozesse über ein Signal. Ich SIGCHLD verwendet.
Man benötigt auf jeden Fall eine Trap für SIGTERM und SIGINT um Kindprozesse zu töten, wenn die Ausführung gestoppt wird.
Es scheint sich zu lohnen 2 Jobs pro Kern zu spendieren.
Die Zahl der geforkten Prozesse prüfe ich mit 100Hz. Bei 10Hz zum Beispiel frisst die Wartezeit, die Prozesse später als nötig geforkt werden, einen signifikanten Teil des Laufzeitgewinns. Vor allem wenn man nur einen Job pro Kern verwendet. Ich werde damit noch experimentieren.
Update:
Wenn das neue Skript in einen 1-Job-Modus gezwungen wird, ist es über 16% langsamer als das Original. Dabei handelt es sich also um Overhead, der mit mehr Prozessen durch die Nutzung mehrerer Kerne ausgeglichen werden muss. Das bestätigt sich auch auf meinem Single-Core P4 mit 1.6 GHz. Dort ist das parallelisierte Skript satte 19% langsamer.
Jetzt lautet die Frage was mehr wiegt. 19% langsamer bei Single-Core oder 30% schneller bei Dual-Core?
Ein paar Erfahrungen, die ich gemacht habe:
Statusausgaben werden nur von einem Prozess neu gezeichnet. Den Bedarf melden die Kindprozesse über ein Signal. Ich SIGCHLD verwendet.
Man benötigt auf jeden Fall eine Trap für SIGTERM und SIGINT um Kindprozesse zu töten, wenn die Ausführung gestoppt wird.
Es scheint sich zu lohnen 2 Jobs pro Kern zu spendieren.
Die Zahl der geforkten Prozesse prüfe ich mit 100Hz. Bei 10Hz zum Beispiel frisst die Wartezeit, die Prozesse später als nötig geforkt werden, einen signifikanten Teil des Laufzeitgewinns. Vor allem wenn man nur einen Job pro Kern verwendet. Ich werde damit noch experimentieren.
Update:
Wenn das neue Skript in einen 1-Job-Modus gezwungen wird, ist es über 16% langsamer als das Original. Dabei handelt es sich also um Overhead, der mit mehr Prozessen durch die Nutzung mehrerer Kerne ausgeglichen werden muss. Das bestätigt sich auch auf meinem Single-Core P4 mit 1.6 GHz. Dort ist das parallelisierte Skript satte 19% langsamer.
Jetzt lautet die Frage was mehr wiegt. 19% langsamer bei Single-Core oder 30% schneller bei Dual-Core?
Zuletzt bearbeitet: