magnolia a écrit 34 commentaires

Bonjour,

Je me permets l'évocation du Frido pour faire la publicité de deux cours similaires que je viens de publier sous licence libre, avec les sources LaTeX. Ce n'est en aucun cas un concurrent du Frido puisqu'il s'adresse à des élèves venant de passer le bac. Il y a :

• Un cours de maths de niveau première année de prépa, conforme au programme 2021 de MPSI et de MP2I
• Un cours d'informatique de niveau première année de prépa conforme au programme du tronc commun 2021. Le langage de programmation utilisé est Python.

Fichiers PDF :
- Cours de maths de MPSI/MP2I : https://mailauxlazaristes-my.sharepoint.com/:b:/g/personal/francois_fayard_auxlazaristeslasalle_fr/EYr-OFSBz2VFq4dzA4hbP_sB1fD9YRvKiIy4TjvhGHwANg?e=5DbNQ2
- Cours d’info commune de sup : https://mailauxlazaristes-my.sharepoint.com/:b:/g/personal/francois_fayard_auxlazaristeslasalle_fr/EfmdIY5Uz0xDv8Pr6uAW5EAB82zCRWSm-gzZjgh7ADqE3g?e=m7dDa6

Les sources sont disponibles sur github : https://github.com/FayardProf/Magnolia.git

Les images ne sont pas libres de droits et sont disponibles ici : https://mailauxlazaristes-my.sharepoint.com/:u:/g/personal/francois_fayard_auxlazaristeslasalle_fr/EY3fIqw_3tRPuGEBdYV9facBVxGNmrdjPuXzhiAImvzhMg?e=fv5vU2

François Fayard

Mais pourquoi aurait on Python=Maths. Peux-tu préciser ce qui a dégouté ta fille ?

Je crois que Scratch est libre. D'après le site, c'est du GPLv2.

Pour les logiciels libres, c'est exactement ce qui se passe en première en NSI : on y enseigne Python qui est libre. Pour l'environnement, il y a beaucoup de choix libres dont Jupyter.

En prépa, c'est pour le moment toujours Python avec quelques bibliothèques libres comme Numpy et Matplotlib. Pour l'option informatique, c'est en OCaml. Le tout est 100% libre.

Pour le programme, c'est vrai qu'on a un programme très orienté algorithmique. Cela me semble être un bon choix. Il y a certes eu des excés en prépa (langages reconnaissables et autres joyeusetés, fonctionnel beaucoup trop mis en avant à mon sens) mais ça se calme.

Si on veut faire des choses qui brillent en info, comme des GUI, le mélange de cours magistral/TP n'est pas taillé pour. Il faudrait faire de l'enseignement par projet. Mais c'est surement trop tôt au lycée et l'éducation nationale n'est pas taillée pour cela. Il y a aussi le problème fondamental du recrutement : il y a de moins en moins de candidats aux concours d'enseignement et le niveau baisse. Donc il va être à mon avis très difficile de recruter des jeunes profs d'informatique compétents. Ceux qui savent faire de l'info sont chassés par les entreprises. Bref, l'éducation nationale peine à recruter. Et des profs compétents, passionnés et passionnants sont nécessaires pour que la matière intéresse.

Je n'ai pas compris quelle est ta question. Est-ce que tu peux préciser ?

Pour une utilisation plus poussée, PyCharm Community est très bien. Jupyter, c'est parfait pour travailler avec des données et visualiser. PyCharm me semble parfait pour faire du développement.

Du coup, j'ai du mal à trouver un intérêt à Pyzo.

En prépa, on fait de l'algo de base et on fait des graphes. C'est pour cela que Jupyter me semble la meilleure solution.

Quand je parle de Jupyter, je pense essentiellement à une config où le serveur et le client tourne sur la même machine. Je ne pensais pas à une architecture où il y a un serveur central.

