Quand une application fonctionne correctement mais bien trop lentement, ou mange trop de place disque ou mémoire, le dilemme qui se pose est le suivant :
- investir dans du matos plus récent/plus puissant, ou mettre à jour l’actuel,
ou :
- demander à un humain de voir ce qui cloche dans le logiciel pour l’améliorer (paramétrage ou correction de code, c’est pareil, il y a investissement de temps de cerveau).

Dans un monde idéal, l’optimisation manuelle, pérenne, serait systématique, et l’investissement financier en matériel serait un dernier recours, quand il devient impossible de tirer plus de jus du matériel existant (ou au détriment de la maintenabilité par exemple).

Jeff Atwood de Codinghorror a une réponse assez affirmative : Hardware is Cheap, Programmers are Expensive. Il part du principe que payer un humain est quasiment toujours plus cher qu’investir dans du matériel. Le sujet est récurrent sur un autre repaire de geeks, professionnels ou amateurs.

L’avantage du hardware

Atwood défend sa position. D’abord : l’optimisation sera un échec si on ne sait pas exactement quoi optimiser. Ensuite : l’utilisateur ne verra pas la différence en-dessous d’un certain seuil. Une optimisation menée avant des mesures de performance et d’identification des vrais goulots d’étranglement ne sert à rien. Un des ses proverbes :

Rules of Optimization:

Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.

Règles d’optimisation :
Règle 1 : Ne le faites pas.
Règle 2 (experts uniquement) : Ne le faites pas encore.

Autre exemple, les micro-optimisations inutiles : Jeff a comparé plusieurs implémentations différentes d’un test de chaîne vide[1]. Verdict : gratter 30 ms sur un million d’itérations n’a strictement aucune importance !

D’autres arguments s’appliquent :

  • le coût du matériel est parfois effectivement dérisoire pour le gain obtenu (100 € pour un gros disque ou pour 2 Go de RAM !) ;
  • le matériel acheté pour accélérer un système un peu lent est recyclable et pourra resservir ailleurs, ou repousser le remplacement par une autre machine ;
  • ne pas modifier le logiciel permet de ne pas y introduire de bug (un coût caché majeur évité ) ;
  • les règles comptables poussent plutôt à acheter du matériel amortissable que payer un humain (et ses cotisations sociales) (j’ai personnellement beaucoup de mal avec la logique comptable et fiscale) ;
  • rajouter du matériel coûte rarement en performance ; cependant devoir ajouter un nouveau développeur dans une équipe débordée a des coûts énormes en formation, communication, espace de bureau, administration.

La loi de Moore et ses dérivés, sur l’augmentation sans fin de la puissance disponible pour un budget raisonnable, encouragent ce comportement : Microsoft et plein d’autres (Business Objects en tête) ajoutent des fonctions d’abord, et ne se soucient des performances qu’après. Windows 3.1 ou Vista, même combat, il suffit d’attendre que le marché remplace les machines les moins récentes par des neuves. La tentation est grande pour tout éditeur de logiciel.

Plus l’environnement concerné est petit, plus Atwood a raison. Une PME avec trois serveurs et un administrateur/développeur seul et débordé trouvera plus rapide et logique de payer deux barrettes voire de remplacer un trop petit serveur que de se lancer dans la réécriture d’une application.

Optimiser un datacenter ou une box

Évidemment, la règle n’est pas universelle.

Un cas extrême : pour Google, un gain de 1 % sur un demi-million de serveurs, c’est 5000 serveurs de gagnés, et à ce prix, payer un ingénieur à plein temps sur des micro-optimisations est rentable. Quand on s’appelle Google, on peut investir carrément dans le développement des langages pour gagner à la source. Le cas de Google est extrême, puisque l’entreprise a la surface et les compétences pour rentabiliser du matériel conçu spécialement pour ses besoins.

(Ajout de 2013 : La librairie de compression zopfli, libérée par Google récemment, est un exemple parfait d’optimisation. En un temps décuple, voire centuple, par rapport aux algorithmes précédents, cette librairie offre un gain de compression de quelques pour cent supplémentaires. Dérisoire ? Le CPU ne manque pas dans les datacenters ; par contre chaque économie de bande passante est bonne à prendre.)

De manière plus générale, tous les environnements où l’investissement matériel est massif, ou simplement coûteux, ont plutôt intérêt à miser sur des améliorations logicielles : supercalculateurs, gros serveurs bancaires…

Tous les domaines où la mise à jour ne serait pas que coûteuse, mais est carrément impossible car le matériel n’est plus sous la main, sont également concernés, notamment tout ce qui concerne l’embarqué : les Freebox reçoivent facilement des mises à jour par le réseau, mais Free ne peut leur rajouter une barrette de RAM sans un ruineux échange ; le firmware d’une console ou d’un calculateur de voiture peut être patché, mais on ne changera plus le processeur ; etc.

