[C] Utiliser fork() correctement
Résolu/Fermé
Sauvegarde2
Messages postés
205
Date d'inscription
dimanche 14 décembre 2008
Statut
Membre
Dernière intervention
11 janvier 2015
-
6 août 2012 à 19:25
Sauvegarde2 Messages postés 205 Date d'inscription dimanche 14 décembre 2008 Statut Membre Dernière intervention 11 janvier 2015 - 8 août 2012 à 17:15
Sauvegarde2 Messages postés 205 Date d'inscription dimanche 14 décembre 2008 Statut Membre Dernière intervention 11 janvier 2015 - 8 août 2012 à 17:15
A voir également:
- [C] Utiliser fork() correctement
- Utiliser chromecast - Guide
- Comment utiliser l'ia - Accueil - Guide Intelligence artificielle
- Utiliser iphone comme webcam - Guide
- Comment utiliser utorrent - Télécharger - Téléchargement & Transfert
- Comment utiliser wetransfer gratuit ? - Guide
2 réponses
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 298
7 août 2012 à 13:53
7 août 2012 à 13:53
Déjà on sais maintenant que c'est le wait qui pose problème.
As tu lus le man de wait ? Je comprends qu'un enfant qui se termine correctement doit avoir un exit(2) ou exit(3). Peut être que comme tu retournes un exit(0), le wait détecte un problème ?
Tu peux aussi récupérer les retours de wait ainsi que le status (paramètre de wait() ) pour voir si quelques chose se passe mal.
Je pense que ton algorithme est mal pensé, faire un fork prend du temps car il faut dupliquer le processus, et là tu fait un fork à chaque itération que tu détruit ensuite, donc tu fais NB_IZOOM fork. Selon la valeur de NB_ZOOM, ça peut être très pénalisant.
Pour moi, la bonne façon de faire et ton script s'y prete bien, c'est de faire le fork avant le for et de couper ta boucle en deux.
As tu lus le man de wait ? Je comprends qu'un enfant qui se termine correctement doit avoir un exit(2) ou exit(3). Peut être que comme tu retournes un exit(0), le wait détecte un problème ?
Tu peux aussi récupérer les retours de wait ainsi que le status (paramètre de wait() ) pour voir si quelques chose se passe mal.
Je pense que ton algorithme est mal pensé, faire un fork prend du temps car il faut dupliquer le processus, et là tu fait un fork à chaque itération que tu détruit ensuite, donc tu fais NB_IZOOM fork. Selon la valeur de NB_ZOOM, ça peut être très pénalisant.
Pour moi, la bonne façon de faire et ton script s'y prete bien, c'est de faire le fork avant le for et de couper ta boucle en deux.
pid=fork(); if(pid==0) { for (i=0;i<NB_IZOOM/2;++i) { if(i!=0)source[i] = resize(source[0], subname[i], pzoom[i]); crop(source[i], subname[i], subdir[i], geometry); } exit(2); }else { for (i=NB_IZOOM/2;i<NB_IZOOM;++i) { source[i] = resize(source[0], subname[i], pzoom[i]); crop(source[i], subname[i], subdir[i], geometry); } } wait(0);// attend la fin de l'enfant pour être certain de ne pas avoir de problème de synchronisation dans la suite. ...
Char Snipeur
Messages postés
9813
Date d'inscription
vendredi 23 avril 2004
Statut
Contributeur
Dernière intervention
3 octobre 2023
1 298
7 août 2012 à 08:43
7 août 2012 à 08:43
essai sans le wait(0). Le fork prend du temps tout de même !
Sauvegarde2
Messages postés
205
Date d'inscription
dimanche 14 décembre 2008
Statut
Membre
Dernière intervention
11 janvier 2015
261
7 août 2012 à 13:18
7 août 2012 à 13:18
Effectivement ça marche. J'ai un temps de 48 secondes mais ça marche. Mais je comprend pas pourquoi ça fonctionne mieux sans le wait(0)...
7 août 2012 à 16:56
8 août 2012 à 07:52
Ce que je vois : fork prend du temps à être fait, donc il faut vraiment que la boucle soit longue en calcul. 8s ça me parait exploitable, si tu passe bien la majorité du temps dans la boucle que tu donnes. Je pense que tu devrais descendre à 5s.
Je vois une autre cause possible au ralentissement : l'écriture sur disque. Il faut d'abord vérifier que ça ne soit pas ça qui prenne le plus de temps. Du coup en parallèle, peut être que les deux processus se marchent un peu sur les pieds pour écrire.
=> profilage ou test du programme en supprimant la fonction d'écriture.
8 août 2012 à 13:35
8 août 2012 à 14:47
Ou alors c'est le recopiage des données qui est long à cause de comme tu dit l'histoire du cache, en parallèle tu es obligé de faire pleins d'aller retour dans la RAM ce qui doit prendre du temps ? Après, il y a des méthodes d'optimisation pour aller plus vite, sinon il va falloir se contenter des 8s.
8 août 2012 à 17:15