Discussion :

[Cedric Chevalier]

Faut-il investir dans l’optimisation du code ou l’achat de matériel puissant ?
un blogueur opte pour le second cas, car les programmeurs coûtent cher

Si vous deviez améliorer les performances d’une application, opteriez-vous pour l’optimisation du code ou pour l’achat de nouveaux appareils puissants ? Pour Jeff Atwood, créateur du site StackOverflow, la question ne devrait même pas se poser.

Selon celui-ci, les programmeurs coûtent excessivement cher alors que les périphériques puissants comme les serveurs le sont moins. D’après Jeff Atwood, la paie mensuelle du plus modeste des programmeurs aux États-Unis lui a permis d’acheter deux serveurs puissants, ainsi qu’un disque de sauvegarde sans compter les unités redondantes de disques pour StackOverflow.


D’après Jeff, les gains de performances et de productivité réalisés avec l’achat de ce matériel haut de gamme se sont faits rapidement ressentir. Autrement dit, avec un bon matériel, l’amélioration des performances suit toujours. Cependant, même en embauchant des programmeurs qu’elle paye modestement, une entreprise court un risque énorme.

La probabilité que la productivité de ces programmeurs soit faible de façon à ce que la firme n’ait pas un retour sur investissement conséquent dans le temps est élevée. Jeff dit d’ailleurs qu’il comprend maintenant les entreprises qui mettent constamment leurs programmeurs sous pression.

Par contre, il reconnaît que la machine seule ne suffit pas. Un programmeur expert devra se charger de produire du code optimisé pour le matériel haut de gamme, de façon à tirer pleinement parti de la totalité de sa puissance.

Une fois encore, il met en garde. Déjà que ces programmeurs experts coûteront horriblement cher, l’optimisation est une pratique déconseillée, voire même dangereuse. Il cite M.A Jackson qui donne des règles d’or sur l’optimisation du code « Règle 1: Ne jamais l’utiliser. Règle 2: Si vous êtes expert, ne l’utilisez pas maintenant. »

Autrement dit, Jeff conseille encore une fois d’utiliser les performances de calcul des nouveaux périphériques au profit d’investissements dans du code optimisé.

Source : Coding Horror

Et vous ?

Que pensez-vous du point de vue de Jeff Atwood ?

Et si vous aviez le choix entre optimiser le code et améliorer les performances via les équipements, que choisiriez-vous ?

[el_slapper]

Il a quelques années, son article. J'ai du le mettre en lien deux ou trois fois dans le coin.....

Et surtout, l'article original dit qu'on ferait mieux de mettre du matos sur les problèmes de performances pour utiliser les programmeurs à faire de la valeur ajoutée, pas à virer tous les programmeurs.

On est pas vendredi, pourtant...

[Paul TOTH]

sur la question des performances c'est peut-être pas faux...acheter une machine suffisamment puissante pour faire tourner une appli c'est une quantité mesurable, le temps que mettra le développeur pour rendre l'application plus véloce sur la machine existante l'est moins.

par contre, du point de vu fiabilité, la plus puissante des machines ne corrigera jamais les bugs toute seule

[gros_rougeot]

Malheureusement il a raison.

Conséquences : trop de logiciel récents et grands publics rament sur de vieilles bécanes alors qu'ils n'ont pas plus de fonctionnalités que leurs anciennes versions.

[AoCannaille]

Si je me souviens bien de mes cours d'algo d'IUT, en particulier de ceux sur la compléxité, il me semble que passer un algo de n^3 à nlog(n) permettait de faire passer des calculs d'un an à quelques minutes.

Il faut cibler le niveau d'optim. Optimiser des variables intermédiaires, un passage de boucle par-ci par là avec while/do while ça ne vaut effectivement probablement pas le coup. En particulier si l'algo devient moins clair donc moins maintenable.

Par contre, l'optim' basique des algos reste en ce sens indispensable.

de mémoire Knuth disait que les étapes dans l’algorithmique c'était :
1. On écrit un algo naïf qui répond aux exigences fonctionnelles
2. on l'optimise
3. on le rend "propre" et maintenable (nom de variable, indentation, commentaires etc...)


pour moi, en résumé:
L'optimisation du code à la conception reste indispensable.
L'optimisation du code en production, pour un delta inférieur à n² peut être résolu en changeant de matos.

[Washmid]

C'est pas toujours vrai. Dans ma boite, sur du matériel mobile, on a eu un investissement d'un million d'euros rien que le matériel (ajoutez à ça les frais annexes) pour une appli sur laquelle bosse un dev et demie.

Suite à des problèmes de performances justement, on a eu le choix entre réinvestir à nouveau dans du matériel ou mettre un dev sur l'optimisation de code pendant 6 mois... Le calcul est vite fait.

[germinolegrand]

Visiblement pour FB, ça coûte nettement moins cher d'investir dans l'optimisation (et ils emploient des experts -cher- et pas des moindres !) que dans les machines comme nous le précise Andrei Alexandrescu récemment .

remarque de JolyLoic à ce sujet

[Sirus64]

Que pensez-vous du point de vue de Jeff Atwood ?
Il a tord et raison. Il a tord car il faut d'abord trouver le goulot d'étranglement. Il a raison dans le sens ou changer le code n'apporte pas le retour sur investissement.

Et si vous aviez le choix entre optimiser le code et améliorer les performances via les équipements, que choisiriez-vous ?
En dev, on cherche à optimiser un minimum dans un temps raisonnable (ie. dans le temps alloué pour créer cette partie du projet).
En production, on commence par faire des analyses de performances et on réhausse les serveurs ou on ajoute des serveurs avant d'ouvrir le code (c'est aussi plus rapide à faire qu'analyser le code....)