Pour Pyzo, je ne l'ai jamais vraiment utilisé. Mon premier contact s'est soldé par une modification du code source pour que le Pyzo qui vient avec Ubuntu 18.04 LTS tourne avec le Python 3.7 de mon Anaconda. Maintenant, ça marche, mais je n'ai pas eu le temps d'essayer. Pas mal de collègues ralent contre Pyzo et disent que c'est buggé. Mais je ne sais pas si quels bugs ils rencontrent ni si l'installation faite pas les admins est propre.

Pour les élèves qui veulent installer Python sur leur machine, je recommande Anaconda. On a besoin de numpy et matplotlib et vu que les élèves galèrent déjà avec Anaconda (certains téléchargent la version 32 bits car ils ne savent même pas que leur machine est 64 bits), il est hors de question de faire cela à la main. Ce serait plus simple pour moi si Pyzo était disponible avec conda.

Je suis d'accord que la distribution Anaconda a tendance à s'installer et prendre de la place. Je n'ai jamais utilisé miniconda, mais j'imagine que cela permet de s'installer sans prendre trop de place.

Je ne suis pas administrateur dans notre lycée, mais je crois qu'ils ont utilisé Anaconda sans aucun problème. Bien évidemment, les élèves n'ont pas à installer Anaconda sur leur compte perso puisqu'il est déjà présent sur la machine.

Je n'ai pas encore beaucoup utilisé Pyzo car c'est la première année que j'enseigne le Python et j'ai commencé les TPs avec Jupyter. Mais comme l'École Centrale utilise Pyzo, je vais migrer vers Pyzo. Des collègues m'ont expliqué qu'ils faisaient ça parce qu'ils étaient bien obligés et ils m'ont dit avoir pas mal de problèmes avec Pyzo, des bugs notamment. Je n'ai aucune expérience à ce sujet, mais:

1 - Je préfère toujours utiliser des outils utilisés par le maximum de personnes. Cela permet le plus souvent d'avoir des outils les moins buggés possibles.
2 - Je ne comprends pas pourquoi Pyzo n'est pas dans Anaconda.

Toutes les personnes que je connais et qui enseignent en école d'ingénieur utilisent Jupyter. C'est le cas notamment à Polytechnique. Au passage, il est possible d'utiliser Python et OCaml dans Jupyter alors que Pyzo gère juste Python. Bref, quand on met à côté Pyzo et Jupyter, on ne parle pas du tout de la même taille de communauté et de support. Cela suffit pour moi à préférer Jupyter à Pyzo. Mais je suis d'accord qu'en 2014, lors du lancement de l'épreuve Python à Centrale, ipython/jupyter ne devait pas être au stade où il est aujourd'hui.

Je suis parfaitement d'accord.

Et je trouve qu'il ne vaut mieux pas s'essayer aux interfaces graphiques, ou alors juste le temps d'un TP ou deux. Je pense même qu'utiliser ce petit framework est le meilleur moyen pour que certains élèves, qui parfois maitrisent les bases de SwiftUI ou l'équivalent Kotlin sous Android, nous jettent des pièces.

Désolé pour mon ton un peu emporté.

Il est évident que n'importe quoi semble être un excellent choix à côté de IDLE. Voici mes griefs par rapport à Pyzo :
- Ce n'est même pas dans Anaconda. J'aimerais d'ailleurs bien savoir pourquoi.
- À part dans l'éducation, je n'ai jamais vu personne l'utiliser.

Je ne me souviens plus de l'étendu de l'utilisation de ipython/jupyter en 2013. Mais je trouve dommage qu'on ne change pas. En prépa, c'est dicté par l'École Centrale qui utilise Pyzo dans les épreuves au concours.
Alors que j'ai été consultant en calcul scientifique et que je m'estime plutôt débrouillard en informatique, j'ai du changer le code source du Pyzo disponible sur ma distribution Ubuntu (18.04 LTS) pour qu'il puisse utiliser mon Python Anaconda (version 3.7). Pour l'instant mes élèves utilisent Jupyter notebook, mais on va devoir basculer sur Pyzo. Je sens à 10 km la queue pour que j'installe ce truc sur les configurations parfois exotiques de mes élèves.

