Différents ordonnances d'exécution entraînent des différences de performance d'un programme Pthread

Ceci est mon premier message sur Stackoverflow et ma langue maternelle n'est pas l'anglais. S'il vous plaît, excusez-moi pour tout inconvénient que cet article vous apporte. Peut-être que c'est un peu longtemps, alors j'attends votre patience avec impatience. Merci d'avance!

J'ai un extrait de code de langue C. Le travail comporte le nombre de mots dans deux fichiers. J'utilise Pthreads pour résoudre ce problème. Mais je trouve l'ordre de ces deux déclarations

Nombre_Words (argv [1]);

pthread_create (& t1, null, comte_words, (vide *) argv [2]);

affecte les performances du programme, ce qui est opposé à ce que je m'attendais. Voici le code: xxx

performance:

i Exécutez le programme à l'aide de "Nom de programme" sur la ligne de commande pour tester le vitesse de course. La sortie est la suivante:

si la commande comme ceci:

Nombre_Words (argv [1]);

pthread_create (& t1, null, comte_words, (vide *) argv [2]);

Le programme fonctionne vite: réel 0.014S

SI comme ceci:

pthread_create (& t1, null, comte_words, (vide *) argv [2]);

Nombre_Words (argv [1]);

programme fonctionne lentement: réel 0.026S

ce que je m'attendais:

sur le boîtier 1, le programme exécute le comte_word () d'abord. Après avoir terminé le travail de comptage, il continuera à exécuter pthread_create (). À ce moment-là, le nouveau fil vous aidera à faire le travail de comptage. Donc, le nouveau thread contient le travail après que le fil d'origine complète le travail, qui est en cours d'exécution séquentielle au lieu de courir parallèle. Sur le cas 2, le programme exécute Pthread_Create () d'abord avant tout comptage, de manière à ce qu'il y ait deux threads parallèles faire le comptage. Je m'attends donc à ce que le cas 2 soit plus rapide que le cas 1. Mais je me trompe. Le cas 2 est plus lent. Quelqu'un pourrait-il me donner des informations utiles sur cela?

note

Veuillez ignorer que je ne mettez pas de verrouillage mutex sur la variable globale total_wards. Ce n'est pas la partie qui me préoccupe. Et le programme est juste pour les tests. S'il vous plaît pardonnez à ses imperfections.

---

EDIT 1

ci-dessous est le complément et l'amélioration après avoir lu des suggestions.

a) Supplément: Le processeur est Intel® Celeron (R) CPU 420 @ 1.60GHz. Un noyau.

b) Amélioration: j'ai amélioré mon exemple, deux modifications:

1) J'ai agrandi les fichiers. File1 est 2080651 octets (environ 2M), File2 est la copie de fichier1.

2) J'ai modifié le comte_words (). Lorsque vous atteignez l'extrémité du fichier, utilisez Fsek () pour définir le FP au début et compter à nouveau. Compte à plusieurs reprises les temps comptent. Définir le compte 20. Vous trouverez ci-dessous le code modifié: xxx

sortie de FAST_VERSION (Nombre_Word () d'abord) et Slow_version (pthread_create () d'abord):

Administrateur @ ubuntu: ~ $ TIME ./fast_version File1 File2

12241560: Total des mots

réel 0m5.057s

utilisateur 0m4.960s < p> sys 0m0.048s

administrateur @ ubuntu: ~ $ TIME ./slow_version File1 File2

12241560: Total des mots

réel 0m7.636s

Utilisateur 0m7.280s

SYS 0M0.048S

J'ai essayé la commande "Fichier Prignome1 time1 File2" quelques fois. Peut-être qu'il y a une différence sur dixième ou centième d'une seconde à chaque course. Mais les différences ne sont pas beaucoup.

EDIT 2

Cette pièce est ajoutée après avoir fait des expériences selon certaines indications -

Lorsque vous lancez le deuxième thread après le premier fil terminé son exécution, il n'y a pas de contexte basculant sur le dessus.

- par user315052.

L'expérience est que j'ai amélioré le comte_word (): xxx

Ajouter une déclaration "Imprimerf ( "de% s \ n", nom de fichier); ", afin que je puisse dire quel fichier (ou fil) fonctionne à cette époque. La sortie de la version rapide est 20 fois "à partir de fichier1", puis 20 fois "à partir de fichier2" et la version lente est "à partir de fichier1" et "à partir de fichier2" imprimé mixte.

On dirait que la version rapide est plus rapide car il n'y a pas de commutation de contexte. Mais le fait est qu'après la fin de Count_Word (), le fil d'origine n'était pas mort, mais a créé un nouveau fil et a attendu que cela se termine. N'y a-t-il pas de contexte de commutation lorsque le nouveau thread est en cours d'exécution? J'ai regardé l'écran de près et j'ai trouvé que la vitesse d'impression de "à partir de fichier2" est apparemment plus lente que "de File1". Pourquoi? Est-ce parce que la commutation de contexte s'est produite lors du dépôt de fichier2?

pour la version lente, nous pouvons voir à partir de la sortie la vitesse d'impression de "à partir de fichier1" et "à partir de fichier2" est encore plus lente que la vitesse d'impression de "de File2" dans la version rapide, car son contexte La commutation coûte plus de temps sur le comptage parallèle, tandis que dans la version rapide, le changement de contexte n'est pas si lourd car l'un des threads a terminé son travail et juste en attente.

donc je pense que la version principale est donc la version rapide Contexte léger et facile basculant contre la version lente. Mais la "vitesse d'impression" vient de mon observation et peut ne pas être aussi stricte. Donc, je ne suis pas sûr de ça.