[kolodz]

Le propos se résume plus à ces étapes :

1. Throw cheap, faster hardware at the performance problem.
2. If the application now meets your performance goals, stop.
3. Benchmark your code to identify specifically where the performance problems are.
4. Analyze and optimize the areas that you identified in the previous step.
5. If the application now meets your performance goals, stop.
6. Go to step 1.

Pour les développeurs que je connais, ceux-ci ont déjà des machines relativement puissante à leur disposition pour leur développement. Dans un cas d'une application d'entreprise, il est certes plus facile d'acheter un second serveur.

M.A Jackson qui donne des règles d’or sur l’optimisation du code « Règle 1: Ne jamais l’utiliser. Règle 2: Si vous êtes expert, ne l’utilisez pas maintenant. »

Cela me fait penser à deux exemples vue dans une application :
1. Le cache plus lent que le calcul des données qu'il met en cache.
2. L'algorithme qui remplace la bonne requête sur base de donnée.

Cette règle d'or s'applique directement au premier cas. Mais pour le second, je considère la mise en place de la bonne requête est une optimisation en plus d'être une règle de codage.

Pour moi une application lente est une application mal codé. Mettre une machine plus puissante, c'est comme mettre plus d'essence dans une voiture qui à le réservoir percé. Ça va bien pour faire les 10 bornes pour rentrer chez soit le vendredi soir.

Cordialement,
Patrick Kolodziejczyk.

[grunk]

Visiblement pour FB, ça coûte nettement moins cher d'investir dans l'optimisation (et ils emploient des experts -cher- et pas des moindres !) que dans les machines comme nous le précise Andrei Alexandrescu récemment .

Quand une update materiel implique plusieurs centaines voir milliers de serveur effectivement , la réflexion doit être différente.

[Squisqui]

L'éternel débat entre la loi de Moore et la loi de Wirth
Malgré que les deux ont su prouver leur véracité pendant des années, aujourd'hui, la première montre ses limites favorisant à violer la seconde sur certains domaines.

Le jugement de Jeff Atwood était sans doute bon en 2008, mais il est bien connu que seuls les imbéciles ne changent pas d'avis. Nous sommes bientôt en 2014, les choses ont beaucoup changées et il est peut-être temps de se remettre en question.
Certains ont déjà commencé avec Microsoft qui optimise son OS Windows depuis Vista ou encore les différents développeurs autour des moteurs JavaScript.
Comble de l'ironie, les smartphones/tablettes utilisent du matériel beaucoup plus puissant qu'il y a 5ans sans en faire beaucoup plus.

[Niark13]

Je crains que son avis, qui a déjà plusieurs années, ne tienne pas la distance vis à vis de la fin de la loi de Moore ainsi que la crise énergétique et le changement de paradigme qu'elle impose…

[Shuty]

Ca se discute en fonction de la taille du projet. "Les développeur, ça coute cher" On dirait qu'on est riche quand j'entends ça lol

[yimson]

Pour ma part, je pense que la solution est de trouver le compromis, plus clairement le juste milieu. La question a laquelle il faut répondre est la suivante: La baisse de performance de l'application est-elle due à un programme mal écrit ou alors à la baisse de performance de l'équipement sur lequel le programme tourne?

Il est tout aussi important de penser à un expert dans le matériel, après une investigation on peut se rendre effectivement compte que le problème est par exemple causé par une barrette de RAM qui a rendu l’âme, auquel cas il faut augmenter les performances de l'équipement.

Par ailleurs, si le problème n'est pas du a l'équipement, il est toujours judicieux de penser à appeler un développeur qui peut avoir un nouvel œil sur les lignes de code du programmes question d'améliorer certains algorithmes et peut être certaines boucles.

[Paul TOTH]

C'est pas toujours vrai. Dans ma boite, sur du matériel mobile, on a eu un investissement d'un million d'euros rien que le matériel (ajoutez à ça les frais annexes) pour une appli sur laquelle bosse un dev et demie.

Suite à des problèmes de performances justement, on a eu le choix entre réinvestir à nouveau dans du matériel ou mettre un dev sur l'optimisation de code pendant 6 mois... Le calcul est vite fait.

ça ma fait penser à mon premier jeu Android, il est la réécriture sous Android d'un code Delphi pour le défi jeu du serpent, et bien les performances n'étant pas vraiment les mêmes j'ai du revoir le code pour que ça tourne sur une petite tablette; c'est un changement de plateforme avec une baisse de performance certaine.

[Thorna]

Ca fait 20 ans qu'on "rajoute du disque", "rajoute de la ram", "rajoute du CPU"... Je ne vois pas comment ni pourquoi ça changerait soudain, au prix que coûtent ces équipements par rapport à celui d'un bonhomme pour optimiser !

[sinople]

Moi j'applique la règle des trois make:

• Make it
• Make it working
• Make it working fast

On déjà content si on arrive à clôturer le point 2 dans un projet...

[imikado]

Les deux mon capitaine, mais je préfère me dire qu'on à fait le maximum sur notre partie (choix techno/cache/index...) avant de demander un upgrade de serveurs

[CodeurPlusPlus]

Autrement dit, avec un bon matériel, l’amélioration des performances suit toujours. (...)

Même un étudiant en première année d'informatique sait que ceci est parfaitement faux (sinon je l'invite à refaire sa première année). Si je me trompe, qu'on me dise où trouver le super-matériel qui résoud un problème NP complet en temps raisonnable.

[CodeurPlusPlus]

Je vais reformuler mon propos plus simplement. Avant de se demander s'il faut améliorer l'équipement et / ou optimiser le code, il faut avant tout optimiser les algos (ou s'assurer qu'ils sont déjà optimals) car c'est souvent le plus déterminant.