Jupyter est devenu le standard. Je pense qu'il serait bien que l'éducation nationale utilise les standards.

Concernant l'idée d'une bibliothèque graphique :

• Le post suggère de diriger les futurs profs de NSI/Python vers une bibliothèque maintenue par une personne qui n'est même pas installée par défaut sur les distributions Python classiques comme Anaconda. Cela me semble être une erreur grave. Je m'y connais plutôt en info (ce qui me permet d'être écouté oar les administrateurs du lycée) et c'est déjà compliqué pour demander aux administrateurs d'installer le moindre truc.
• Ne parlons même pas de séparation entre le coeur du code et l'interface graphique d'un programme que ce genre d'enseignement va ignorer totalement.

Bref, pour intéresser des élèves le temps d'un ou deux TPs, pourquoi pas. Baser tous les exercices de NSI sur une telle bibliothèque, je pense que c'est une erreur grave.

On doit déjà se coltiner Pyzo parce qu'un quidam trouvait cela sympa, alors que toute personne qui n'a pas le cerveau retourné utilise Jupyter notebook.

Bref, je crois en la liberté pédagogique de l'enseignant. C'est à lui, en fonction de ses élèves, d'adapter son cours pour qu'il passionne et qu'il soit efficace. Pour échanger des exercices entre profs, le mieux est donc de n'utiliser que les fonctions de base. Ensuite, le prof mettra l'enrobage qu'il souhaite si cela lui semble important.

Et pour rassurer Christophe : Oui, on a internet. ;-)

Ce post est une réponse à une remarque faite plus haut par Christophe B.

Je suis professeur de mathématiques et d'informatique en classes préparatoires et j'ai suivi l'arrivée de la spécialité NSI en classe de première. Voici quelques éléments de réponse à Christophe :

• Il n'y a jamais eu de CAPES ou d'Agrégation d'informatique. Autrement dit, l'éducation nationale n'a jamais recruté de professeur d'informatique. Les professeurs d'informatique actuels sont donc des personnes qui ont appris l'informatique sur le tas et qui ont choisi d'enseigner l'informatique parce qu'ils en avaient envie. En pratique, cela a souvent été les professeurs de mathématiques.
  La situation est en train de changer et un CAPES d'informatique a été créé. La première session aura lieu au printemps 2020. On aura donc officiellement les premiers professeurs d'informatique l'année prochaine. C'est fondamental car il y a beaucoup de lycées où la NSI n'est pas proposée car il n'y a pas de profs pour l'enseigner.

• Le programme de NSI est essentiellement une adaptation au lycée de ce qui se fait en classes préparatoires depuis 2013. En prépa, on enseigne l'informatique avec Python et certains prennent l'option informatique et font du OCaml (langage impératif et fonctionnel développé par l'INRIA). Au programme de l'option NSI de première, il y a :

  • Variables
  • Fonctions
  • if, for, while
  • listes Python (ils appellent cela tableau car ce sont des gens de bon gout ;-) )
  • dictionnaires
  • on parle un peu de correction de programme

Bref, il y a selon moi l'essentiel pour bien débuter la programmation et avoir les bases de l'algo et les structures de données élémentaires.

• Pour la NSI, il y a selon moi un superbe ouvrage qui a été publié cet été : https://www.amazon.fr/Spécialité-Numérique-sciences-informatiques-programmes/dp/2340033640 . Jean-Christophe Filliâtre est prof de compilation à l'ENS Ulm et à Polytechnique. Les autres auteurs font partie du même labo de l'INRIA que J.C. Filliâtre. Donc il n'y a aucun soucis à se faire sur leur compétence en informatique. Il se trouve que pédagogiquement, leur livre est aussi très bon. Bref, je le recommande très fortement.

