Je ne suis pas sûr que ce soit gagnant (par rapport à memcmp, s'entend) : en utilisant --len, tu forces 4 mises-à-jour de la variable len, autrement dit tu génères des instructions d'écriture qui vont détériorer les performances du pipeline.
À moins d'avoir un compilateur suffisament performant qui va réécrire cela en
mais là l'intérêt est réduit, vu que le même compilateur va probablement générer un code très semblable (seule différence visible, l'ordre des comparaisons) avec memcmp().
En fait, le compilateur va *considérer* ce code-là si tu écris memcmp(); mais il peut aussi décider de générer un truc genre :
si les accès non-alignés (avec proba 75% ou 50%) ne sont pas trop chers, ou si tu priorises la taille du code. On peut aussi avoir une version plus compliquée qui teste la parité de name+len, genre :
Bref, en règle générale cela vaut la peine de laisser faire le compilateur et la bibliothèque standard, cela fait moins de code à écrire et le résultat est plus facile à comprendre, à vérifier, à dépanner, à changer si l'extension passe de ".txt" à ".resultats", etc.
Antoine
En news:462a30e9$0$5103$ba4acef3@news.orange.fr,
matt va escriure:
Je ne suis pas sûr que ce soit gagnant (par rapport à memcmp, s'entend) : en
utilisant --len, tu forces 4 mises-à-jour de la variable len, autrement dit
tu génères des instructions d'écriture qui vont détériorer les performances
du pipeline.
À moins d'avoir un compilateur suffisament performant qui va réécrire cela
en
mais là l'intérêt est réduit, vu que le même compilateur va probablement
générer un code très semblable (seule différence visible, l'ordre des
comparaisons) avec memcmp().
En fait, le compilateur va *considérer* ce code-là si tu écris memcmp();
mais il peut aussi décider de générer un truc genre :
si les accès non-alignés (avec proba 75% ou 50%) ne sont pas trop chers, ou
si tu priorises la taille du code. On peut aussi avoir une version plus
compliquée qui teste la parité de name+len, genre :
Bref, en règle générale cela vaut la peine de laisser faire le compilateur
et la bibliothèque standard, cela fait moins de code à écrire et le résultat
est plus facile à comprendre, à vérifier, à dépanner, à changer si
l'extension passe de ".txt" à ".resultats", etc.
Je ne suis pas sûr que ce soit gagnant (par rapport à memcmp, s'entend) : en utilisant --len, tu forces 4 mises-à-jour de la variable len, autrement dit tu génères des instructions d'écriture qui vont détériorer les performances du pipeline.
À moins d'avoir un compilateur suffisament performant qui va réécrire cela en
mais là l'intérêt est réduit, vu que le même compilateur va probablement générer un code très semblable (seule différence visible, l'ordre des comparaisons) avec memcmp().
En fait, le compilateur va *considérer* ce code-là si tu écris memcmp(); mais il peut aussi décider de générer un truc genre :
si les accès non-alignés (avec proba 75% ou 50%) ne sont pas trop chers, ou si tu priorises la taille du code. On peut aussi avoir une version plus compliquée qui teste la parité de name+len, genre :
Bref, en règle générale cela vaut la peine de laisser faire le compilateur et la bibliothèque standard, cela fait moins de code à écrire et le résultat est plus facile à comprendre, à vérifier, à dépanner, à changer si l'extension passe de ".txt" à ".resultats", etc.
Je ne suis pas sûr que ce soit gagnant (par rapport à memcmp, s'entend) : en utilisant --len, tu forces 4 mises-à-jour de la variable len, autrement dit tu génères des instructions d'écriture qui vont détériorer les performances du pipeline.
À moins d'avoir un compilateur suffisament performant qui va réécrire cela en
mais là l'intérêt est réduit, vu que le même compilateur va probablement générer un code très semblable (seule différence visible, l'ordre des comparaisons) avec memcmp().
En fait, le compilateur va *considérer* ce code-là si tu écris memcmp(); mais il peut aussi décider de générer un truc genre :
si les accès non-alignés (avec proba 75% ou 50%) ne sont pas trop chers, ou si tu priorises la taille du code. On peut aussi avoir une version plus compliquée qui teste la parité de name+len, genre :
Bref, en règle générale cela vaut la peine de laisser faire le compilateur et la bibliothèque standard, cela fait moins de code à écrire et le résultat est plus facile à comprendre, à vérifier, à dépanner, à changer si l'extension passe de ".txt" à ".resultats", etc.
Antoine
Bonsoir,
Je te remercie pour ces précisions, et je pense que je vais opter pour un memcmp (qui est preferable à un strcmp ou strncmp ?)
Matt...
En news:462a30e9$0$5103$ba4acef3@news.orange.fr,
matt va escriure:
Je ne suis pas sûr que ce soit gagnant (par rapport à memcmp, s'entend) : en
utilisant --len, tu forces 4 mises-à-jour de la variable len, autrement dit
tu génères des instructions d'écriture qui vont détériorer les performances
du pipeline.
À moins d'avoir un compilateur suffisament performant qui va réécrire cela
en
mais là l'intérêt est réduit, vu que le même compilateur va probablement
générer un code très semblable (seule différence visible, l'ordre des
comparaisons) avec memcmp().
En fait, le compilateur va *considérer* ce code-là si tu écris memcmp();
mais il peut aussi décider de générer un truc genre :
si les accès non-alignés (avec proba 75% ou 50%) ne sont pas trop chers, ou
si tu priorises la taille du code. On peut aussi avoir une version plus
compliquée qui teste la parité de name+len, genre :
Bref, en règle générale cela vaut la peine de laisser faire le compilateur
et la bibliothèque standard, cela fait moins de code à écrire et le résultat
est plus facile à comprendre, à vérifier, à dépanner, à changer si
l'extension passe de ".txt" à ".resultats", etc.
Antoine
Bonsoir,
Je te remercie pour ces précisions, et je pense que je vais opter pour
un memcmp (qui est preferable à un strcmp ou strncmp ?)
Je ne suis pas sûr que ce soit gagnant (par rapport à memcmp, s'entend) : en utilisant --len, tu forces 4 mises-à-jour de la variable len, autrement dit tu génères des instructions d'écriture qui vont détériorer les performances du pipeline.
À moins d'avoir un compilateur suffisament performant qui va réécrire cela en
mais là l'intérêt est réduit, vu que le même compilateur va probablement générer un code très semblable (seule différence visible, l'ordre des comparaisons) avec memcmp().
En fait, le compilateur va *considérer* ce code-là si tu écris memcmp(); mais il peut aussi décider de générer un truc genre :
si les accès non-alignés (avec proba 75% ou 50%) ne sont pas trop chers, ou si tu priorises la taille du code. On peut aussi avoir une version plus compliquée qui teste la parité de name+len, genre :
Bref, en règle générale cela vaut la peine de laisser faire le compilateur et la bibliothèque standard, cela fait moins de code à écrire et le résultat est plus facile à comprendre, à vérifier, à dépanner, à changer si l'extension passe de ".txt" à ".resultats", etc.
Antoine
Bonsoir,
Je te remercie pour ces précisions, et je pense que je vais opter pour un memcmp (qui est preferable à un strcmp ou strncmp ?)
