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.

samedi 28 juin 2014

Tableaux de taille variable

Dernière dans la liste des features C++14 dont je parlerai pour g++4.9, voici les tableaux à taille variable. Alors que jusqu'à présent, la taille d'un tableau créé sur la pile devait être une constante, g++4.9 permet de prendre une variable à la place. Le standard ne définit pas si la mémoire allouée par un tableau de taille variable doit l'être sur la pile ou sur le tas, mais l'idée, bien entendu, est de favoriser la pile et économiser ainsi une allocation coûteuse.

Voyons sans plus attendre un programme d'exemple:

#include <iostream>

int main(int argc, char ** argv)
{
  int array[argc];
  for(int index = 0; index < argc; ++index)
  {
    array[index] = index;
  }
  
  for(int index : array)
  {
    std::cout << index << std::endl;
  }

  return 0;
}

Le programme met dans un tableau la liste des entiers de 0 au nombre d'arguments de la commande. Valgrind confirme qu'aucune allocation n'a été effectuée, le tableau a donc été créé sur la pile.

==15403== HEAP SUMMARY:
==15403==     in use at exit: 0 bytes in 0 blocks
==15403==   total heap usage: 1 allocs, 1 frees, 20 bytes allocated
==15403== 
==15403== All heap blocks were freed -- no leaks are possible

Pour le fun, j'ai ré-implémenté le même programme en utilisant un std::vector, et Valgrind indique bien une allocation.

La même syntaxe étant utilisée pour les tableaux fixes et variables, je pense qu'il y a un réel risque d'utiliser l'un en pensant utiliser l'autre. D'un côté, il faudra faire attention à ne pas exploser la pile. De l'autre, il est tellement peu courant de nos jours d'utiliser un tableau directement (std::array est passé par là), que le programmeur devrait savoir à quoi s'attendre. Et parfois, économiser une microseconde dans une routine peut faire toute la différence.

samedi 21 juin 2014

Nombres en binaire

Continuons sur notre exploration de g++4.9. Toujours pas révolutionnaire, mais plutôt utile, la possibilité d'avoir des constantes binaires dans le code source. En plus de la notation 0x pour l'hexadécimal et 0 pour l'octal, voici 0b pour le binaire. Démonstration:

#include <iostream>

int main()
{
  std::cout << 130 << std::endl;
  std::cout << 0x1a << std::endl;
  std::cout << 077 << std::endl;
  std::cout << 0b1000 << std::endl;
  std::cout << 0b110'1000 << std::endl;

  return 0;
}

Le programme affiche:

130
26
63
8
104

Notons que les séparateurs de chiffres, décrits ici, fonctionnent aussi bien pour le binaire, ce qui va certainement améliorer la lisibilité.

lundi 9 juin 2014

Un Ohmmètre improvisé

Installation de luminaires, aujourd'hui. Une fois coupé le câble pour le raccourcir, surprise, les fils électriques ne sont pas marqués! Nous nous sommes retrouvés gros-Jean comme devant, avec nos trois fils d'un côté et les douilles de l'autre.

Après avoir tourné dans l'appart' à la recherche de quelque chose pour trouver le bon fil, j'ai finalement eu une idée: utiliser les fils des haut-parleurs de la hifi.

Donc, on met la musique, puis débranchage d'un des fils du haut-parleur, contact avec une des bornes dans la douille d'un côté, et contact avec un des fils de la lampe dans le haut parleur de l'autre. Essayer les deux bornes de la douille. Musique, pas musique, phase, neutre, et terre!

C'est quand même plus pratique avec un vrai ohmmètre. Ça fera un bon cadeau de Noël.