• Pour ce qui est du post est des interfaces graphiques, je suis sceptique. Je suis prof dans une des meilleures prépa de France. Et je dois batailler en début d'année pour que les élèves comprennent qu'il y a une différence entre un print(a) et un return a. Écrire une interface graphique propre est un boulot de spécialiste et nécessite beaucoup de connaissances très spécifiques à la bibliothèque utilisée. Certes, c'est ici une bibliothèque très simple, qui permet de faire des input et des print plus jolis. Mais bon, je crois qu'il est plus important de savoir ce qu'est un tableau ou une table de hachage.

Il y avait un chargé de TD de la prépa Agreg de l'ENS-Lyon qui avait dit à un élève qui l'emmerdait sur ce genre de questions : "Écoute, tu sors de la salle. Ensuite tu prends l'ascenseur et tu descends au -1. À gauche, il y a un labo de bio et dans un placard, il y a une boite avec marqué dessus : Drosophiles. Tu ouvres la boite, et une bonne fois pour toute, tu les e……."

Oui, Walter Rudin semble avoir défini dans un de ses bouquins la limite en un point comme la limite lorsque x tend vers a lorsque x est différent de a. Après, si tu lis une thèse, et que tu ne comprends pas quelle est la limite que le mec utilise, c'est pas la peine de faire des maths. Personnelement, dans le symbole de limite, je mets x \neq a si je veux parler de limite au sens dont tu parles, et j'emploie la limite que tu qualifies de "française" dans les cas général.

J'ai jamais eu de problème à soulever sur ce type de définition bien qu'ayant fait de la recherche en analyse aux USA. Et pour la compacité, si tu as un doute, tu demandes à la personne sa définition. Si c'est dans un papier, un peu de bon sens te permettra de voir rapidement si l'espace topologique est séparable ou non.

J'ai trouve cet article de Daniel Perrin : https://www.math.u-psud.fr/~perrin/CAPES/analyse/fonctions/definitiondelimite.pdf

Il milite pour la definition du Frido qui est bien evidemment la bonne, surtout si on veut enoncer des theoremes de composition. C'est la definition en prepa au programme de MPSI. Si il y a un programme de l'education nationale qui definit la limite au sens usuel comme la limite lorsque x tend vers a lorsque x est different de a, c'est effectivement une erreur grave car c'est ingerable pour la composition.

Mais j'aimerais bien voir un tel programme. J'ai un peu de mal a croire qu'il existe d'ailleurs, car les personnes qui l'auraient redige auraient clairement craque leur slip.

C'est ici, page 385

8.1.13 Limite pointée ou épointée ?

Ils laissent entendre que l'education nationale preconise de definir la limite en un point a comme limite lorsque x tend vers a pour x different de a. Ce n'est pas le cas dans le programme actuel de prepa MPSI. Qu'on soit sur R ou sur un espace topologique general ne change rien au probleme.

Ils laissent entendre que ca peut poser probleme lorsqu'on parle avec des etrangers. Je trouve que c'est un peu abuser. Il y a bien d'autres soucis lorsqu'on parle avec des etrangers, notamment le fait que N = {0, 1, 2, …} en France et N = {1, 2, 3, …} aux USA. J'ai meme vu Villani ecrire que N = {1, 2, 3, …} dans un cours ecrit en francais. Donc les habitudes americaines arrivent doucement en France. Je ne sais pas ce qui se passe dans d'autres pays comme l'Allemagne ou l'Italie par exemple.

Il y a une remarque du Frido qui laisse entendre qu'un programme de maths officiel donne une définition louche. Dans le programme de prépa (MPSI), ils ne disent pas vraiment quelle est la définition de la limite, mais ils disent que si une fonction a une limite en a et que f est défini en a, alors cette limite est f(a). Il est donc clair que dans ce programme, la définition de limite est celle qui est utilisée dans le Frido.

Juste par curiosité : quel est le programme de maths français qui dit que la limite en un point a est la limite lorsque x tend vers a pour x différent de a ?

Le premier argument pour supprimer ce genre de signature, c'est que ce n'est pas une fonction pure

