J'aime beaucoup systemd, et le boulot de Lennart Poettering en général (même si je conçois que beaucoup de ses projets ont été amenés à gêner pas mal de monde dans l'utilisation quotidienne de systèmes libres).
Ceci dit, je commence à en avoir ras-le-derrière de cet argument. Je cite : "Tout le système de démarrage SysVinit est basé sur des scripts qui lancent des commandes externes. D’après Lennart cette approche est condamnée à être lente.".
1) grep, awk, cut, sed, etc. pourraient (souvent) être remplacés par des primitives du shell, et on éviterait de lancer des processus. Si les primitives manquent au shell par défaut de la distro, c'est peut-être plus intelligent de l'implémenter (ou d'utiliser un langage dynamique plus puissant, genre Python/Perl/Ruby/votre lubie) que de faire pêter du C ?
2048 processus echo prennent 5 secondes :
bash-3.2$ time sh -c 'for id in {1..2048}; do /bin/echo $id; done > /dev/null'
real 0m5.453s
user 0m1.374s
sys 0m3.542s
2048 echo de Bash prennent 50ms :
bash-3.2$ time sh -c 'for id in {1..2048}; do echo $id; done > /dev/null'
real 0m0.051s
user 0m0.041s
sys 0m0.007s
2) J'ai écrit en 2 minutes un micro-benchmark (pourri, comme tout benchmark). Un processus qui crée un enfant puis attend qu'il termine. Cet enfant crée lui-même un enfant puis attend qu'il termine. Le tout récursif, 2048 fois (donc 0 parallélisation, et on se retrouve avec 2049 de ces processus en simultané...).
Dans une machine virtuelle sur un laptop avec processeur basse consommation, l'exécution prend un total de 11 ms.
$ grep ^Pid /proc/self/status; time ./forking; grep ^Pid /proc/self/status
Pid: 15451
real 0m0.011s
user 0m0.002s
sys 0m0.009s
Pid: 15548
# Quoi ? Il faut créer plein de processus ?
Posté par Pierre Carrier . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 9.
J'aime beaucoup
systemd, et le boulot de Lennart Poettering en général (même si je conçois que beaucoup de ses projets ont été amenés à gêner pas mal de monde dans l'utilisation quotidienne de systèmes libres).Ceci dit, je commence à en avoir ras-le-derrière de cet argument. Je cite : "Tout le système de démarrage SysVinit est basé sur des scripts qui lancent des commandes externes. D’après Lennart cette approche est condamnée à être lente.".
1) grep, awk, cut, sed, etc. pourraient (souvent) être remplacés par des primitives du shell, et on éviterait de lancer des processus. Si les primitives manquent au shell par défaut de la distro, c'est peut-être plus intelligent de l'implémenter (ou d'utiliser un langage dynamique plus puissant, genre Python/Perl/Ruby/votre lubie) que de faire pêter du C ?
2048 processus
echoprennent 5 secondes :2048
echode Bash prennent 50ms :2) J'ai écrit en 2 minutes un micro-benchmark (pourri, comme tout benchmark). Un processus qui crée un enfant puis attend qu'il termine. Cet enfant crée lui-même un enfant puis attend qu'il termine. Le tout récursif, 2048 fois (donc 0 parallélisation, et on se retrouve avec 2049 de ces processus en simultané...).
Dans une machine virtuelle sur un laptop avec processeur basse consommation, l'exécution prend un total de 11 ms.
Si vous doutez de ma capacité à écrire 10 lignes de code, vous pouvez vérifier sur [https://github.com/pcarrier/stuff/blob/master/fun/forking.c].
systemdapporte des fonctionnalités géniales, mais de grâce, arrêtons d'utiliser la performance comme argument pour l'introduction de larges binaires.