Me semble avoir vu un papier sur l'utilisation de la fonction C sort, contre je ne sais plus quel algo générique C++ ou le C++ était effectivement supérieur. Mais supérieur à mon avis uniquement à l'implémentation standard C.
En fait, la différence est dans la manière dont se fait l’appel à la fonction de comparaison. Avec qsort() en C, on passe par un pointeur de fonction. Avec std::sort, le compilateur va générer l’ensemble du code de tri, spécialisé pour la fonction de tri donnée. L’empreinte mémoire sera un peu plus grosse, mais en revanche on se passe du pointeur de fonction, l’appel au comparateur est plus rapide, au final on est gagnant.
Et C n’offre pas d’alternative autre que de réécrire l’algo spécialisé pour le type en question pour avoir les mêmes perfs. En C++, c’est le compilateru qui le fait pour toi.
De la même manière, une bibliothèque comme ublas (calcul matriciel) met une branlée à toute bibliothèque C pour toutes les opérations non spécialisées dans les libs C, grâce à l’utilisation d’expression templates.
J’avais lu un comparatif assez intéressant, je crois fait par les devs de scala au départ, sur les perfs entre C++, Scala, Java (je crois qu’il y avait un autre langage mais je ne me souvient plus lequel, peut-être go). La conclusion qui en ressortait était que le programme « naïf » écrit en C++ était plus lent que celui écrit naïvement en scala, et qu’après optimisations ils étaient à peu près équivalent. Ensuite, ils ont donné le programme à un gourou C++ (un vrai), qui a fait de vraies optimisations de gourou, et là les perfs étaient quelque chose comme 20% meilleures, quelque chose qu’ils n’ont jamais pu atteindre en scala. Par contre les optimisations en question étaient très loin d’être à la portée du dev moyen.
D'ailleurs, ce if, il ne sera pas optimisé par le compilateur en débogage, je me trompe? C'est peut-être une micro optim, c'est vrai, mais est-elle illisible? Et si ce n'est pas le cas, pourquoi ne pas l'utiliser?
Quelques raisons :
- la liste vide pas gérée, et c’est pas précisé (un connard va copier/coller le code et l’utiliser ailleurs)
- le goto est un nid à emmerdes, j’aime pouvoir faire un "grep goto *" et que ça soit vide
- tu optimises au mauvais endroit. Tu supprimes un test, alors que la première chose à faire, c’est d’optimiser l’allocation mémoire au moyen d’un reserve()
- dans le même genre, je fais mal aux mouches mais tu concatènes avec ";" alors qu’il serait plus efficace de concaténer ';'
Donc en gros, tu micro-optimises, mais mal, et donc tu complexifies la lecture du code pour un gain négligeable. Je préfère largement voir dans le code :
qui prend une ligne à écrire, et fait ce que tu veux de manière largement assez efficace (c’est à dire, vraisemblablement autant que ta version « optimisée ») partout où ce n’est pas nécessaire de faire mieux.
Cela dit, si le sujet de la micro-optimisation en C++ t’intéresse, je t’invite à regarder les conf’ d’Alexandrescu, c’est hyper technique et hyper intéressant de ce point de vue.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Pas sûr que trouver des erreurs/la fiabilité soit si important pour la communauté libre..
Posté par whity . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 4.
En fait, la différence est dans la manière dont se fait l’appel à la fonction de comparaison. Avec qsort() en C, on passe par un pointeur de fonction. Avec std::sort, le compilateur va générer l’ensemble du code de tri, spécialisé pour la fonction de tri donnée. L’empreinte mémoire sera un peu plus grosse, mais en revanche on se passe du pointeur de fonction, l’appel au comparateur est plus rapide, au final on est gagnant.
Et C n’offre pas d’alternative autre que de réécrire l’algo spécialisé pour le type en question pour avoir les mêmes perfs. En C++, c’est le compilateru qui le fait pour toi.
De la même manière, une bibliothèque comme ublas (calcul matriciel) met une branlée à toute bibliothèque C pour toutes les opérations non spécialisées dans les libs C, grâce à l’utilisation d’expression templates.
J’avais lu un comparatif assez intéressant, je crois fait par les devs de scala au départ, sur les perfs entre C++, Scala, Java (je crois qu’il y avait un autre langage mais je ne me souvient plus lequel, peut-être go). La conclusion qui en ressortait était que le programme « naïf » écrit en C++ était plus lent que celui écrit naïvement en scala, et qu’après optimisations ils étaient à peu près équivalent. Ensuite, ils ont donné le programme à un gourou C++ (un vrai), qui a fait de vraies optimisations de gourou, et là les perfs étaient quelque chose comme 20% meilleures, quelque chose qu’ils n’ont jamais pu atteindre en scala. Par contre les optimisations en question étaient très loin d’être à la portée du dev moyen.
Quelques raisons :
- la liste vide pas gérée, et c’est pas précisé (un connard va copier/coller le code et l’utiliser ailleurs)
- le goto est un nid à emmerdes, j’aime pouvoir faire un "grep goto *" et que ça soit vide
- tu optimises au mauvais endroit. Tu supprimes un test, alors que la première chose à faire, c’est d’optimiser l’allocation mémoire au moyen d’un reserve()
- dans le même genre, je fais mal aux mouches mais tu concatènes avec ";" alors qu’il serait plus efficace de concaténer ';'
Donc en gros, tu micro-optimises, mais mal, et donc tu complexifies la lecture du code pour un gain négligeable. Je préfère largement voir dans le code :
std::string foo = boost::algorithm::join(bar, ";");
qui prend une ligne à écrire, et fait ce que tu veux de manière largement assez efficace (c’est à dire, vraisemblablement autant que ta version « optimisée ») partout où ce n’est pas nécessaire de faire mieux.
Cela dit, si le sujet de la micro-optimisation en C++ t’intéresse, je t’invite à regarder les conf’ d’Alexandrescu, c’est hyper technique et hyper intéressant de ce point de vue.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0