Comme mon truc, c'est le HPC je me focalise souvent sur la performance. Du coup j'en oublie l'essentiel. C'est effectivement très important de travailler avec des fonctions pures dès que c'est possible. C'est d'ailleurs pour cela que je ne suis pas fan des exceptions (même si ça peut parfois être bien pratique). Dans un monde où le multithreading et la vectorisation sont de plus en plus importantes, les fonctions pures sont encore plus importantes qu'hier. L'article de John Carmack est excellent.

Renvoyer les objets par valeur a donc tous les avantages : côté fonctionnel et performance. Et pourtant, beaucoup résistent encore pour de sombres histoires de performance qui sont fausses et qu'ils n'ont d'ailleurs souvent jamais mesurée.

Je n'achète pas non plus l'exemple précis du "find_last index qui vérifie v[k] == 0"—sur le github. Probablement parce que ce n'est pas un problème que j'ai fréquemment à résoudre. J'ai rarement besoin de boucler à l'envers.

Je l'ai personnellement rencontré plusieurs fois. La dernière fois, c'était pour une détection d'un gros objet noir sur un fond blanc. Pour détecter le bord droit, on partait du côté droit et on avançait vers la gauche jusqu'à trouver du noir. Comme il y avait un rectangle de recherche à l'intérieur de l'image, on se retrouvait à gérer les a et les b comme dans le code présenté. Le code marchait très bien jusqu'au jour où une personne à mis la gauche du rectangle de recherche sur le bord gauche de l'image (a == 0) et qu'un objet n'était pas présent. Ce genre de bug n'avait a été découvert par un client. Et quand on se retrouve avec une ânerie pareille, on se dit que les types non signés, c'est vraiment mal.

Par contre, c’était il y a pas loin de 10 ans, avec Visual Studio 2003 ou 2005, je ne sais plus lequel des deux. À cette époque, passer par référence était une bonne pratique. Le langage a bien changé depuis :).

Oui. C'est vrai que c'est un des problèmes du C++ : les bonnes pratiques changent avec le temps.

J'ai le sentiment que tu as mal compris mes propos, voire que tu les déformes.

• Je ne connais aucun compilateur qui ne fait pas de "return value optimization". Gcc, Clang, Visual Studio, PGI, Intel font tous ces optimisations. Comme signalé dans la news, Gcc le fait même en -O0 et il faut une option speciale pour ne pas le faire. Donc vous pouvez renvoyer des gros objets par valeur. J'ai dit dans mon post qu'il fallait cependant faire attention à une ou deux règles pour cela. Voici un premier cas où on est sur que ces compilateurs optimisent.

U f(const T& input) {
   U output{};

    // n'importe quoi ensuite si tous les "codepath" contiennent un return U
}

Le deuxième cas est celui où le programme peut renvoyer des objets différents mais que ceux si sont tous construits sur le return.

U f(const T& input) {
    ...
    if (...) {
        return U{...};
    } else {
        return U{...};
    }
}

Évidemment, un code du type:

U f(const T& input) {
    U out0{...};
    U out1{...};

    if (...) {
        return out0;
    } else {
        return out1;
    }
}

ne peut pas bénificier de return value optimisation car à la construction des objets, on ne sait pas lequel va être renvoyé.

• Enfin l'exemple où je disais qu'il fallait le compilo Intel ou une version récente de Gcc pour voir une accéleration de performance avec un retour par valeur a été choisi parce qu'il est simple à expliquer. Si vous prenez un compilateur qui n'est pas aussi bon, les deux codes seront simplement aussi rapides sur cet exemple. À noter qu'il y a plein d'autres cas où même une vieille version de gcc produira un code plus performant avec un retour par valeur.

Donc je maintiens mon propos : pour la performance en C++, renvoyez par valeur.

J'ai beaucoup étudié les différents entiers et leur rapprt usage / performance, mon travail consistant à faire de la formation et du conseil en calcul HPC.

