lundi 28 juillet 2014

De l'usage des lambdas

Enfin lancé à pleine vapeur sur une base de code sous g++4.8 (j'en parlais ici), je peux utiliser à fond les toutes dernières fonctionnalités du standard. En particulier, j'utilise beaucoup le range-based for, et le mot-clé override. Et, bien sûr, les lambdas.

Le cas des lambdas est intéressant. J'en rêvais pour les mettre dans mes std::for_each, lesquels avaient l'avantage d'être très brefs, en comparaison des déclarations d'itérateurs à ralonge. Les variables auto ont rendu les itérateurs bien plus agréables à utiliser, et le range-based for a fini de combler l'écart. Pour une boucle simple, un std::for_each avec un lambda est plutôt moins pratique qu'un for, en particulier, il faut rentrer begin, end, et le type du paramètre dans la lambda (en attendant les lambdas polymorphiques), à comparer à un for(auto && element : container){...}.

Reste les autres cas, en particulier les tris. Notre bon vieux std::sort veut un comparateur, et lui donner une lambda est rudement pratique. Il y a également std::binary_search dans la même veine.

C'est là que je trouve que déclarer sa lambda en dehors de l'algorithme a beaucoup d'avantages. D'une part, c'est réutilisable, s'il faut trier plusieurs conteneurs avec le même comparateur. Et d'autre part, c'est beaucoup plus lisible.

auto comparator = [](const Element & left, const Element & right)
  {return left._name < right._name;};
[...]
std::sort(c.begin(), c.end(), comparator);

Au final, cela permet de voir sa lambda plus comme un foncteur local avec une syntaxe très condensée (ce qu'était déjà le std::bind, au final, même si l'absence d'auto à l'époque rendait sa déclaration absolument épouvantable lorsque ce n'était pas un temporaire).

C'est quand même beaucoup plus joli comme cela, non?

samedi 19 juillet 2014

C++ et Microsoft Office

Que de présentations intéressantes à la CPP Con 2014, la conférence C++ qui aura lieu en Septembre. Malheureusement, je peux toujours me brosser pour que mon employeur m'envoie à Bellevue, WA (où, comme son nom l'indique, la vue est tout à fait magnifique).

En particulier, des développeurs de MS Office expliqueront comment ils développent en C++ sur Android, IOS, Windows et Mac pour tenter de garder la base de code la plus générique possible. J'espère bien qu'il y aura des vidéos.

Blender et projet Gooseberry

Je viens de voir passer sur mon compte en banque le premier prélèvement pour Gooseberry, le projet pour le prochain film de l'équipe Blender. C'est l'occasion de revenir sur l'actualité du projet

C'était le 6 mai que les responsables du projet annonçaient que malheureusement, la levée de fond n'avait pas permis de réunir suffisamment pour produire le long-métrage d'animation dont ils rêvaient. Cette campagne était très ambitieuse, et cet échec n'est donc pas vraiment une surprise. Cependant, les fonds sont suffisants pour créer un court métrage de 10 à 15 minutes. Une fois ce pilote développé, les responsables du projet reviendront sur leurs options pour transformer ce pilote en long-métrage.

Je comprends parfaitement l'envie de passer à l'échelle supérieure et de développer un long-métrage. C'est un boulot très différent et particulièrement intéressant de développer une histoire sur 1h30 plutôt que 10 minutes, et les contraintes techniques sont toutes autres (je n'ose imaginer le temps de rendu!). Mais plus personnellement, le court métrage me convient tout à fait. C'est l'espoir de voir un produit fini plus tôt, et je trouve que dans l'animation, les productions les plus courtes sont souvent les meilleures: un bon Tex Avery n'a vraiment pas à rougir en comparaison des mastodontes d'aujourd'hui type "Hotel Transylvania" ou même "Ice Age", qui commence sérieusement à s'essouffler. Je continuerai bien entendu à soutenir l'équipe Blender dans tous leurs projets.

Plus récemment, les responsables confirmaient le démarrage de la production du pilote, en particulier le travail d'écriture et le concept art.

J'avoue ne pas regarder de trop près, car je veux garder la surprise pour quand le film sera disponible!

lundi 7 juillet 2014

Goooooold linker!!!!!

C'est sous ce nom très JamesBondien que se cache un nouvel éditeur de liens, développé par Google (Gold = Google ld), avec comme but de meilleures performances lors de la compilation de grosses solutions, en remplacement du vénérable ld.

Gold est optimisé pour la vitesse. Lier de grosses bibliothèques ou de gros exécutables est donc nettement plus rapide. Sur une de nos bibliothèques mammouth (1 GB avec les informations de débug), l'édition de liens est passée de 1 minute à 40 secondes, ce qui est très agréable lorsque l'on doit effectuer cette opération des dizaines de fois par jour.

Gold permet d'effectuer l'édition de liens de manière incrémentale. En construisant le binaire de manière à laisser de l'espace autour des unités de compilation, l'éditeur de liens peut simplement remplacer le bout qui a changé et garder le reste. Cette fonctionnalité m'intéresse particulièrement: très souvent, je fais un changement trivial dans un fichier, lequel est compilé en quelques secondes. Mais c'est ensuite que je dois attendre une bonne minute que l'éditeur de liens reconstruise l'ensemble du binaire. Si la mémoire libre est rare, je perds mon cache disque, et chaque fichier objet doit être relu du disque. Autant dire, je peux aller me faire un thé, cueillette et macération incluses.

J'ai donc essayé tout ce que j'ai pu, mais malheureusement, je n'ai pas réussi à faire fonctionner le mode incrémental pour la création de bibliothèques dynamiques, alors que cela semble se passer plutôt bien lorsque l'on s'occupe directement des exécutables. Pas de bol, la grande majorité du code de notre solution est incluse dans de grosses bibliothèques dynamiques, c'était donc cette phase qui était le principal goulot d'étranglement. Il va me falloir y passer un peu plus de temps pour comprendre ce qui se passe, je n'ai pas trouvé de documentation précise sur ce point.

À noter que Gold est également l'éditeur de liens permettant de faire de l'optimisation au "link time" (LTO). C'est une fonctionnalité relativement récente de g++, qui permet d'optimiser le programme globalement, plutôt que de considérer chaque unité de compilation de manière séparée. Cela repousse une grosse partie du temps de compilation dans l'éditeur de liens. Je compte bien m'intéresser très bientôt à la LTO, attendez-vous à bientôt en avoir des nouvelles ici.

Gold est multitheadé. La version que j'ai pu tester n'avait malheureusement pas été compilée avec cette fonctionnalité, je n'ai donc pas pu vérifier si cela changeait grand chose. En particulier, j'ai cru comprendre que c'était surtout utile pour la LTO.

Hormis quelques cas particuliers où Gold ne fonctionne pas (comme par exemple les modules du noyau Linux), il n'y a pas vraiment de raisons pour ne pas y passer. Gold est devenu un projet officiel GNU, et continuera vraisemblablement à s'améliorer, là où ld a stagné pendant si longtemps.