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# ?
5 réactions
1 De vpo - 01/10/2009, 10:32
Tu es pénible aussi de mettre des billets si intéressants et si long à des heures si tardives. Ensuite, je me couche tard et j'ai mal au crane le lendemain matin au boulot :-)
2 De Arnest - 01/10/2009, 12:47
Article intéressant. A noter que la durée de création d'un rapport est inversement proportionnelle a sa durée d'utilisation.
Cet article me permet de comprendre l'engouement actuel pour le BPM (Business Performance Management) -> http://en.wikipedia.org/wiki/Busine... qui consiste a tirer les données de tous ces vieux systèmes, de les combiner et de les présenter sous une nouvelle forme :-)
3 De Le webmestre - 01/10/2009, 15:26
@vpo : Je sais, je tartine trop, et j’ai arrêté de découper mes articles trop longs. Par contre rien ne t’interdit d’attendre le lendemain pour lire :-)
@Arnest : Ah, je connaissais pas le BPM. La différence avec le BI que je fais semble subtile. Mais effectivement, séparer les systèmes d’analyse (BI et autres) des systèmes de production est un moyen de réduire la complexité des premiers qui doivent donc se limiter à une seule tâche, la prod’ en transactionnel. Moi qui en était resté à de basses considérations de performances alors que c’est une bête application du « diviser pour régner » :-)
4 De Actualité Décalée - 13/07/2012, 00:08
J'ai le coup de foudre pour ce billet.
Les clients demandent toujours les derniers batiment de guerre pour obtenir plus de performance.... N'étant pas commercial pour la société où je travaille, et perso je m'en fous, je n'ai pas le droit de conseiller ^^
En même temps ça m'arrange, car pour mon PC perso qui à 7 ans, j'ai un Quad Core avec un honnorable cache L2 ! et 8 Go de DDR2 800 (de la récup aussi) et je sais plus quoi, et comme je travaille énormément dessus pour la prise de contrôle de machine à distance, télémaintenance, progs, recherches, infogérance (détente ;-) ), avec mes 4 écrans, mes 50 000 bureaux virtuelles, et 40 000 terminaux et fenêtres (j'exagère), j'ai ajouté un vieux HDD pata à 7200 tours INCREVABLE et je l'ai dédié pour la Swap afin de pas la foutre sur mon raid6 de ma debian afin d'aumenter mes performances et ma productivité.
Résultats : Plutôt que de me payer un i7 et donc, une nouvelle carte mère, et 16 Go de RAM, etc, etc, pour un petit prix de 500 € je crois ? ou plus ?
ça ma couté zéro euro (que de la récupération que des sociétés foutes à la poubelle (oui, je fais les poubelles informatique pour mon bureau qui est d'une puissance démesuré) ) et mon PC atomique carbure un maximum avec ma Debian Squeeze...
@webmaster : j'ai juste un conseil à te demander
Mon HDD pata 7200tours dédié à la swap me donne de bonne performance pour la mémoire virtuelle, j'ai aucune latence ou plantage. Cependant, j'ai un trouble pshychatrique en informatique et j'aimerai bien que tu m'orientes :
Penses-tu que si je dédie un SSD puissance maximum j'obtiendrai d'aussi bonne performance que 16 Go de RAM ddr2 ?
Tu le sais mieux que moi, la DDR2 offre de très bonne performance, autant que la DDR3 mais comme d'habitude, elle coute 3 fois plus cher neuve.
Exemple, neuve, une DDR2 800 2 Go coute en moyenne 25 € et une DDR3 sans aucune perfomance en plus pour ce que je fais, coute 6 € !!!
Et si je veux 16 Go de ram physique (j'en ai réellement besoin, je déconne pas) je suis obligé de changer ma carte mère et ça ! je veux pas ! j'y tiens beaucoup !
J'attends ton avis,
Merci Monsieur !
J'ai testé un vaio i7 avec seven et matos surdimmensionné, c'est inexploitable pour un professionnel en informatique générale, et mêmes nos clients se plaignent...
Conclusion, J'emmerde le marketing des constructeurs qui nous prennent vraiment pour des brelles
5 De Le webmestre - 14/07/2012, 15:07
@AD : S'il y a besoin de 16 Go, il y a besoin de 16 Go. Aprèsn DDR2, DDR3, j'en sais fichtre rien, moi.
Je sais par contre qu'à bugdet équivalent je mettrais plus mon fric dans un SSD que dans une masse de RAM énorme ou hyper-performante, vu que le SSD a un impact énorme sur l'accès aux fichiers, donc tout le démarrage, les fichiers les plus utilistés, et le swap.