Entre les signés et les non signés, pour moi le choix est clair : il faut utiliser les entiers signés, sauf si on veut absolument que l'entier se comporte modulo 2^n, ou si malheureusement on y est contraint par la STL. Je sais que je peux m'attirer les foudres de nombreux programmeurs C++, mais Stroustrup, Sutter et Carruth sont avec moi, donc je me sens moins seul :-). Les entiers non signés devraient d'ailleurs être appelés entiers "modulo". Les entiers signés sont beaucoup moins dangereux que les non signés. Je donne un gag sur ma page, mais un autre est le suivant :

for (std::size_t k = 0; k < point.size() - 1; ++k) {
    draw_line(point[i], point[i +1]);
}

Le jour où point ne contient aucun, élément, c'est la catastrophe.

Au niveau performance, c'est 50 / 50 :
- La division est un peu plus rapide pour les entiers non signés. Pour les autres opérations c'est exactement pareil car ce sont les mêmes opérations au niveau assembleur.
- De nombreuses optimisations peuvent être faites sur les entiers signés comme : i < i + 1 est toujours vrai, a[i] et a[i + 1] sont cote à cote dans la mémoire, 10* i / 5 = 2 * i. Vous verrez que tout cela est faux pour les types non signés. Je vois souvent des compilateurs refuser certaines optimisations comme la vectorisation car les types non signés leur font peur. Une analyse fine montre souvent que cette vectorisation était quand même posssible, mais comme certaines autres ne le sont pas, la vue de ces entiers doit faire fuir les optimseurs :-)
Donc, mon conseil est de toujours traiter avec des types signés et de faire un static_cast vers un unsigned (ça ne génère aucun code assembleur) si on doit faire de nombreuses divisions dans une partie critique d'un code avec des entiers signés dont on sait qu'ils sont positifs. Au passage, cela ne m'est jamais arrivé de le faire :-)

Concernant la performance des entiers 32 bits ou 64 bits, pour indexer les boucles (je ne veux pas entendre parler d'itérateurs pour les tableaux, car les indices sont beaucoup plus pratique : on peut faire leur moyenne, ils ne sont pas invalidés quand on fait un resize, il n'existe pas d'iterateur efficace pour les tableaux multidimensionnels dès qu'on fait du padding, etc), il faut savoir que pour calculer p[i] lorsque p est un pointeur et i un entier, il faut une instruction d'assembleur pour faire passer i du 32 bit au 64 bit avant de l'ajouter à p. Donc les entiers 64-bit seraient en pratique un peu plus efficace que les entiers 32 bits pour indexer. Maintenant, les compilateurs font tellement de transformation sur une boucle (unrolling, vectorisation) que cette instruction n'a en pratique aucun effet notable. Bref, le match est 50-50 pour moi.
Par contre lorsqu'un traite des tableaux d'indices (on a beaucoup d'entiers), la il faut prendre le type le plus petit possible (donc 32-bit) pour que la vectorisation soit le plus efficace possible.
Sur d'autres algorithmes, cela dépend. Si par exemple, on cherche le i tel que v[i] est minimal dans un std::vector, il vaut mieux utiliser un entier 64-bit car les doubles sont sur 64-bits. Si on remplace le double par un float, il vaut mieux un indice codé sur 32-bit, comme le float. Cela permet au compilateur de gérer les lignes vectorielles plus efficacement.

En gros, dans un monde sans STL, mon conseil pour la performance et les indices des boucles est le suivant : utilisez un entier signé. Quand à savoir si il faut le prendre en 32 bit ou 64-bit, faites ce que vous voulez, mais sachez qu'il est parfois nécessaire de choisir le bon pour la performance ultime.

Je ferai cela une fois le projet plus avancé. Merci pour l'idée.

Ces optimisations, faites par tout compilateur qui se respecte, sont vraiment essentielles à connaitre. Leur meilleur connaissance permettrait à beaucoup de programmeurs de réaliser que pour des raisons de performance, il est important de renvoyer les objets par valeur.

On voit malheureusement encore beaucoup de personnes écrire des signatures comme :

void f(const T& input, U& output);

lorsque U est un objet un peu gros comme un std::vector ou un std::array. Souvent l'argument donné est que cela permet d'éviter d'avoir à faire une copie. Mais comme l'explique très bien cet article, c'est inutile car le compilateur peut (en respectant une ou deux règles simples) faire un court-circuit de la copie. Et il n'y a pas besoin de move semantics pour que cela soit efficace, donc n'hesitez pas à renvoyer par valeur des std::array. En conclusion, utilisez plutôt la signature :

U f(const T& input)

Cette signature permet de plus aux compilateurs de nombreuses optimisations impossibles avec la première signature. Prenez par exemple cette fonction:

void f(const std::array<double, 2>& x, std::array<double>& y) {
    y[0] = std::cos(x[0] + x[1]);
    y[1] = std::sin(x[0] + x[1]);
}

Elle ne peut pas être optimisée pour son usage courant. En effet, il faut savoir qu'on peut calculer très efficacement le cos et le sin d'un même angle (avec une seule instruction x86). Cela semble être le moment idéal pour utiliser cette instruction. Malheureusement, c'est impossible, car si on appelle f(x, x), on voit bien que la première ligne change x[0] et donc que les deux angles ne sont pas les mêmes. Si par contre on utilise la signature:

std::array<double, 2> f(const std::array<double>& x)

le compilateur peut faire l'optimisation et le code sera 2 fois plus rapide. Essayez d'écrire les deux fonctions et regardez l'assembleur produit (ou mieux mesurez le temps d'execution) et vous verrez qu'avec un bon compilateur (le compilo intel, ou une version récente de gcc), la seconde signature est beaucoup plus efficace. De nombreuses librairies, comme Boost::odeint limitent fortement leur performance car elles imposent la première signature.
De manière générale, l'aliasing induit par ces "retour par référence" peut être catastrophique pour la performance. J'ai réussit une fois à faire une x3 en performance rien qu'en changeant une telle signature. Comme il n'y avait plus d'aliasing sur des std::array, le compilateur a pu tout reordonner les calculs et pu profiter à fond du parallélisme d'instructions.