La revanche du meatware

Écologiquement parlant, le meatware a toujours raison. Des serveurs et barrettes en plus, c’est du gaspillage. Tandis que la réflexion humaine ne pollue pas (pas plus que la sieste en tout cas). En entreprise cependant, l’argument porte peu.

Un autre argument quasi-économique va dans le même sens : celui du temps perdu en paperasse. Dans certains endroits dysfonctionnels, il coûtera plus cher en temps, énervement, efforts, et au final argent, de faire acheter le matériel adéquat, que de perdre des jours (éventuellement de prestataire coûteux !) dans l’optimisation ou la chasse aux octets perdus. Le coût caché de la mesquinerie des services achats peut être effroyable…

Autre cas extrême, celui où le temps de cerveau est faible ou nul. Pour des projets personnels, pour un étudiant, un chômeur, un habitant d’un pays sous-développé, le coût du matériel est démesuré et celui du temps disponible (celui d’employés peu payés) comparativement dérisoire. Voire nul dans le cas où les employés ne comptent pas leurs heures. Là il s’agit en fait de faire porter par d’autres (la famille de l’employé, du prestataire, de l’autoentrepreneur…) le coût.

Dans les calculs de rentabilité, il faut aussi tenir compte du long terme quand la masse de données à traiter augmente. Si par exemple l’algorithme bien pensé est en O(N) (temps de calcul proportionnel à la taille du jeu de données), alors que l’algorithme vite torché pas optimisé est en O(N²), doubler le jeu de données peut signifier ajouter un serveur dans le premier cas, et trois autres dans le second. Comme l’augmentation dudit jeu de données ne se fera pas du jour au lendemain, les tenants du « matériel d’abord, réflexion ensuite » gaspilleront deux ou trois serveurs avant de se dire qu’une optimisation est vraiment nécessaire. (Des gens compétents ou avertis peuvent tout de même voir venir le coup du matériel qui ne suivra pas.)

Dans le pire des cas, pour un problème non parallélisable, le problème ne consistera pas à ajouter des serveurs, mais à remplacer du matériel par un deux fois plus rapide contre un autre quatre fois plus rapide, et le coût n’est PAS proportionnel.

Ajoutons les coûts cachés (ou plutôt : non comptabilisés) quand un système grandit rapidement : plus de disques, plus de serveurs, cela veut dire plus de composants faillibles, plus d’administration, plus d’interactions possibles, plus de problèmes de synchronisation, plus d’électricité consommée, plus de frais de climatisation…

Sauver des vies par l’optimisation

Les systèmes d’exploitation (ou, plus généralement, tout logiciel massivement utilisé) sont un cas à part, pas technologiquement mais économiquement : il est rentable pour la société de payer des gens à optimiser chaque miette de Linux ou Windows, ne serait-ce que pour réduire les besoins des machines, et gratter un peu sur la consommation. Écologiquement, cela se défend, mais entre en conflit ouvert avec la course aux fonctionnalités ou à l’apparence qui en jette — Vista est l’exemple caricatural.

L’anecdote est caricaturale et connue : pendant la conception du Macintosh, Steve Jobs a persuadé ses développeurs d’accélérer le temps de démarrage de quelques secondes, en faisant valoir le nombre de vies économisées en mettant bout à bout toutes les minutes gagnées deci delà.

Généralisons : les machines actuelles, qui bootent en dix fois plus de temps qu’un Mac de 1984, gaspillent chaque matin des millions d’heures de productivité, sinon de vie humaine. Le simple fait que la mise en veille de mon Ubuntu échoue mais que celle du Powerbook, elle, fonctionne, est un argument puissant pour le choix de l’utilisation de telle ou telle machine quand je veux juste regarder mon courrier le soir en revenant du boulot.

À l’inverse, une non-optimisation qui impose un surcoût de 100 € par machine (en mémoire supplémentaire, en carte graphique récente…) finit par coûter à l’économie, donc l’humanité, des milliards. Les constructeurs informatiques ont d’ailleurs été amèrement déçus par le flop relatif de Vista, dont la gourmandise imposait souvent un changement de machines. Je ne compte pas les systèmes (Linux compris) qui réclament des ressources supplémentaires à chaque génération. Un nouvel Ubuntu ou un nouveau Mac OS X ne réclament tout de même pas quasi-systématiquement une mise à jour majeure de la machine ; l’obsolescence artificielle qu’ils imposent se rapproche un peu de celle, technique, due au taux de mortalité de l’électronique actuelle (certes un autre scandale).

Bref, si un éditeur de logiciel décide de passer outre des optimisations, il refile simplement à ses clients le coût qu’il ne veut pas assumer. Pour sa défense, il faut reconnaître que nombre d’applications actuelles ne gagneraient rien à être optimisées à grand frais quand elles tournent sur des machines dégoulinantes de RAM et dopées aux GHz. Cercle vicieux.