Bref, pour écrire des codes performants, renvoyez par valeur. Chandler Carruth, qui s'occupe de l'optimiseur de LLVM est un grand militant pour cela. Regardez ses conférences qui sont très instructives.

Enfin, afin de donner un contre exemple, il est quand même parfois intéressant d'avoir un retour par référence. comme sur ce code:

std::string line;
while(file.get_line(line)) {
    // process line
}

Comme les fichiers ont souvent des lignes de moins de 80 (ou 120) caractères, il va y avoir une allocation dynamique de mémoire au début de la boucle, puis plus aucune ensuite, sauf si la ligne grossit, mais c'est rare. Ma politique est de toujours renvoyer par valeurs, sauf si vous avez un benchmark clair qui montre que on est dans ce type de cas.

Au passage, je me permet de faire la pub pour un projet libre perso : des conteneurs efficaces pour le calcul haute performance. C'est ici : https://github.com/insideloop/InsideLoop

Je viens de lire rapidement la dépêche sur le court-circuit du constructeur par copie. A la fin, dans "Un code portable est moins performant que l’élision", j'emmetrai quelques reserves sur ce qui est dit.

• Je ne connais aucun compilateur qui ne fait pas l'elision de la copie lors du retour par valeur. Comme vous l'avez vu, gcc et clang nécessitent des options pour ne pas faire cette optimisation. Le retour par valeur est donc en général bien plus efficace est portable.

• Si vous voulez un petit jeu, essayez le code suivant:

  std::array"double, 2" f(const std::array"double, 2"& x) {
  std::array"double, 2" y{};
  y[0] = std::sin(x[0] + x[1]);
  y[1] = std::cos(x[0] + x[1]);
  return y;
  }

et écrivez le même code avec un retour "par référence". Vous verrez que le retour par valeur est 2 fois plus rapide (avec un bon compilateur. Il me semble qu'il faut soit icpc, soit gcc >= 6.0).