C’est dommage, car justement la distribution gratuite et quasi-instantanée de chaque amélioration est le meilleur moyen de multiplier démesurément la productivité d’un simple programmeur (remarque, je crois, de Frederick P. Brooks à la fin de la dernière édition de The Mythical Man-Month) — et cela arrive effectivement tout de même souvent. Mais les clients encaisseraient des gains et l’éditeur paierait le développeur sans rien gagner (sinon une meilleure réputation).

Les gains qualitatifs

Quand au boulot je dois optimiser le temps d’exécution d’un rapport, en général en persuadant Oracle de préférer tel ou tel chemin d’exécution, les gains sont rarement faibles : une optimisation réussie fait gagner un ordre de grandeur à l’exécution, sinon deux. Dans les cas où je baisse les bras, les modifications éventuelles n’apporteraient rien par rapport aux coûts cachés (maintenance, risque de mise en production, tests à refaire…).

Dans le cas favorable, le gain de quantitatif peut devenir qualitatif. Un rapport critique édité chaque semaine peut devenir quotidien. J’ai vu une usine faire sa clôture comptable mensuelle en quelques heures au lieu de plusieurs jours — sa multinationale y avait un intérêt majeur vu ce que cela a coûté.

Les économies de ressources se cumulent : une optimisation qui libère des ressources machines — ou humaines — permet de faire « respirer » d’autres processus, de réduire la charge d’administration…

Le phénomène peut s’emballer dans l’autre sens : un rapport hebdomadaire intéressant beaucoup de monde et archi-optimisé risque d’être exécuté chaque jour, voire chaque heure, par la suite, annihilant le gain technique (à première vue, car à présent la charge peut être étalée) — mais fournissant au moins un service rendu supérieur.

Plus généralement, les avancées de l’informatique des deux dernières décennies ont permis à des milliers de processus de devenir quasiment instantanés au lieu d’attendre leur tour dans un batch de nuit ou hebdomadaire. Pour la hiérarchie, les « tableaux de bord » et autres outils de contrôle sont souvent mis à jour quotidiennement. Pour le client/utilisateur/administré, ses demandes sont prises en compte en général beaucoup plus rapidement.

Au final, le cas n’est pas rare où une optimisation bien pensée transforme un énorme batch de fin de semaine en requête quotidienne, libérant des plages de temps considérables, des serveurs, voire un humain qui n’a plus besoin de surveiller une machine hors des horaires classiques de bureau. Les gains sont peut-être cachés ou non financiers, en tout cas évidents.

Pour revenir au cas de Google ou d’un éditeur, ce gain est re-multiplié sur chaque installation.

Et il faut penser que les communications et les serveurs ne sont qu’un élément. On n’a parfois pas juste accumulé les serveurs, mais repensé nombre de flux, de A à Z, aussi bien fonctionnellement que techniquement. On n’a pas inventé l’industrie moderne en multipliant les usines identiques, mais en en repensant le fonctionnement.

Concrètement

Comme dans tout conflit entre deux théories, le compromis nait de la confrontation à la vie réelle et à l’application au cas particulier.

  • Faut-il ou pas utiliser des frameworks genre Hibernate, ou préférer le C à python ou l’inverse ? Cela dépend du développeur, du besoin, du gain apporté en fonctionnalité (et donc en temps de développement) par les outils par rapport à leur lourdeur irréductible (overhead) et à leurs limites (coût caché énorme s’il faut déployer des trésors d’imagination pour forcer un outil à faire ce qui n’a jamais été prévu).
  • Quels sont les vrais problèmes ? La vraie cause du problème de performance ? (Certes l’analyse réclame elle aussi du temps de cervelle, alors que dégainer une barrette de RAM est trivial.)
  • Le must : ce qui permet au développeur d’être lui-même plus productif. Optimiser les fonctions de test, accélérer l’application de manière qu’elle devienne simplement testable, améliorer la machine du développeur (piège ! il risque de ne plus voir les ralentissements sur les machines moins bien dotées !) ou… lui donner un deuxième moniteur (en affichage vertical pour voir plus de code, pas des films).
  • Comme souvent, les vrais gisements de productivité du développeur résident non dans le hardware mais dans la communication, les spécifications claires (ou qui peuvent être éclaircies facilement), stables, la documentation (éternel parent pauvre, et également une charge inutile si elle est mal faite, et pas automatisée au maximum), le passage de connaissance entre collègues, etc.

Et on conclura en remarquant que les gains de productivité matériels et humains se complètent : d’abord du jus de cervelle sont nés l’ordinateur, le FORTRAN, le garbage collection, le web ; puis l’investissement en matériel récent les a rendus utilisables ; enfin une masse de nouvelles applications sont devenues économiquement possibles en libérant l’esprit du programmeur.

Note

[1] Question à ceux qui connaissent : c’est du VB ou du C# ?